The two week right-sizing sprint: a repeatable playbook

Right-sizing fails as a backlog item and works as a sprint. As a backlog item it competes with feature work forever, each resize needs its own justification, and after four months nine instances have been resized. As a two week sprint with a ranked list and a batch cadence, the same team ships dozens of changes because the process, not the individual decision, carries the risk management.

The sprint shape

Days 1 to 2: the candidate list

Pull 14 days of metrics for every compute instance, container workload, and managed database. The thresholds that work: p95 CPU under 25 percent, p95 memory under 50 percent, and peak CPU under 60 percent. Peak matters because an instance averaging 10 percent but hitting 95 percent twice a day is sized for that peak and should not be touched.

Rank by absolute monthly dollars saved, never by percentage over-provisioned. A 90 percent idle t3.micro saves $7 a month and an m5.4xlarge at 30 percent utilisation saves $280 by halving. The list should be sorted so the first ten items are worth more than the remaining hundred, which is usually how the distribution falls.

Two exclusions belong in the list from the start. Anything with a memory bound profile that lacks memory metrics, since the default cloud metrics for most instance types do not report memory without an agent, and resizing a memory bound workload on CPU data is the most common way to cause an incident. And anything under a commitment where the resize would strand coverage, which is a financial rather than technical consideration.

Days 3 to 5: batch one, non-production only

The first batch is entirely non-production because it validates the tooling, the rollback path, and the measurement without customer risk. Fifteen to thirty resources is a realistic batch. Apply one size step each: an m5.2xlarge at $0.384 per hour becomes an m5.xlarge at $0.192, not an m5.large. One step at a time is the rule that makes rollback cheap and diagnosis easy.

Do every resize through Terraform rather than the console, so the change is reviewable, the saving is visible before merge, and the next environment built from the same module inherits the new size. A console resize is undone by the next apply.

Days 6 to 8: observe, then production batch

Observation means checking p99 latency, error rate, and saturation metrics against the pre resize baseline, not just checking that nothing paged. A resize that added 15 milliseconds to p99 latency is a regression even if no alert fired. Capture the baseline before batch one so this comparison is possible.

Batch two takes the top production items by dollar value. Production batches are smaller, ten to fifteen resources, and each needs an explicit rollback plan: for most instance types a resize is a stop, change, start cycle, so the rollback is the same operation in reverse and takes minutes. For managed databases the resize triggers a failover window, so schedule it. The performance guardrails are in right-sizing without hurting performance.

Days 9 to 12: the third batch and the awkward cases

Batch three covers what is left, plus the cases the first two batches deferred. Kubernetes workloads belong here, since resizing means adjusting requests and limits rather than instance types, and the method differs enough to warrant its own pass, covered in right-sizing Kubernetes pods. Over-requested pods are usually the largest single source of cluster waste, because the scheduler provisions nodes against requests rather than usage.

Days 13 to 14: measure and codify

Measure by comparing the compute run rate to the pre sprint baseline, adjusted for any unrelated growth. A typical sprint across a mid sized estate ships 30 to 60 resources and removes 10 to 20 percent of compute spend. On a $60,000 a month compute base that is $6,000 to $12,000 a month.

Then write the result into module defaults. If the sprint discovered that the standard web tier runs fine on an m5.large rather than an m5.2xlarge, change the default in the module so the next twenty environments start correct. This is the step that stops the sprint being annual. Pair it with a cost estimate on every infrastructure pull request against the resource catalog so a resize upward has to justify itself in review.

Budget for rollbacks

Expect one or two rollbacks in a sprint of fifty resizes. That is not failure, it is the expected cost of moving quickly with a cheap reversal path. A team that has zero rollbacks was too conservative and left money on the table. What you must avoid is a rollback you cannot diagnose, which is why single size steps and a captured baseline matter more than any other part of the process. The broader rollout model is in the right-sizing program rollout.

FAQ

What to do next

Codify the right size in the module. C3X prices Terraform changes against a live resource catalog so a resize upward argues its case. Start with the quickstart.