Right-Sizing: Finding the Gap Between Provisioned and Used

Why over-provisioning happens

• The original size was a guess, made before any load existed.
• It was sized for a launch spike that never recurred.
• Someone doubled it during an incident and nobody reduced it afterwards.
• It was copied from another environment with different requirements.
• A safety margin was applied on top of a figure that already included one.
• Nobody owns the cost, so nobody looks.

The incident-doubling pattern is the most common and the most durable, because reducing it feels risky even when the incident was unrelated to capacity.

The measurement that matters

Use peaks, not averages, over a period long enough to include your real cycles:

Four weeks catches a monthly cycle. If you have quarterly peaks — a billing run, a seasonal event — account for those separately rather than sizing everything for them permanently.

Memory is the one to be careful with

CPU throttling makes things slow. Running out of memory makes things stop, because the kernel kills processes. Leave more headroom on memory than on CPU.

Beware runtimes that expand to fill available memory — the JVM, some databases, and caches configured as a percentage of RAM. Their usage graph reflects configuration, not need, so read the configuration before concluding the memory is required.

Do it safely

1. Start with non-production. The risk is negligible and the pattern is often identical.
2. Change one size step at a time.
3. Reduce during a low-traffic window, since most resizes need a restart.
4. Watch for a full week, including the weekly peak, before the next step.
5. Note the previous size so reverting is trivial.
6. Reduce one dimension at a time when instance families let you, so you know what caused any change.

Beyond instances

• Databases — usually the most over-provisioned resource in an estate, and often sized for a migration years ago.
• Volumes — check allocated against used, and check whether provisioned IOPS are being consumed.
• Kubernetes requests and limits — requests reserve capacity whether or not it is used, so inflated requests waste nodes directly.
• Serverless memory settings — often left at a default that is either wasteful or slow.
• Managed service tiers — a search cluster or cache sized for a peak that no longer exists.
• Non-production entirely — schedule it off outside working hours rather than shrinking it.

Kubernetes requests deserve special attention. A cluster can appear full while nodes sit at 20 per cent CPU, purely because pods reserve more than they use.

Keep it from drifting back

1. Run the analysis monthly; the provider tools generate most of it automatically.
2. Require a size justification in code review for anything above a threshold.
3. Tag resources with an owner so recommendations reach someone who can act.
4. Track a utilisation figure alongside the spend figure, so efficiency is visible.
5. Re-check after any significant architecture change.

Common questions

Where to go next

See how to size a cloud server and budgets and alerts.