Cloud rightsizing: workload evidence, failure headroom and realized savings
Choose rightsizing candidates using CPU, memory, I/O, workload cycles and failure headroom. Work through a capacity and cost example, then distinguish a lower resource rate from realized bill savings.
TL;DR: Rightsizing matches a resource shape and count to measured workload requirements. Use peak and failure-mode evidence to reject unsafe candidates, then verify service outcomes and actual billing; a low average CPU chart or an estimated saving is insufficient.
Collect the missing dimensions before choosing a smaller machine
Average CPU can conceal a daily import, a single saturated core or a workload waiting on storage. Record memory pressure, I/O throughput and latency, network demand, connection counts and queueing alongside CPU. Cover the workload's business cycle and the expected recovery case. An observation window that misses month-end processing cannot establish month-end capacity.
Provider recommendations are useful candidate generators. AWS Compute Optimizer exposes rightsizing preferences for lookback, headroom and eligible instance families. Its EC2 memory-aware recommendations require supplied memory metrics, such as CloudWatch agent or supported external telemetry. An absent guest-memory series is missing evidence, not spare RAM.
Inspect the metrics and aggregation rules used by the recommender. Compare them with short bursts and service-level evidence that matter to your workload. A recommendation computed from the available history cannot account for a future event that history never represented.
| Dimension | Evidence for the candidate | Reason to reject or defer |
|---|---|---|
| CPU | Per-core demand and throughput under representative load | New shape throttles or misses latency target |
| Memory | Working set, reclaim, cache and restart behavior | Required headroom exceeds available RAM |
| I/O and network | Sustained and burst limits versus actual demand | Smaller shape removes required bandwidth |
| Reliability | Remaining capacity during an agreed failure | Survivors overload before replacement arrives |
Calculate a candidate before running the experiment
Use this illustrative model with equal workload distribution and comparable per-vCPU performance. Four instances each provide eight vCPUs, and measured peak demand totals twelve vCPUs. The original fleet's CPU utilization at that peak is 12 / 32 = 37.5%.
Replacing all four with four-vCPU instances provides sixteen vCPUs. Normal peak utilization becomes 75%. If one instance is unavailable, the remaining twelve vCPUs equal the entire measured peak demand, leaving no CPU headroom for bursts or recovery work. That candidate fails a requirement to remain below 70% at peak after losing one instance.
Five four-vCPU instances leave sixteen vCPUs after one loss, again 75%. Six leave twenty, or 60%, and pass this CPU-only screen. Memory, traffic distribution and instance bandwidth can still reject that candidate. vCPU counts across processor families are not interchangeable performance measurements.
from math import ceil
demand = 12.0
vcpu_per_instance = 4
target = 0.70
lost_instances = 1
needed = ceil(demand / (vcpu_per_instance * target)) + lost_instances
assert needed == 6
assert demand / ((needed - lost_instances) * vcpu_per_instance) == 0.60
The formula assumes demand remains stable through the failure and the survivors share it evenly. A zonal outage that removes several instances requires a different lost-capacity input and a placement plan consistent with it.
Keep the price calculation separate from the capacity claim
Assume fictional hourly rates of 0.40 currency units for the old shape and 0.23 for the candidate. Four old instances cost 1.60 per hour; six candidates cost 1.38. The estimated reduction is 0.22 per hour, or 0.22 / 1.60 = 13.75%, before other charges and discounts. These are teaching prices, not a cloud price quote.
Now check the actual bill model. An existing commitment may keep the payment unchanged until it expires or the freed coverage is used elsewhere. More instances may change licensing or operational cost. A fleet that performs less useful work can also look cheaper while increasing cost per successful transaction. Connect the experiment to unit economics, with comparable workload and quality.
The FinOps Foundation's usage-optimization guidance treats optimization as ongoing engineering work with performance and business constraints. Assign a service owner to accept the candidate, record the evidence and choose reversal conditions before the change.
Verify during the workload that made the decision difficult
Try a bounded portion of the fleet and compare equivalent requests. Observe startup and cache warming, the busiest interval and the agreed failure rehearsal. Confirm instance-family compatibility, available capacity and scaling delay. Reverse the experiment if it violates the service's latency or correctness criteria, even if the resource dashboard looks efficient.
Self-check: the new fleet costs 14% less on the estimate, but memory telemetry is missing and the busiest scheduled job has not run. Is the saving ready to approve? No. It is a candidate with two material evidence gaps. Collect the memory series and exercise that job before claiming the workload fits or the saving was realized.