The "Max Peak" Trap
When engineers provision infrastructure, they naturally think about worst-case scenarios: "What if we go viral? What if the batch job takes twice as long?" This is responsible thinking — but it leads to systematic over-provisioning. The "Best Day Ever" scenario gets baked into the instance size, and then the Best Day never comes. The server runs at 2–5% CPU utilization indefinitely.
Rightsizing is the process of matching instance size to actual workload requirements. For example, moving from an m5.xlarge (4 vCPU, 16 GB RAM) to an m5.large (2 vCPU, 8 GB RAM) cuts the instance cost roughly in half.
Why "Average CPU" Is a Dangerous Metric
The most common rightsizing mistake is recommending downsizes based solely on average CPU utilization. This is dangerous for a simple reason: averages hide spikes.
Consider this scenario:
- A web server averages 8% CPU over 30 days.
- Every weekday at 9:00 AM, CPU spikes to 95% for 15 minutes as users log in simultaneously.
A naive recommender sees "8% average" and suggests a much smaller instance. You downsize. The next Monday morning, the login spike causes the server to saturate CPU, requests queue up, and users experience timeouts.
The Golden Metrics for Safe Rightsizing
A production-grade rightsizing recommender must evaluate all of the following:
1. CPU P99 (99th Percentile Peak)
Size for the spikes, not the average. If P99 CPU over 30 days is 85%, the instance is correctly sized even if the average is 10%. The P99 tells you what the worst 1% of moments look like — and those moments are often your most important traffic.
2. Memory Usage — The Blind Spot
Standard AWS CloudWatch metrics do not include memory utilization. You must install the CloudWatch Agent (or a third-party agent like Datadog or Prometheus Node Exporter) on each instance to collect memory metrics.
This is critical: never rightsize based on CPU alone. Many workloads — databases, JVM applications, in-memory caches — are memory-bound, not CPU-bound. An instance running at 5% CPU and 90% memory will crash with an Out of Memory (OOM) error if you halve its RAM.
3. Network and Disk I/O Throughput
Some instance types are chosen specifically for their network bandwidth or EBS throughput limits, not their compute capacity. A data pipeline instance might use 3% CPU but saturate its network interface. Downsizing the instance type could reduce the network ceiling and cause the pipeline to fall behind.
The Safe Recommendation Template
A well-designed rightsizing recommendation looks like this:
Instance: i-0abc123def456 (m5.2xlarge)
Current cost: $280/month
Metrics (30-day window):
CPU P99: 12%
CPU Avg: 4%
Memory P99: 18%
Memory Avg: 11%
Net I/O: Low
Recommendation: Downsize to m5.large
Projected cost: $70/month
Monthly savings: $210 (75% reduction)
Confidence: HIGH — all metrics well within safe thresholds
The confidence rating matters. A recommendation with P99 CPU at 70% should be flagged as LOW confidence — there is not enough headroom to safely downsize.