Deleting an idle instance is easy. Downsizing a running production workload — and being right — is the discipline. Most right-sizing programs stall not because the savings aren't real but because the first bad resize destroys the program's credibility. One latency incident traced to a downsized instance and every subsequent recommendation dies in review. This playbook is about making resizes defensible: the statistics, the workflows, and the sequencing that let a fleet-scale program survive its own mistakes.
Percentiles, not averages
The first mistake is statistical. Average CPU utilization is a comfort metric: a service that idles at 4% for 23 hours and saturates for one averages under 10%, and resizing on that average causes the incident that ends the program. Defensible sizing decisions use p95 and p99 utilization over a window long enough to contain the workload's real cycles — 30 days minimum, longer where month-end batch, quarterly close, or seasonal traffic dominates the risk.
The rule: size to the percentile that matches the workload's tolerance for degradation. Latency-sensitive production sizes to p99 with headroom. Batch and asynchronous workloads can size to p95, because a slow tail costs minutes, not customers. Any recommendation that does not state its percentile, window, and headroom assumption is an opinion, not a finding.
Burst profiles and the t-family trap
Utilization shape matters as much as level. A workload that runs flat at 30% and a workload that idles at 5% with hourly spikes to 90% can share an average — and need entirely different targets. The spiky one may belong on burstable t-family instances, where sustained low baseline earns credits that fund the spikes at a fraction of the fixed-size cost. But the t-family is also a trap in reverse: move a genuinely busy workload onto burstable instances and it exhausts its CPU credits, then either throttles hard or, in unlimited mode, quietly bills surcharges that erase the savings. Check credit-balance metrics before and after any move into or out of the family. A t-instance persistently at zero credits is an undersize wearing a discount.
The memory blind spot
CloudWatch reports CPU, network, and disk from the hypervisor. It does not report memory, because the hypervisor cannot see inside the guest. Every right-sizing tool that works from default metrics is therefore sizing on half the picture — and memory is the half that fails badly, because memory exhaustion means OOM kills and swap-driven latency collapse, not graceful slowdown. Defensible downsizing of memory-relevant workloads requires the CloudWatch agent (or equivalent) publishing guest memory metrics for the full analysis window before any recommendation is issued. Where agent coverage is missing, say so: "no memory data — recommendation limited to CPU-derived family changes" is an honest finding. A confident downsize without memory data is a guess.
A right-sizing program is judged by its worst resize, not its best savings slide. Defensibility is the product.
Workflow: sign-off, rollback, sequencing
The technical analysis is half the playbook. The other half is process, and it is what separates a savings estimate from realized savings:
- Owner sign-off, always. Every recommendation routes to the service owner with the evidence attached — percentile charts, window, proposed target, projected saving. Owners know what the metrics don't: the failover capacity requirement, the launch next month, the vendor sizing mandate. Sign-off converts a central team's guess into a shared decision, and it is what keeps the program alive after the first rollback.
- A rollback path before every change. A resize is defensible only if it is reversible on a known trigger: alarm thresholds defined in advance, the previous instance type recorded, the revert change pre-written. Time-boxed observation — a week of post-change watching against the same p95/p99 baselines — closes each resize out as confirmed or reverted, never ambiguous.
- Nonproduction first. Sequence the program to build its own evidence: dev and test fleets first (where oversizing is habitual and blast radius is low), then stateless production behind load balancers, then stateful and singleton systems last. Each phase's confirmed-resize rate is the argument for the next.
The commitment interaction
Right-sizing changes what you run; Reserved Instances and Savings Plans price what you promised to run. Resize without checking coverage and you can strand commitments — paying for reserved capacity your smaller fleet no longer uses — turning a real utilization gain into zero net savings until the term expires. The interactions are mechanical but unforgiving: size-flexible RIs and Compute Savings Plans absorb downsizing within a family far better than zonal or instance-specific commitments; large fleet reductions belong just before renewal windows, not just after them. The playbook rule is one sentence: every resize recommendation carries a commitment-impact line, and the savings number quoted is net of stranding.
What changes with generated IaC
The historical bottleneck in all of the above was never analysis — Compute Optimizer has offered recommendations for years. It was the review cycle: a spreadsheet of suggestions that some engineer must translate into Terraform or CloudFormation changes, ticket by ticket. When the recommendation arrives as a parameterized code change — the diff, the rollback template, and the evidence in one reviewable unit — the owner's task collapses from "do this work" to "approve this change."
| Stage | Spreadsheet-driven | Recommendation as code |
|---|---|---|
| Analysis | Quarterly export, manual filtering | Continuous, p95/p99 over live windows |
| Owner review | Ticket, meeting, re-analysis | Pull request with evidence attached |
| Execution | Hand-written change, human error risk | Reviewed plan diff, applied via pipeline |
| Rollback | Improvised under pressure | Pre-generated revert, one approval |
| Typical cycle | Weeks per batch | Days, often same-day for nonprod |
The waste this discipline targets is not marginal. Flexera's 2026 report puts it at 29% of cloud spend — rising for the first time in five years — and the FinOps Foundation's 2025 survey has workload optimization as the top priority for roughly half of practitioners. The recommendations exist everywhere. Programs that realize them are the ones that made each resize cheap to review, safe to apply, and trivial to undo.
CAELION's Caelion Meridian runs this playbook as a standing capability: percentile-based analysis over live CloudWatch data, commitment-aware savings math, and every recommendation delivered as reviewable infrastructure-as-code with a rollback path. See it against your own fleet — request a private briefing.