Glossary
Rightsizing
Also: Right sizing · Resizing resources
Bringing resources to the size actually needed rather than the one chosen when they were created.
Almost every instance, container and database was created larger than necessary. That is not an oversight, it is a rational response to the incentives: undersize something and cause an outage, and you have a conversation ahead of you. Build it twice as large as needed and you have none, because the cost is invisible to everyone.
Rightsizing therefore does not mean turning a dial, it means replacing fear with data. The basis is utilization over at least fourteen days, so that weekly rhythm and monthly peaks are included. Only then can you say whether a reservation of eight gigabytes is really needed at a weekly average of 1.2 gigabytes.
For containers the reservation is the lever, not actual usage: ECS on Fargate bills reserved CPU and reserved memory regardless of whether the task uses them. A task with a four gigabyte reservation and 700 megabytes of usage costs four times what it should.
Lambda works against intuition: the memory setting also determines the allocated CPU, and billing is in gigabyte-seconds. More memory pays off exactly when runtime drops disproportionately. There are functions that run cheaper with twice the memory than before.
In terms of sequence, rightsizing belongs late, not early. Shrinking a workload that the next step removes anyway wastes the care you put into it. First delete what nobody needs, then get observability and data volumes under control, then resize.
How you notice it
- CPU utilization below ten per cent as a weekly average across several instances.
- Task definitions with reservations unchanged since day one.
- Capacity for a load case that occurs twice a year is kept available around the clock.
Not to be confused with
- Auto scaling
- Adjusts the number of units to the load. Rightsizing adjusts the size of one unit. Both together make sense, but auto scaling on badly sized units scales the waste along with it.
- Savings Plans
- A discount on what runs. Committing before rightsizing locks in the oversizing for one to three years.
- Spot instances
- Cheaper capacity for interruptible workloads, independent of size. It changes the price per unit, not the question of whether the unit is too large.
When it fits
- At least fourteen days of utilization data are available.
- The clean-up of unused resources is already done.
- The architecture of the component is stable and no rebuild is pending.
When it does not
- Before the clean-up. A resource that should be deleted does not need to be resized.
- For components whose load profile is currently changing, for example after a migration.
- Without a way back. Every reduction needs a rollback and a week of observation.
How to approach it
- Collect utilization over fourteen daysContainer Insights, the CloudWatch agent or the metrics of the service itself. What matters is the mean and the percentiles, not the peak alone: a single spike does not justify a permanent reservation.
- One size down, not threeJumping to a quarter in one step produces the outage that discredits the whole effort. One step down, observe for a week, then the next.
- Measure Lambda instead of guessingUse Lambda Power Tuning to find the curve of memory, runtime and cost per function. Half an hour per function, and the result regularly contradicts the expectation.
- Take Graviton where it is freeFor managed services, moving to ARM instances brings around 20 per cent at minimal effort. For your own workloads, wherever containers are built multi-arch anyway.
- Measure the effectDo not record the estimated saving, record the actual one from the Cost and Usage Report. The gap between the two is the learning curve.
Frequently asked
How much does rightsizing typically deliver?
In grown environments regularly between 20 and 40 per cent of compute cost. In one project over twelve months it was around 2,000 euros a month, but only after deletion, observability and data volumes had been dealt with. Before that, the same work would have gone into workloads that disappeared anyway.
Are the AWS Compute Optimizer recommendations enough?
As a starting point yes, as a decision no. The service sees metrics, not business context. It knows neither the year-end close where load triples nor the fact that a component will be switched off in six weeks.
What about the risk?
It is kept small by the sequence: one step, one week of observation, then continue. Every change can be reverted in minutes. The real risk is not in resizing but in resizing without a way back and without an alert.
Why does rightsizing come late in the sequence?
Because the earlier steps change the population. Shrinking an instance whose load disappears anyway through a cache or a disabled polling process means doing the work twice. After the clean-up it is also clear which load is permanent, and only that should be sized.