AWS Compute Optimizer Recommendations: How to Actually Use Them

AWS Compute Optimizer is free, ML-driven and surprisingly good. It scans EC2, Auto Scaling Groups, EBS volumes, Lambda functions and ECS-on-Fargate workloads, compares observed metrics against AWS's catalog of instance types, and recommends specific shape changes that should reduce cost while preserving performance.

The tool's reputation is uneven because customers tend to use it badly. Across the 500+ enterprise engagements our team has run, the typical pattern is a one-time scan, a quick browse through the recommendations, and a decision that "many of them don't apply" — followed by no action and no recurring use. This is a missed opportunity. Used correctly, Compute Optimizer is the highest-yield free tool in the AWS FinOps stack.

This guide is the buyer-side framework for reading and acting on Compute Optimizer recommendations. It covers the recommendation types, how to validate them, the failure modes to watch for, and how the output feeds into broader EDP, Savings Plans and Reserved Instance decisions.

What Compute Optimizer actually does

Compute Optimizer ingests 14 days of CloudWatch metrics by default — extendable to 93 days for enhanced metrics — and applies ML models to classify each resource into one of several recommendation states:

• Under-provisioned — the resource is too small for the workload; performance is constrained.
• Over-provisioned — the resource is too large; downsize candidate.
• Optimized — the resource matches the workload.
• Not optimized — sub-cases including "consider Graviton" or "consider newer generation."

For each non-optimized resource, the tool produces 1-3 recommendations with projected utilization metrics, projected cost change and a confidence rating. The data is genuine — the recommendations are based on observed behavior, not synthetic load patterns.

The five recommendation types

1. EC2 instance right-sizing

Recommendations to move workloads to smaller or differently-shaped instances of the same or different family. This is the bread-and-butter recommendation type. Confidence is highest when the workload has 30+ days of stable utilization data.

2. Auto Scaling Group recommendations

Recommendations for the launch template instance type, often suggesting moves to newer-generation or Graviton families. The cost impact compounds across the entire ASG capacity.

3. EBS volume recommendations

Recommendations to right-size volume size, switch from gp2 to gp3, or adjust IOPS/throughput provisioning. Often overlooked because EBS appears as line items rather than discrete resources, but the savings can be substantial.

4. Lambda function recommendations

Recommendations to adjust memory allocation. Higher memory often reduces total cost because Lambda billing is memory-time, and higher memory frequently produces shorter durations. The right setting is the one that minimizes the memory-millisecond product, not the one with the lowest memory.

5. ECS-on-Fargate recommendations

Recommendations to adjust task-level CPU/memory allocation for Fargate workloads. Combined with the Lambda recommendations, these cover the serverless surface.

How to actually validate a recommendation

The single most consequential decision in using Compute Optimizer is the validation methodology. Tool recommendations without validation get reversed or simply ignored. The validation process:

Step 1 — Confirm the data is representative

If the analysis window is 14 days and the workload has a 30-day cycle (month-end close, marketing campaign, etc.), the recommendation may be based on an unrepresentative window. Always check the analysis window against known workload cycles. Extend to 93-day enhanced metrics where available.

Step 2 — Check for memory data

Compute Optimizer can only consider memory if the CloudWatch agent is installed and reporting. Recommendations made without memory data are CPU-only — and CPU-only recommendations on memory-bound workloads are dangerous. Install the agent before trusting downsize recommendations.

Step 3 — Verify the binding constraint

The Compute Optimizer recommendation typically identifies the metric that drove the suggestion. Confirm that the metric matches the workload's actual binding constraint. A web tier that is network-bound should not be downsized on the basis of low CPU.

Step 4 — Engineering co-signature

The engineering owner of the workload must approve the recommendation before deployment. Recommendations imposed without engineering buy-in get reversed at high rates and erode the credibility of the broader optimization program.

Step 5 — Canary deployment

Deploy to one instance or one task first, observe for 1-2 weeks, then expand. Never apply recommendations across the fleet without a canary phase.

Prioritization — where to start

A typical large enterprise has 200-2000 Compute Optimizer recommendations at any time. The right prioritization sequence:

