AWS Compute Optimizer analyses CloudWatch utilisation and recommends rightsizing for EC2, Auto Scaling groups, EBS volumes, Lambda, and more, scoring options as over provisioned, under provisioned, or optimised. It is genuinely useful, but it is an advisor, not a decision: its default fourteen day lookback can miss a monthly batch peak, it does not see your application's latency budget, and it does not know which instances are already covered by a Savings Plan or Reserved Instance. So you trust the direction and verify the specifics. Enable enhanced infrastructure metrics for a longer lookback, check each recommendation against the workload's true peak and headroom, confirm the target family is covered by your commitments, and roll changes out behind monitoring. That is how a recommendation becomes a banked saving rather than a 2am page.
Here is what Compute Optimizer measures, where its defaults mislead, and the verification checklist that makes its picks safe to act on.
What does Compute Optimizer actually measure?
Compute Optimizer reads historical CloudWatch metrics, CPU, memory where the agent reports it, network, and disk, and compares them against the AWS instance catalogue to suggest a cheaper or better fitting option. For EC2 it ranks alternatives and shows projected utilisation on each. For EBS it flags over provisioned IOPS and volumes that would be cheaper on gp3. For Lambda it suggests memory settings. The analysis is sound as far as it goes, but it can only reason about the window and the signals it has.
Where do its defaults mislead?
Three gaps cause most bad picks if you act on the raw output:
- Lookback window. The default period can miss a peak that occurs monthly or quarterly. A workload that looks over provisioned for thirteen days may be exactly sized on the fourteenth. Enhanced infrastructure metrics extend the lookback to up to three months and should be on for anything with periodic load.
- Memory blindness. Without the CloudWatch agent, memory is not measured, so a memory bound workload can be flagged as over provisioned on CPU alone. Install the agent before trusting a downsize.
- Commitment ignorance. Compute Optimizer does not know your Savings Plans or Reserved Instance coverage. Moving off a covered instance family can strand a commitment and raise net cost even as the on demand rate falls.
What is the verification checklist before you act?
Run each recommendation through five checks. Does the lookback cover the workload's real cycle, including month end batch. Is memory measured, not assumed. Does the target instance family keep you inside existing Savings Plan or Reserved Instance coverage, or does it strand a commitment. Does the application have a latency or headroom requirement the metrics do not show. Can you roll the change out behind monitoring with a fast rollback. A pick that passes all five is safe to bank; one that fails any is a hypothesis that needs a closer look.
How does this fit a broader AWS program?
Rightsizing is one lever among several, and it interacts with the others. Verify against commitments first so you do not strand a Savings Plan. Pair downsizing with a move to Graviton and gp3 where the workload allows, since those are standing wins. Read the Cost and Usage Report as the source of truth rather than the console summary. Compute Optimizer points at the opportunities; disciplined verification and the wider program turn them into a durable reduction.
A worked example
A scaling fintech accepted Compute Optimizer downsizing recommendations across a fleet and saw cost fall, then hit intermittent latency on a service whose monthly close drove a peak the default lookback never saw. Re running the analysis with enhanced infrastructure metrics and the CloudWatch agent reporting memory corrected several picks, and cross checking against Savings Plan coverage stopped two downsizes that would have stranded a commitment. The verified set still delivered most of the projected saving, and it contributed to the program that left the company 41 percent lighter on cloud spend without a repeat incident. Figures are verified against billing data and anonymised.
Frequently asked questions
Is AWS Compute Optimizer accurate?
Should I enable enhanced infrastructure metrics?
Can rightsizing strand a Savings Plan?
Turn Compute Optimizer output into banked savings
We help AWS teams read Compute Optimizer critically, verify each pick against real workload context and commitment coverage, and roll changes out without regressions, across AWS, Azure, GCP, and OCI. We take zero provider commissions and answer only to you, on a Fixed Fee or a no risk Gainshare basis, with a simple guarantee: we reduce your cloud spend or we reimburse our service fee. Book a strategy call, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.