How to Size Cloud Instances Without Overpaying

Most cloud overspend is not caused by expensive services. It is caused by instances chosen from a dropdown before anyone measured what the workload needed.

Measure first

Before choosing an instance, establish four numbers for a representative period — ideally a full week, since weekday peaks and weekend troughs both matter:

1. CPU utilisation at the 50th, 95th and 99th percentiles
2. Memory working set, not memory allocated
3. Network throughput, in and out separately
4. Disk IOPS and throughput, plus queue depth

The percentiles are the important part. An average of 15% with a p99 of 90% is a completely different sizing problem from a steady 15%.

The usual failure modes

Sizing for the peak of the peak

Provisioning for the highest spike ever observed means paying for that capacity permanently. Autoscaling or burstable instances handle spikes far more cheaply.

Confusing allocated with used

A JVM configured with an 8 GB heap will report 8 GB in use regardless of the actual working set. Measure what is genuinely resident.

Ignoring the CPU-to-memory ratio

General-purpose instances sit near 1:4 (vCPU:GiB). Compute-optimised are 1:2, memory-optimised 1:8 or more. Picking the wrong family means paying for one resource to obtain enough of another — the most expensive common mistake.

Overlooking burstable credits

Burstable families are excellent for spiky, low-average workloads and terrible for sustained load, where credit exhaustion throttles you hard. Check the baseline percentage, not just the peak.

Pricing models, ranked by savings

A sensible default: reserve or commit the steady baseline, serve the variable portion on-demand, and put fault-tolerant batch work on spot. Model the mix with the reserved instance savings calculator and the spot instance savings calculator.

The costs that surprise people

• Egress. Data leaving the provider is usually the largest unexpected line

item. Inter-region and internet egress are billed separately.

• NAT gateway processing charges scale with traffic volume.
• Idle load balancers and unattached volumes bill continuously for nothing.
• Snapshots accumulate silently and forever unless lifecycle-managed.
• Cross-AZ traffic is charged in both directions.

A workable process

1. Deploy on a deliberately generous on-demand instance.
2. Run a full week under real load.
3. Right-size to p95 plus roughly 20% headroom.
4. Observe for another week.
5. Commit to a savings plan only once the shape is stable.
6. Re-review quarterly — workloads drift.

Committing before step 5 locks in a guess for one to three years, which is the one mistake that is genuinely expensive to reverse.