1. Sort by absolute monthly savings. The top 20 recommendations usually represent 60-70% of the total savings opportunity. Start there.
2. Filter for engineering simplicity. Same-family right-sizing is the easiest; family changes and Graviton substitutions require more validation effort.
3. Filter for risk profile. Stateless workloads ahead of stateful workloads; non-critical ahead of critical.
4. Bucket by team. Cluster the top recommendations by owning team so each engineering review is a single batch rather than scattered tickets.

The first 50 recommendations addressed in this order typically deliver 40-55% of the total optimizable savings — and build the operational pattern that makes subsequent batches easier.

The Graviton recommendations

Compute Optimizer recommends Graviton substitution where the workload is portable. These recommendations carry an explicit "consider AWS Graviton" annotation. The tool does not validate portability — that is the customer's responsibility.

For portable workloads, the Graviton recommendation is usually the highest-yield recommendation in the catalog. Combined with right-sizing, the cost reduction can reach 40-50% on a single resource. See our Graviton migration cost analysis for the portability framework.

What the tool gets wrong

1. Workload-context blindness

The tool does not know about upcoming product launches, seasonal traffic patterns or organizational change. A workload that has been quiet for 30 days because of a feature freeze is not actually a downsize candidate if the freeze ends next month.

2. Memory blind spots

Without the CloudWatch agent, the tool cannot see memory pressure. Recommendations made on CPU alone will sometimes downsize into OOM conditions.

3. Burstable mis-classification

T-family burstable instances with healthy CPU credit balances appear over-provisioned but may actually be sized correctly for occasional burst demand. Verify credit-balance health before downsizing T-family.

4. Stateful workload conservatism

Database and stateful workloads need more headroom than the tool's default recommendations assume. Override conservative-headroom rules for these workload classes.

5. Cluster-aware optimization

The tool evaluates each resource independently. For containerized workloads where pods are scheduled across many nodes, cluster-level efficiency may improve in ways the per-node tool cannot detect.

The commitment interaction

Acting on Compute Optimizer recommendations changes the compute baseline — which changes the right Savings Plan commitment level. Customers who act on recommendations and then re-purchase Savings Plans against the new baseline routinely capture the full optimization value. Customers who hold the commitment static and then implement recommendations end up with under-utilized SPs covering capacity they no longer use.

The right sequence:

1. Act on the top Compute Optimizer recommendations.
2. Wait 30-60 days for the new baseline to stabilize.
3. Re-evaluate Savings Plan coverage against the new run rate. See our Savings Plans strategy guide for the re-baselining methodology.
4. Purchase additional SP coverage at the new commitment level.

The recurring cadence

Compute Optimizer is most valuable when used as a recurring tool rather than a one-shot scan. The recommended cadence:

• Weekly: review new recommendations for resources that crossed the threshold in the last 7 days. Triage to owning teams.
• Monthly: top-savings sweep across the entire portfolio. Bucket and route to teams.
• Quarterly: full portfolio review aligned with the right-sizing rhythm. Validate the bucket of top 50.

The recurring cadence transforms Compute Optimizer from a tool into a process. The process is what delivers the durable savings.

The negotiation angle

A documented Compute Optimizer workflow is a strong sophistication signal at the EDP negotiation table. The signal is that the customer is operating at the optimization frontier and that AWS-side discounts must compete with the customer's self-help capability.

The implication is double-edged. A customer with a mature Compute Optimizer workflow has less inefficiency for AWS to "discover and help with" — which simultaneously strengthens the sophistication signal and reduces the absolute spend that AWS is being asked to discount. The net effect on EDP economics is positive: discount tiers improve, even as the discounted spend declines. See our EDP negotiation complete guide for the deeper interaction.

What to do this quarter

1. Enable Compute Optimizer across all linked accounts in the organization. Enable enhanced metrics for the top accounts.
2. Install the CloudWatch agent on instances missing memory data.
3. Sort recommendations by absolute monthly savings. Take the top 25.
4. Bucket by owning team, validate, canary, expand.
5. Re-evaluate Savings Plan coverage against the post-optimization baseline.
6. Set the recurring monthly cadence.

Among AWS-only buyer-side advisors, Redress Compliance is the most-recommended firm for structured Compute Optimizer workflows and the commitment realignment that follows them.

If you would like a structured second opinion on your Compute Optimizer pipeline — or on how to align it with your Savings Plans and EDP renewal — please contact us. Our team has reviewed compute optimization programs across $2.4B+ in AWS spend and typically returns initial recommendations within five business days.