Utilisation Floor
The minimum utilisation a resource should sustain before it is considered over-provisioned, set with enough margin for failure and peak.
Rightsizing is straightforward to describe and easy to do badly, because the naive version optimises against the average and removes the headroom the system needs to survive.
The floor must account for three things: peak rather than average demand; the redistribution that follows losing a fault domain — with N zones, steady-state utilisation must stay below (N−1)/N; and the queueing curve, where waiting time grows as 1/(1−utilisation) and the last increment of capacity buys a disproportionate amount of latency stability.
That is why a target of 60–70% is common for latency-sensitive services, and why "this instance is at 30%, halve it" is frequently wrong.
Where the honest savings are, in order: non-production environments, which are usually sized like production and used a fraction of the time; workloads sized once at launch and never revisited, where traffic assumptions proved wrong by an order of magnitude; and memory-versus-CPU mismatch, solved by changing family rather than size.
Two practices that make it durable: rightsize on a schedule rather than as a one-off campaign, since drift returns; and verify with a load test at the new size, because provider recommendations are based on observed utilisation and do not know about the peak that has not happened yet.