AWS Compute Optimizer vs CloudWatch Rightsizing

• What each one is
• The blind spot they share
• How long you have to watch
• Headroom is a rule, not a judgement
• Using both without double-counting
• Which to use
• Frequently asked questions

There are two ways to decide an EC2 instance is too big. Ask AWS Compute Optimizer, which does the analysis for you and returns a dollar figure. Or read CloudWatch metrics and do the arithmetic yourself. They disagree more often than you would expect, they cover different resources, and they share one blind spot that neither will tell you about.

The useful answer is not which one to pick. It is knowing what each can actually prove.

What each one is

AWS Compute Optimizer is a managed service. You enrol an account, wait roughly a day for it to gather history, and it returns recommendations with its own estimated monthly savings attached. It covers EC2 instances, EBS volumes, ECS services on Fargate, RDS instances, Lambda functions and Auto Scaling groups. It will also surface Graviton and ARM64 options where it has validated them for your workload, which is a class of saving that is hard to derive yourself.

CloudWatch-based rightsizing is reading CPUUtilization and friends directly and applying your own rules about what constitutes over-provisioning. Nothing to enrol, no waiting period, and it works on the first day you look.

The blind spot they share

This one matters more than the differences, because it is invisible in both tools' output.

Neither can see how much memory your instance is using. The hypervisor reports CPU, network and disk. It cannot see inside the guest operating system, and memory usage lives inside the guest. Unless you have installed the CloudWatch Agent and are publishing memory metrics yourself, memory utilization is simply not a number anyone has.

So any recommendation that mentions your memory headroom is fabricated, and any recommendation that silently downsizes memory is making an assumption it cannot support. An instance at 12% CPU looks like an obvious downsize. If it is an in-memory cache or a JVM with a large heap, CPU is the wrong measure entirely and the smaller instance will fail in a way that is expensive and hard to attribute.

There are three honest responses to this, and the tools differ in which they take:

1. Make CPU-only recommendations and say memory was not measured.
2. Refuse to cut memory beyond a conservative fraction while it is unmeasured.
3. Tell the customer to install the agent so the next analysis can do better.

Our analyzer does all three. It makes CPU-based suggestions, states plainly that memory was not measured, and refuses to recommend any instance with less than half the current memory while memory is unmeasured. The recommendation text names the exact figure the operator has to confirm by hand: confirm the working set fits in the new size, down from the old one, before applying.

How long you have to watch

This is where doing it yourself earns its keep, because the observation window is a choice and it should be a disclosed one.

A quiet week proves very little. Weekly batch jobs, Monday-morning load, month-end reporting and quarter-close all hide inside a seven-day window. A recommendation derived from seven days of data is not wrong exactly, it is simply not yet supported.

The rule we implement is that the claim may never exceed the data. Short windows are reported as observations and are structurally incapable of producing a resize instruction:

The trap that makes long windows lie

There is a specific failure worth knowing about if you build this yourself.

CloudWatch reports a query for an absent metric series as complete, not as an error. Ask for 90 days of data on an instance that has only existed for 20, and you get a successful response containing 20 days of datapoints. Nothing in the response says the window was not covered. A naive implementation reads that as a 90-day observation and reports very high confidence in a claim backed by less than three weeks.

The guard is a coverage ratio. We require at least 80% of the requested window to actually carry data before describing a peak as covering that window. Metric gaps are normal, a stopped afternoon or an agent restart, but a series spanning 20 days must never be reported as 90.

Headroom is a rule, not a judgement

Once you have a peak, the question is whether the smaller instance could have carried it. This is arithmetic and it should be stated:

consumed  = peak%  / 100 * current vCPU     # actual work at peak
projected = consumed / target vCPU * 100    # as a % of the smaller box

A worked example. An m5.xlarge has 4 vCPU and peaked at 38% over 60 days. That is about 1.52 vCPU of real work. On an m5.large with 2 vCPU, the same peak lands at roughly 76%.

Seventy-six percent is too hot. Our ceiling is 70%, which leaves about 30% headroom against the worst datapoint observed in the entire window, room for growth and for a spike sharper than anything seen. So this recommendation is refused rather than made, and the refusal is the point. It is what stops a downsize that would throttle the workload during exactly the peak the data already showed you.

Two things follow from writing it this way. The arithmetic is unit-testable, so the numbers in a customer-facing report are checked by tests rather than trusted. And it is deliberately not delegated to a language model: a model asked to multiply will occasionally get it wrong, and one wrong dollar figure destroys trust in every correct finding next to it.

