AWS Compute Optimizer cost in 2026

AWS Compute Optimizer costs nothing to run. The Compute Optimizer pricing page puts it in one line: "There is no additional charge for AWS Compute Optimizer." What is not free is the configuration that makes its EC2 recommendations worth acting on. The 93-day lookback costs $0.25 per instance per month. The CloudWatch metric that lets Compute Optimizer see memory at all costs $0.30 per instance per month, and without it the service will happily tell you to downsize a box that is memory-bound.

Is AWS Compute Optimizer free?

Yes, with two asterisks AWS itself prints. The pricing sentence is unconditional: "There is no additional charge for AWS Compute Optimizer. You pay only for the AWS resources needed to run your applications and Amazon CloudWatch monitoring fees." No support plan, no per-account fee, no minimum. You opt in and it starts reading CloudWatch.

The first asterisk is "Amazon CloudWatch monitoring fees", which does real work further down this page. The second is a paid recommendation preference called enhanced infrastructure metrics.

How much do Compute Optimizer enhanced infrastructure metrics cost?

$0.0003360215 per resource per hour. The pricing page gives the rate and the month together: "Enhanced infrastructure metrics cost $0.0003360215 per resource per hour and are charged based on the number of hours per month the resource is running. For a resource running continuously in a 31-day month, the feature would cost approximately $0.25."

It meters on running hours, so a stopped instance costs nothing for the feature, unlike the charges in what a stopped EC2 instance still costs that keep running. It bills per instance rather than per group: "The only exception is that EC2 Auto Scaling groups are charged per running EC2 instance." And it scales with fleet size, not with spend, so it is cheapest where it matters least. Every monthly figure here uses AWS's own month for this service, 744 hours, because all three of its worked examples do. At 720 hours the same resource is $0.2419.

Which Compute Optimizer lookback periods are free, and which are paid?

The pricing page frames this as 14 days free against three months paid. The rightsizing recommendation preferences page documents a third option in the middle and prices it at zero: "The 14-day and 32-day lookback periods require no additional payments. If you have monthly cycles, the 32-day lookback period can capture monthly workload patterns. The 93-day lookback period requires additional payment."

A month-end batch, a payroll run, a billing cycle: those are exactly the patterns a 14-day window misses, and they are why people buy the paid feature. A 32-day window catches them for nothing. The Compute Optimizer FAQ confirms the three-way choice for EC2, Auto Scaling groups and RDS: "you can change the settings to 32 or 93 days."

The pages also disagree on how much history 93 days buys. The pricing page and the FAQ both say the feature ingests "up to six times more Amazon CloudWatch utilization metrics history than the default Compute Optimizer option (up to three months of history compared to 14 days)". The enhanced infrastructure metrics page gives the real numbers: "This recommendation preference extends the utilization metrics analysis lookback period to up to 93 days, compared to the default 14-day period." 93 divided by 14 is 6.64. The marketing page rounds down.

Does the Compute Optimizer 93-day lookback pay for itself?

AWS never publishes the break-even, but it is one division. The feature costs $0.0003360215 per hour against an instance that costs its own hourly rate, so it is worth switching on the moment the longer history improves the fleet's rightsizing outcome by more than that ratio. The instance rates below are hypothetical, not AWS-quoted; this post quotes no EC2 prices. Substitute your own blended rate.

Read the third column as the hurdle. On a fleet averaging $0.10 an hour the paid lookback has to improve rightsizing by more than 0.34% of compute spend, and one instance at that rate terminated as idle funds the feature on 298 instances for a month. The hurdle gets harder as instances get cheaper: at $0.02 an hour the feature is 1.68% of the instance, and a fleet of burstable boxes is the case where the free 32-day window deserves a try first.

Why does AWS's own Compute Optimizer pricing example add up to half its total?

Because Pricing Example 2 is wrong as published. Its prose sets up an Auto Scaling group: "Assuming three resources ran for 31 days (744 hours) and two ran for half the month (372 hours), the bill at the end of the month for Compute Optimizer would be calculated as follows:". Five resources, 2,976 billable resource-hours, $1.00. The stated total is right. The table under it is not.

The published rows cover four resources and sum to $0.50, against a stated headcount of five and a stated total of $1.00. The row for three resources at 744 hours is missing, and the two-at-372-hours row is printed twice in its place. Examples 1 and 3 on the same page are both correct to seven decimal places. Only Example 2 broke, and the table is the half that broke. Work from the prose.

Can AWS Compute Optimizer see EC2 memory utilization, and what does that cost?

Not by default. The EC2 instance metrics page lists MemoryUtilization among the metrics analyzed, then qualifies it: "To have Compute Optimizer analyze the memory utilization metric of your instances, install the CloudWatch agent on your instances." EC2 publishes no memory metric on its own. Without the agent, or one of the four supported observability products, there is nothing to analyze.

Read the finding definition on the EC2 recommendations page with that in mind: "An EC2 instance is considered over-provisioned when at least one specification of your instance, such as CPU, memory, or network, can be sized down while still meeting the performance requirements of your workload, and when no specification is under-provisioned." The same page adds that "Memory utilization is analyzed only for resources with the unified CloudWatch agent installed."

