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%.

A worked right-sizing

Suppose an eight-vCPU instance shows a p95 CPU of 62% and a memory working set of 9 GiB. Multiply the p95 by the vCPU count to get the real demand: 0.62 × 8 = 4.96 vCPU. Add 20% headroom and you need 5.95 — so four vCPUs is too few and eight is roughly 35% more than required. The honest answer here is a six-vCPU size if the family offers one, otherwise eight with autoscaling.

Now put a number on it. Cloud list prices change constantly, so treat the rate below as an example and substitute the current figure from your provider's pricing page. At an illustrative $0.384 per hour, and using 730 hours as the average month (8,760 ÷ 12):

Halving the instance halves the bill, saving $1,681.92 a year on one machine. The reason right-sizing is the highest-return cloud activity is that this is per instance, per environment, and most fleets have dozens of them. Run your own numbers through the EC2 instance cost calculator.

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.

The mix matters more than the discount rate. If 60% of your spend is a stable baseline you can commit at a 55% discount and 40% stays on-demand, the blended result is (0.60 × 0.45) + 0.40 = 0.67 of the on-demand bill — a 33% saving, not 55%. Committing 100% would save more but strands capacity you no longer need the moment the architecture changes. Model the blend with the reserved instance savings calculator and the spot instance savings calculator.

Spot capacity needs the workload to tolerate a two-minute termination notice. Queue consumers, CI runners, batch rendering and stateless web tiers behind a load balancer qualify. Stateful singletons and anything holding a long transaction do not.

The costs that surprise people

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

item. At an example rate of $0.09 per GB, 10 TB a month is 10 × 1,024 × 0.09 = $921.60 — likely more than the instance serving it. Inter-region and internet egress are billed separately and rates vary by region, so check the current table rather than trusting a remembered number.

• NAT gateway processing charges scale with traffic volume, and every private

subnet pulling container images through one pays twice: once for NAT, once for egress.

• 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, which makes a chatty

multi-AZ service measurably more expensive than a single-AZ one.

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.

Two habits make the process stick. Tag every instance with an owner and a workload name at launch, because untagged resources are the ones nobody deletes. And compare the bill against the measurements monthly rather than quarterly — the gap between what you provisioned and what you use only ever grows on its own.