Using both without double-counting

The two sources overlap. The same instance can appear in Compute Optimizer's output and in your own analysis, with two different savings figures, and the naive merge counts it twice.

Deduplicating means agreeing on a key. We use resource type, resource ID and region, and everything must normalise to that before the sources meet. Compute Optimizer returns ARNs; direct API calls return bare IDs:

# Compute Optimizer returns:
arn:aws:ec2:ap-south-1:123456789012:instance/i-0a91c4e2

# describe-instances returns:
i-0a91c4e2

Same instance, different strings, no deduplication. We have shipped this bug twice: once on instances, where an earlier version keyed on the friendly Name tag, and once on EBS volumes, where the fix for instances was not carried across. The instance fix is released. The volume fix is written and under review at the time of writing. Both carry regression tests that fail if the key regresses.

The division of labour that avoids the problem entirely is to give one source ownership. Where Compute Optimizer has an opinion about an instance, we let it keep the finding, because its savings figure is AWS-computed and better than ours, and we append our headroom arithmetic and confidence band to its recommendation rather than emitting a rival one. Standalone findings are emitted only for instances Compute Optimizer returned nothing for.

Which to use

Enrol in Compute Optimizer. It is free, its savings figures are computed by the party that sets the prices, and Graviton validation is not something you can derive from metrics yourself.

Add your own analysis on top for the things it does not give you: a disclosed observation window, a headroom rule you can defend, an explicit statement about memory, and coverage of the questions utilization cannot answer at all, such as whether an Auto Scaling group's floor is too high.

Install the CloudWatch Agent either way. Both approaches are guessing about memory until you do, and both will keep telling you so.

The wider set of rules these follow is in the AWS cost optimization guide.

Frequently asked questions

What is the difference between AWS Compute Optimizer and CloudWatch rightsizing?

Compute Optimizer is a managed AWS service that you enrol an account into and that returns recommendations with AWS-computed savings across EC2, EBS, ECS on Fargate, RDS, Lambda and Auto Scaling groups, including validated Graviton options. CloudWatch rightsizing means reading utilization metrics directly and applying your own rules, which requires no enrolment and lets you choose and disclose the observation window and the headroom threshold.

Can AWS Compute Optimizer see memory usage?

Not by default. The hypervisor cannot see inside the guest operating system, so memory utilization is unavailable to both Compute Optimizer and any direct CloudWatch analysis unless the CloudWatch Agent is installed and publishing guest memory metrics. Any recommendation quoting your memory headroom without the agent is fabricated.

How long should I observe an instance before resizing it?

At least 30 days with 80 percent of the window actually carrying data. Windows of 7 and 15 days should be treated as observations rather than instructions, because weekly batch jobs, Monday-morning load and month-end reporting all hide inside a short window. Sixty and 90 day windows raise confidence further by covering month-end peaks and a quarter close.

Why does CloudWatch return complete results for a window with missing data?

Because a query for an absent or short metric series succeeds rather than erroring. Asking for 90 days on an instance that has existed for 20 returns 20 days of datapoints and a successful status, with nothing indicating the window was not covered. Guard against it with a coverage ratio, requiring at least 80 percent of the requested window to carry data before describing a peak as covering that window.

How much CPU headroom should a rightsizing recommendation leave?

We cap the projected peak on the proposed instance at 70 percent, which leaves about 30 percent headroom against the worst datapoint observed across the whole window. Convert the observed peak into absolute vCPU consumed, project it onto the target's vCPU count, and refuse the recommendation if it exceeds the ceiling. The refusal is what prevents a downsize that would throttle the workload during a peak the data already showed.

Should I use both Compute Optimizer and my own analysis?

Yes, but give one source ownership of each resource so findings are not counted twice. Deduplicate on resource type, resource ID and region, normalising Compute Optimizer's ARNs to bare IDs first. A good division is to let Compute Optimizer keep the finding where it has an opinion, since its savings figure is AWS-computed, and append your own headroom arithmetic and confidence band to it rather than emitting a competing finding.

Why would two rightsizing tools disagree about the same instance?

Because they use different observation windows, different headroom assumptions and different pricing inputs, and because neither can see guest memory. Disagreement is expected. What matters is that each states the window behind its claim and the headroom rule it applied, so the difference is explicable rather than mysterious.