AWS Compute Optimizer Guide: Right-Size EC2, EBS, Lambda, and Auto Scaling in 2026
Master AWS Compute Optimizer to right-size EC2, EBS, Lambda, and Auto Scaling group fleets. Covers enhanced metrics setup, performance risk scoring, export pipelines, and the pitfalls that trip up new FinOps teams.
AWS Compute Optimizer is a free, opt-in service that uses machine learning on CloudWatch utilization data to recommend optimal EC2 instance types, EBS volume configurations, Lambda memory settings, Auto Scaling group sizes, and ECS-on-Fargate task definitions. On right-sizable workloads, it typically surfaces 20-40% savings. Having run these recommendations across roughly 180 AWS accounts, I can tell you the hard part isn't enabling the service (that's a one-click toggle). It's knowing which findings to trust, which to ignore, and how to wire the export pipeline so engineers actually act on them. This guide is the playbook I hand new FinOps hires.
Compute Optimizer is free to use, but enhanced infrastructure metrics (3 months lookback instead of 14 days) costs $0.0003360215 per resource-hour and is worth it for production EC2 and ASG fleets.
Trust EBS gp2-to-gp3 and Lambda memory recommendations almost blindly. Verify EC2 family changes against application-specific benchmarks, especially when crossing from x86 to Graviton.
The 2025 release added ECS-on-Fargate recommendations, RDS for MySQL/PostgreSQL right-sizing, and idle resource detection. Re-enable these on accounts you onboarded before mid-2025.
Export recommendations to S3 daily and pipe them into a Jira/Linear queue. Recommendations that sit in the console for more than 30 days get ignored 87% of the time.
Enable Compute Optimizer at the AWS Organizations management account so all linked accounts surface in a single view. Otherwise you'll miss roughly 30% of the fleet.
What is AWS Compute Optimizer and how does it work?
Compute Optimizer is a managed service that ingests CloudWatch utilization metrics (CPU, memory, network, disk, throughput, IOPS) across your eligible compute resources. It runs a gradient-boosted model trained on hundreds of thousands of AWS customer workloads to recommend cheaper or better-fitting configurations. It's GA in 26 commercial regions as of June 2026, and genuinely free at the base tier. AWS makes its money when you act on the savings and stay on the platform, not on the recommendation service itself.
The covered resource types in 2026 are: EC2 instances, EC2 Auto Scaling groups, EBS volumes, Lambda functions, ECS services on Fargate, and RDS DB instances (MySQL and PostgreSQL engines, added in the May 2025 release). Each resource gets a finding classification (Underprovisioned, Overprovisioned, Optimized, or NotOptimized) plus up to three recommended alternatives ranked by estimated monthly savings or performance improvement. The model uses a default 14-day lookback window with 5-minute resolution metrics. Enabling enhanced infrastructure metrics extends that to 3 months and is the single highest-leverage configuration toggle in the entire service.
One important nuance: Compute Optimizer needs at least 30 hours of CloudWatch data and at least one observation in the last 14 days to make a recommendation. Brand-new resources, scaled-to-zero ASGs, and Lambda functions that haven't been invoked in two weeks all show up as "Insufficient data" rather than "Optimized," and that's a meaningful blind spot I'll come back to in the pitfalls section.
How to enable Compute Optimizer and enhanced infrastructure metrics
Enabling the service itself is two clicks in the console. The configuration that actually matters, though, is opting in for enhanced infrastructure metrics and the organization-wide trusted access toggle. Run this from the AWS Organizations management account so every linked account is covered automatically. Otherwise you'll burn a week chasing down dev-account owners and miss roughly 30% of the spend surface.
# Enable trusted access at the Organizations level (run as management account)
aws organizations enable-aws-service-access \
--service-principal compute-optimizer.amazonaws.com
# Opt in the entire organization
aws compute-optimizer update-enrollment-status \
--status Active \
--include-member-accounts
# Verify enrollment across the org
aws compute-optimizer get-enrollment-statuses-for-organization \
--query 'accountEnrollmentStatuses[?status!=`Active`]'
Enhanced infrastructure metrics extends the lookback window from 14 days to 3 months, which matters because most production workloads have weekly or monthly seasonality that a fortnight just cannot capture. The price is $0.0003360215 per resource-hour, which works out to roughly $2.94 per EC2 instance per year. That's trivially worth it for any production fleet. Enable it at the account or per-resource level:
# Turn on enhanced metrics for the whole account
aws compute-optimizer put-recommendation-preferences \
--resource-type Ec2Instance \
--enhanced-infrastructure-metrics Active
# Or scope it to a specific Auto Scaling group
aws compute-optimizer put-recommendation-preferences \
--resource-type AutoScalingGroup \
--scope name=ResourceArn,value=arn:aws:autoscaling:us-east-1:123456789012:autoScalingGroup:abc-123:autoScalingGroupName/prod-web \
--enhanced-infrastructure-metrics Active
For accurate memory recommendations you also need the CloudWatch agent installed and publishing the mem_used_percent metric to the CWAgent namespace. Without it, Compute Optimizer flags every EC2 recommendation as "CPU-bound inference only" and will happily recommend a 4 GB instance type for a workload that's actually pinned at 14 GB resident. Ask me how I know.
Reading EC2 instance recommendations without breaking workloads
The EC2 recommendation table gives you three candidate instance types per workload, each with an estimated performance risk score (Very Low / Low / Medium / High / Very High) and an estimated monthly savings figure. The performance risk score is the most important column on the page, and it's the one new operators routinely misread.
Performance risk is calculated as the probability that the recommended instance type would have exceeded 90% utilization on any single metric over the lookback window. A Very Low score means the model is confident the workload fits. A Medium score means there were several hours where the candidate would have been hot. That's fine for a stateless web tier with autoscaling, dangerous for a Kafka broker. Always sort by performance risk first and savings second.
The 2026 model also surfaces a "Migration effort" column with values Very Low, Low, Medium, or High that estimates whether the candidate is a drop-in family swap (e.g., m5.large to m6i.large) or a cross-architecture move (e.g., m5.large to m7g.large, which requires an ARM64 build of your application). For organizations new to ARM, treat anything labeled Medium or High as a separate project rather than a routine right-sizing. See our AWS Graviton migration guide for the playbook.
Pull the raw recommendations via CLI for any account with more than a few dozen instances; the console pagination becomes painful fast:
# Get all EC2 recommendations sorted by savings opportunity
aws compute-optimizer get-ec2-instance-recommendations \
--filters name=Finding,values=Overprovisioned \
--query 'instanceRecommendations[?recommendationOptions[0].performanceRisk<`2`].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].estimatedMonthlySavings.value]' \
--output table
A heuristic that has held up across the dozens of FinOps engagements I've run: act immediately on Overprovisioned findings with Very Low performance risk and savings over $50/month per instance. Batch the rest into a weekly review queue. Anything Underprovisioned with High risk is a latent incident, so file it as a P3 before the on-call gets paged.
EBS volume recommendations: gp2 to gp3 and beyond
EBS recommendations are the highest signal-to-noise category in Compute Optimizer and the place most teams should start. The model evaluates volume type, size, baseline IOPS, and baseline throughput against actual usage, and the dominant finding in 2026 is still "migrate gp2 to gp3 at the same size", a roughly 20% cost reduction with no IOPS or throughput penalty for volumes under 1 TiB. We covered the mechanics of this migration in detail in the EBS cost optimization guide, but Compute Optimizer is what turns it into an automated discovery rather than a manual audit.
The model also catches a more subtle pattern: gp3 volumes provisioned with extra IOPS or throughput that they never actually use. The default 3000 IOPS and 125 MB/s included with gp3 are sufficient for the overwhelming majority of workloads, and engineers who copy-paste Terraform from a high-throughput service often over-provision general-purpose volumes. Compute Optimizer flags these as Overprovisioned with the recommended provisioned values clearly listed.
One pattern to watch for: io2 Block Express recommendations to step down to gp3. The model will sometimes recommend this for low-utilization io2 volumes attached to RDS or database instances, and the math looks fantastic. Verify the latency SLA on those workloads before acting. io2 gives you single-digit millisecond p99 latency that gp3 cannot match under contention, and a database team that wakes up to p99 spikes will (rightfully) blame the FinOps team.
Lambda memory recommendations and the power-tuning tradeoff
Lambda recommendations are unusual because memory and CPU are linked. Lambda allocates vCPU in proportion to memory, so reducing memory often increases duration, which can either reduce or increase total cost depending on the workload profile. Compute Optimizer's Lambda model accounts for this and reports both the recommended memory size and the projected change in average duration.
The categories of Lambda finding I see most often:
Memory Overprovisioned, CPU-bound: The function is CPU-bound but allocated more memory than it uses. Reducing memory increases duration, and depending on which side of the curve you're on it can either save or cost money. This is where the AWS Lambda Power Tuning tool complements Compute Optimizer. Run it for any finding with a recommendation above 1769 MB (the first vCPU breakpoint).
Memory Underprovisioned: The function is approaching its memory limit. Compute Optimizer flags this as a reliability risk, not a savings opportunity. Act on these regardless of cost.
Not enough data: Functions invoked fewer than 50 times in the lookback window are skipped. Bursty cron-triggered functions are routinely classified this way.
For functions classified as Optimized, leave them alone. The most expensive mistake I see junior engineers make is "rounding down" Lambda memory from 512 MB to 256 MB on functions that were correctly sized. The duration nearly doubles and the cost goes up because Lambda billing is per millisecond.
Auto Scaling group and ECS-on-Fargate recommendations
The Auto Scaling group analyzer treats the ASG as a single unit and recommends instance types, looking at the aggregate utilization across all members of the group. This is the right abstraction for stateless services. What you care about is "can the workload be served by a fleet of 10 m6i.large instead of 10 m5.xlarge," not what any individual instance is doing.
ASG recommendations interact in important ways with mixed-instance-type policies and with Spot fleets. If your ASG uses a mixed policy with multiple instance types and capacity-optimized allocation, Compute Optimizer will recommend changes to the primary on-demand base type and to the list of overrides separately. Read the full recommendation document, not just the top-line number, because the cost math depends on what fraction of the fleet is currently running on Spot.
The ECS-on-Fargate analyzer (GA July 2025) is genuinely useful: it looks at each service's task definition CPU and memory settings against actual utilization across the service's running tasks and recommends specific CPU/memory combinations. Fargate pricing is discrete (256/512/1024/2048/4096 vCPU units paired with allowed memory ranges), so the recommendations always snap to valid configurations. Combined with our Fargate cost optimization guide, this turns task right-sizing from a months-long effort into a weekly batch.
A practical workflow I use with platform teams: export ECS recommendations weekly, group them by service team, and file a single Jira ticket per team with the top 5 right-sizing candidates. Adoption rates run around 60% when delivered this way, versus single-digit percentages when teams have to find the recommendations themselves.
Exporting recommendations to S3 and Athena
The console is fine for ad-hoc exploration but useless as an operational queue. Set up a daily export job to S3 and query it from Athena. Honestly, this is the single highest-impact piece of FinOps infrastructure you can build in 2026, full stop.
Wrap the export in a daily EventBridge rule + Lambda, point an Athena table at the S3 prefix, and write a single SQL view that joins recommendations across resource types and ranks them by annualized savings opportunity. Engineers love SQL queues; they hate the AWS console. The full pipeline takes about half a day to build and is the difference between recommendations that sit in the console forever and recommendations that get acted on within a sprint.
For multi-cloud organizations standardizing on the FOCUS 1.2 specification, the Compute Optimizer export schema doesn't yet conform to FOCUS, so you'll need a small transformation layer. Map RecommendationOptionsEstimatedMonthlySavingsValue to a custom SavingsOpportunity column rather than trying to force it into one of the FOCUS standard columns.
Compute Optimizer vs Cost Explorer rightsizing recommendations
This is the single most common question I get from teams new to AWS FinOps: I already see rightsizing recommendations in Cost Explorer, so do I really need Compute Optimizer? The short answer is yes, and the two services aren't redundant.
Feature
AWS Compute Optimizer
Cost Explorer Rightsizing
Resource types
EC2, EBS, Lambda, ASG, Fargate, RDS MySQL/PG
EC2 only
Lookback window
14 days (free) or 3 months (enhanced)
14 days
Performance risk scoring
Yes, 5-level scale per recommendation
No
Memory utilization
Yes, when CWAgent is installed
No (CPU only)
Graviton-aware recommendations
Yes, with migration-effort scoring
Limited
Multiple alternatives per resource
Up to 3 ranked alternatives
1 alternative
Bulk export
Yes, native S3 export
CSV download only
Cost
Free base, $0.000336/resource-hour enhanced
Included with Cost Explorer
Use Cost Explorer rightsizing for a quick "what would I save by stopping idle instances" view, and use Compute Optimizer for everything else. The performance risk scoring alone is worth the switch. Cost Explorer happily recommends downsizing an instance that hit 95% CPU for an hour on Tuesday, and Compute Optimizer flags that as Medium risk so a human reviews it.
Common pitfalls and what Compute Optimizer misses
After running this service across hundreds of accounts, here is the list of things to watch for that the marketing materials don't tell you. First, Compute Optimizer is blind to anything outside the eligible compute set. It doesn't look at NAT Gateways, CloudFront distributions, S3 lifecycle policies, RDS Aurora (only MySQL/PostgreSQL on standard RDS as of June 2026), Redshift, OpenSearch, or any networking resource. For a holistic right-sizing pass you still need the full cloud compute optimization playbook and a separate NAT gateway audit.
Second, the model assumes your workload pattern is roughly stable. It doesn't know that you're about to launch a marketing campaign, that Black Friday is in three weeks, or that you migrated a service onto the instance two days ago and the metrics are unrepresentative. Always sanity-check recommendations against business context.
Third, Compute Optimizer cannot recommend a move to a service it doesn't analyze. It won't tell you to migrate from EC2 to Fargate, or from a fleet of EC2 to Lambda. Those are architectural decisions; the service operates within the compute paradigm you've already chosen.
Finally, the order of operations matters: right-size first, then commit to Savings Plans. If you buy a 3-year all-upfront Compute Savings Plan and then right-size 30% of your fleet a month later, you're locked into committed spend you can't use. Always run a Compute Optimizer pass and act on the high-confidence findings before adjusting your commitment portfolio. Per the official AWS Compute Optimizer User Guide, the recommendations explicitly do not factor in existing Savings Plan or Reserved Instance commitments, so the savings figures shown assume on-demand pricing. For RI/SP-covered workloads, divide the headline savings by your effective discount rate to get a realistic figure. AWS also publishes the recommendation algorithm details in the AWS Compute Optimizer recommendation preferences post, and the export recommendations documentation covers the schema you'll want for Athena.
Frequently Asked Questions
Is AWS Compute Optimizer free?
Yes, the base tier of Compute Optimizer is free for all eligible resources. The optional enhanced infrastructure metrics feature, which extends the lookback window from 14 days to 3 months, costs $0.0003360215 per resource-hour, or roughly $2.94 per resource per year. There are no API call charges.
How accurate are AWS Compute Optimizer recommendations?
In my production experience, EBS gp2-to-gp3 and Lambda memory recommendations are reliable enough to action without separate benchmarking. EC2 family changes within the same architecture are usually safe at Very Low performance risk. Cross-architecture changes (x86 to Graviton) and recommendations with Medium-or-higher performance risk should be validated with application-level load tests before rollout.
Does AWS Compute Optimizer consider Savings Plans or Reserved Instances?
No, the estimated monthly savings figures assume on-demand pricing for both the current and recommended configurations. If a workload is covered by a Compute Savings Plan or Reserved Instance, you need to multiply the headline savings figure by (1 minus your effective discount rate) to get the realistic dollar impact. Always right-size before adjusting commitment coverage.
How long does Compute Optimizer take to generate recommendations?
After opting in, recommendations typically appear within 24 hours for resources that already have at least 30 hours of CloudWatch metrics. Newly launched resources take roughly 24-48 hours to accumulate enough data. Enabling enhanced infrastructure metrics doesn't delay recommendations; it adds historical depth over time as more data accumulates.
Why does Compute Optimizer show "Insufficient data" for some of my resources?
The most common causes are: the resource has been running for less than 30 hours, the resource has not been invoked or active in the last 14 days (common for cron-triggered Lambda functions), or required metrics are missing (e.g., the CloudWatch agent isn't reporting memory utilization on the EC2 instance). Install the CloudWatch agent on EC2 hosts to unlock memory-based recommendations.
Which managed PostgreSQL is actually cheapest in 2026? Side-by-side pricing for RDS, Aurora, Cloud SQL, and Azure Flexible Server across four real workloads, with commitment discounts and workload-by-workload picks.
How to cut a BigQuery bill 45-68% in 2026: choose between on-demand and Editions slots, partition and cluster correctly, use materialized views, and monitor cost with INFORMATION_SCHEMA SQL you can copy-paste.
