rightsizing

Rightsizing

Most instance sizes are set once, at launch, from a guess made before real traffic existed — and then never revisited, because a running system that isn't on fire doesn't generate a reason to go back and check. The gap between provisioned and used capacity grows quietly for as long as nobody looks, and by the time someone does look it's often large enough to embarrass whoever picked the original size.

Rightsizing is not a one-time correction. Usage changes with every feature release, traffic pattern shift, and dependency change, so a size that was correct six months ago is a guess again today. The discipline is the measurement loop, not the resize itself.

Size from what the system actually uses, not from what someone guessed it might need.

1. Size from measured usage, never from instinct

"This feels like it needs 4 vCPUs" is not data. Pull actual CPU, memory, disk, and network utilization over a representative window before changing anything — a resize based on a hunch is just as likely to be wrong in the expensive direction as the cheap one.

• Use a window that includes peak traffic, not just a quiet afternoon that understates real need.
• Check all resource dimensions, not just CPU — a service throttled on memory or IOPS won't show up in a CPU-only view.

Done when: every resize decision cites a metrics window, not a guess.

2. Look at the right percentile, not the average

Average utilization hides the peaks that actually determine whether a resource is adequately sized — a workload that averages 20% CPU but spikes to 95% during checkout on Fridays will fall over if sized to the average. Size to a high percentile (p95 or p99) of the metric that matters for the workload's actual failure mode, with headroom for the spike, not to what it looks like on a typical Tuesday.

Done when: the sizing decision states which percentile was used and why it fits the workload's traffic shape.

3. Prefer autoscaling to a fixed guess wherever demand varies