So on an instance with no agent, memory can never be the reason for an over-provisioned finding, and it can never trigger the under-provisioned condition that would hold the recommendation back. A CPU-idle, memory-saturated instance looks over-provisioned to a service with only CPU, network and disk to go on. The memory headroom preference does not save you either. AWS notes on the preferences page that "To receive EC2 instance recommendations that consider the memory utilization metric, you need to enable memory utilization with the CloudWatch agent." The default 20% memory headroom is applied to a number the service does not have.

Fixing that costs $0.30 per instance per month. The agent publishes mem_used_percent as a custom metric, and the CloudWatch pricing page charges "@$0.30 per custom metric" in the first 10,000-metric tier. Because "CloudWatch treats each unique combination of dimensions as a separate metric, even if the metrics have the same metric name", and because Compute Optimizer requires the InstanceId dimension, that is one billable metric per instance. The first 10 custom metrics are in the CloudWatch free tier.

Per instance-month, memory costs 1.20 times what the extra 79 days of history costs. That ordering is worth sitting with. The cheaper purchase buys a longer view of metrics the service already has; the dearer one buys the metric that decides whether a downsize is survivable. Spend on memory first. Per-metric pricing also looks trivial until a fleet multiplies it, which is the same trap as in what Container Insights costs on EKS.

What will AWS Compute Optimizer refuse to rate?

Silence is easy to misread as a clean bill of health. The resource requirements page sets a history floor per resource type, and anything under it produces no finding at all.

Two consequences nobody flags. Turning the paid lookback on loosens the qualification bar rather than tightening it, since 30 hours anywhere in 93 days is easier to reach than 30 hours in 14, so intermittent instances start getting rated once you pay. And a quiet Lambda function is invisible, not approved: functions under the 50-invocation floor "don't appear in the Compute Optimizer console and don't receive recommendations".

Whole categories are excluded outright by the supported resources page. "Compute Optimizer doesn't generate EC2 rightsizing recommendations for Spot Instances." The instance-type table closes with "If an EC2 instance isn't listed, then it isn't supported by Compute Optimizer." Auto Scaling group rightsizing drops out for mixed fleets containing "Amazon ECS or Amazon EKS workloads", or mixing AMD with Intel, or x86 with Graviton. The "Aurora Serverless v2 instance class with automatic capacity scaling" is unsupported, a real gap given how the Aurora Serverless v2 ACU meter behaves on a cluster that never scales down. And EBS volumes stop being rated the moment they are detached.

How do Compute Optimizer, Cost Optimization Hub and Trusted Advisor differ?

They are one engine behind three front doors, and only one door costs money to open. Cost Optimization Hub's documentation is direct about which way the supply runs: "Resource rightsizing and idle resource recommendations are provided by AWS Compute Optimizer." It flows back too, since "After you enable Cost Optimization Hub, you can see estimated monthly savings in AWS Compute Optimizer, consistent with the savings estimates in Cost Optimization Hub." The Hub is where commitments and discounts get applied to the same finding, and its coverage gaps are the subject of our breakdown of what Cost Optimization Hub misses.

Trusted Advisor is the paid door. It "inspects your AWS environment, and then makes recommendations when opportunities exist to save money, improve system availability and performance, or help close security gaps", but "AWS Trusted Advisor checks are available to customers with an AWS Business Support+, AWS Enterprise Support, or AWS Unified Operations plan." The same page prices Business Support+ at "$29/month minimum per account". One account's support minimum is what the 93-day lookback costs on 116 instances.

The newer checks in the Trusted Advisor cost optimization reference re-present Cost Optimization Hub output and require opting in to both it and Compute Optimizer. The older ones are marked "This is a legacy check." and run on fixed thresholds: the low-utilization EC2 check "alerts you if the daily CPU utilization was 10% or less and network I/O was 5 MB or less for at least 4 days". CPU and network, a four-day rule, no memory anywhere.

Commitments are the piece Compute Optimizer does not touch, and rightsizing an instance a commitment already covers moves spend without reducing it. That interaction is the subject of Savings Plans coverage against utilization.

How do you turn on AWS Compute Optimizer across an organization?

From the management account, in one choice. The opt-in page offers "All accounts within this organization", and adds the detail that matters for a growing estate: "If you add any new member accounts to your organization after you opt in, Compute Optimizer automatically opts in those accounts." On the CLI that is aws compute-optimizer update-enrollment-status --status Active --include-member-accounts.

Enable Cost Explorer at the same time, because the requirements page makes it a prerequisite for pricing anything: "You must enable Cost Explorer to allow Compute Optimizer to use Cost Explorer's billing data to calculate savings and populate pricing information for your recommendations."

The paid preference has precedence rules, which is where organizations overpay by accident. "Resource-level preferences override account-level preferences, and account-level preferences override organization-level preferences." Switch the 93-day lookback on at the organization level and it is on for every qualifying running instance in every member account, including the ones nobody is rightsizing.

In order, then. Opt in, which is free. Install the CloudWatch agent for memory on anything you might downsize, at $0.30 per instance-month, because it is the only purchase here that changes whether a recommendation is safe. Move the lookback to 32 days, which is free and catches month-end shapes. Buy the 93-day lookback for genuinely quarterly workloads, per account rather than organization-wide. Then treat the output as a lead, not an inventory. Idle NAT Gateways now get findings, though the charge structure in what a NAT Gateway actually costs means an idle one is rarely the expensive one. Everything outside the supported list is not optimized. It is unexamined.