The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →P95 CPU is a fine summary statistic and a poor sole basis for shrinking an EC2 instance. It ignores the busiest five percent of observations, and CPU says nothing about memory, network, disk, EBS, burst credits or what your workload will look like next month. AWS itself offers P95 as a setting, so the problem is not that P95 is always wrong. The problem is treating it as the whole decision.
What P95 does and does not tell you
P95 is the value that 95% of your CPU data points fall at or below. The top 5% of data points are left out of that number. It is not a peak, and it is not a promise about latency or availability. An instance whose P95 sits at 35% can still hit 100% during a nightly batch, a deploy, a cache flush or a traffic spike, as long as those episodes make up a small share of the sampled intervals.
As an Amazon Associate I earn from qualifying purchases.
Whether those omitted intervals matter depends on the workload. A background worker that tolerates delay may be fine. A latency-sensitive API whose worst minutes are the ones customers notice is not. The statistic cannot tell these apart, so you have to.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The data points are also aggregates over a period, such as five minutes or one minute. A burst shorter than the period is averaged into its interval, so even the maximum you see on a chart can understate what the CPU did.
What AWS actually does
AWS does not say P95 is wrong. In Compute Optimizer’s rightsizing preferences, the EC2 CPU threshold can be P90, P95 or P99.5, and the documented default is P99.5, which ignores only the top 0.5% of data points. P90 ignores the top 10%.
The Balanced preset uses P95 with 30% CPU headroom and 30% memory headroom. The target is CPU below 70% for more than 95% of the time and memory below 70%. AWS describes this as suitable for workloads that are not particularly sensitive to utilization spikes. It is a product setting that trades savings against performance risk. It is not an independent benchmark or proof that 70% is safe for your application.
Rank #2
- Used Book in Good Condition
So the useful question is not “P95 or not?” but “does this workload tolerate the intervals the percentile discards?”
What CPU cannot see
Memory
EC2 does not report guest memory by default. Compute Optimizer only considers memory if you collect it with the CloudWatch agent or ingest it from a supported external source. Without that, a recommendation is effectively CPU-led, and a smaller instance family with less RAM can turn into swapping or out-of-memory kills while CPU looks idle.
Network, local disk and EBS
Smaller instances have lower network and EBS throughput limits. AWS’s Cost Explorer rightsizing calculation uses maximum CPU along with memory when enabled, network in and out, local disk I/O and attached EBS performance. A database or file-processing host can be I/O bound at 15% CPU, and downsizing it makes things worse. The Well-Architected guidance (PERF02-BP04) likewise says to analyze memory, network and CPU against workload characteristics and performance goals.
Burstable instances
For T2, T3 and T3a, AWS says to check whether the replacement can keep bursting above baseline given its vCPU count. A low percentile on a burstable instance may only mean it is living inside its baseline, or spending credits you cannot see on a CPU chart. A smaller size has a lower baseline and may earn credits more slowly, so confirm credit behavior on the candidate type before moving.
Rank #4
History is not a forecast
AWS’s EC2 recommendation documentation states: “The recommendations don’t forecast your usage.” Its standard example uses the most recent 14 days. Cost Explorer’s calculation also uses the last 14 days.
Two weeks can miss month-end processing, quarterly reporting, seasonal traffic and a planned launch. Compute Optimizer lets you choose a lookback of 14, 32 or 93 days. AWS says 32 days can capture monthly patterns. The 93-day option requires enhanced infrastructure metrics, which cost extra. Even the longest window only describes the past, so add known upcoming changes yourself.
Best Value
Comparison checklist before you downsize
| Check | What to look at | Why P95 CPU misses it |
|---|---|---|
| CPU shape | Average, maximum, chosen percentile, daily/weekly/monthly cycles | The top intervals are excluded |
| Memory | CloudWatch agent or external metrics actually flowing | Not a CPU metric, and not collected by default |
| Network and storage | Network in/out, local disk I/O, EBS throughput and IOPS against the candidate’s limits | Bottlenecks can occur at low CPU |
| Burst behavior | Credit balance and baseline of the replacement, vCPU count | Percentiles do not show credit exhaustion |
| Window | 14, 32 or 93 days; releases, batch jobs, seasons | History may not include your peak |
| Future demand | Growth, launches, migrations | Recommendations do not forecast |
| Headroom and risk | CPU and memory headroom, cost of an incident | A threshold is a risk setting, not a safety proof |
| Economics | Reserved Instance or Savings Plans coverage | Cost is separate from fit |
On economics: Cost Explorer’s estimates use On-Demand rates and account for applicable RI or Savings Plans coverage. AWS notes they do not capture second-order effects such as reallocating RI hours to other instances. A cheaper hourly price does not always mean a lower bill, so check your commitments.
A safer downsizing workflow
- Confirm that memory metrics are being collected, and note any gaps in disk, network or EBS visibility.
- Open the recommendation and read the graphs, not just the suggested type. AWS advises reviewing the metrics and the performance-risk rating.
- Pick a lookback that covers your longest business cycle, and note any events that fall outside it.
- Compare the candidate’s vCPU, memory, network and EBS limits, and burst behavior, with your observed maxima, not only P95.
- Test the candidate under representative load in non-production. AWS recommends rigorous load and performance testing before and after the change, and Well-Architected says: “Test configuration changes in a non-production environment before implementing in a live environment.”
- Compare latency and error rates as well as resource metrics. This is practical advice rather than an AWS-quoted step, but resource graphs alone do not show user impact.
- Change one step at a time, keep a rollback path (the previous instance type is a stop, modify, start away), and watch the workload through its next peak.
If you want to alarm on the result, CloudWatch supports percentile statistics for CPU and lets you set the period and the number of datapoints that must breach. See AWS’s CPU usage alarm guide. An alarm on a high percentile or on sustained maximum CPU gives early warning if the smaller size turns out to be tight.
The Bottom Line
Use P95 as one input, not the verdict. Downsize only when memory, network, storage, burst behavior and your longest business cycle all fit the smaller instance, and you have tested it under realistic load with a way back.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
