AWS Compute Optimizer

Picking the right size for a server is hard. Choose too big and you pay for capacity you never use; choose too small and your app gets slow or crashes. AWS Compute Optimizer is a free service that watches how your resources actually behave over time and uses machine learning (ML, where software learns patterns from data) to recommend a better-fitting size. It looks at your real usage history and tells you, for example, “this EC2 instance is over-provisioned, switch to a smaller type and save 40% a month.”

What Compute Optimizer does

Compute Optimizer reads the usage history that AWS already collects in Amazon CloudWatch (the AWS monitoring service that stores metrics like CPU and network usage). It then compares your real load against the catalog of available resource types and suggests the option that fits your workload with the least waste, along with a projected dollar saving.

It covers several resource families:

Resource	What it recommends	Why it matters
EC2 instances	A better instance type/size (e.g. m5.2xlarge to m5.large)	The biggest single line item for most teams
Auto Scaling Groups (ASGs)	A better instance type for the whole group	Rightsizing a fleet multiplies the savings
EBS volumes	Better volume type/size/IOPS (e.g. gp2 to gp3)	gp3 is usually cheaper and faster than gp2
Lambda functions	A better memory setting	Lambda CPU scales with memory, so this affects speed and cost
ECS services on Fargate	Better task CPU/memory	Avoids paying for idle Fargate capacity

An EC2 instance is a virtual server. An Auto Scaling Group is a managed pool of identical instances that grows and shrinks with demand. EBS (Elastic Block Store) is the virtual hard disk attached to an instance. Lambda runs your code without you managing servers. Fargate runs containers without you managing servers.

When to use this (and when not to)

Use Compute Optimizer when you have resources that have been running for at least two weeks under a normal, representative load and you want to cut cost without guessing. It is the natural first step before buying Savings Plans or Reserved Instances, because there is no point committing to a one-year discount on an instance that is twice as big as it needs to be.

Do not rely on it for brand-new resources, for short-lived batch jobs, or for a workload you know is about to grow. Its recommendations are only as good as the history it has seen.

Enabling Compute Optimizer

The service is opt-in. You turn it on once per account (or for an entire AWS Organization), then wait for it to analyze your metrics.

Console steps

1. Open the AWS Management Console and go to the Compute Optimizer service.
2. On the landing page, choose Get started.
3. Under Account, choose whether to opt in only this account or all accounts in your organization.
4. Choose Opt in.
5. Wait. Initial findings appear within hours, but accurate recommendations need about 14 days of metric history.

CLI equivalent

The AWS CLI (Command Line Interface, the terminal tool for controlling AWS) uses the update-enrollment-status call. This assumes AWS CLI v2 is installed and configured.

aws compute-optimizer update-enrollment-status \
  --status Active

Output:

{
    "status": "Active",
    "statusReason": "Compute Optimizer is being enabled. It can take up to 24 hours for the first recommendations to appear."
}

Reading EC2 recommendations

Each recommendation gives a finding (one of Underprovisioned, Overprovisioned, Optimized, or NotOptimized), up to three suggested options, and the projected monthly cost of each.

Console steps

1. In the Compute Optimizer console, open EC2 instances in the left menu.
2. Review the Finding column to spot Over-provisioned instances (these waste money).
3. Click an instance to see the recommended options and the estimated monthly savings.
4. Compare the current instance against the suggested types, then apply the change through EC2 (stop, change instance type, start).

CLI equivalent

aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:111122223333:instance/i-0a1b2c3d4e5f

Output:

{
    "instanceRecommendations": [
        {
            "instanceArn": "arn:aws:ec2:us-east-1:111122223333:instance/i-0a1b2c3d4e5f",
            "currentInstanceType": "m5.2xlarge",
            "finding": "Overprovisioned",
            "recommendationOptions": [
                {
                    "instanceType": "m5.large",
                    "performanceRisk": 1.0,
                    "rank": 1
                }
            ],
            "utilizationMetrics": [
                { "name": "CPU", "statistic": "MAXIMUM", "value": 11.4 }
            ]
        }
    ]
}

A finding of Overprovisioned with a max CPU of 11% means you are paying for roughly 8x the compute you use. Moving from m5.2xlarge (about $277/month on-demand in us-east-1) to m5.large (about $69/month) saves roughly $208 per instance per month.

The two big gotchas

Recommendations need about 14 days of metrics, and they assume the past predicts the future. Compute Optimizer sizes you for the load it has already seen. If you apply a “downsize” recommendation to a service that is about to get a marketing launch or a seasonal spike, you can under-size it and cause outages. Always sanity-check a recommendation against what you know is coming, not just what already happened.

By default EC2 recommendations are based on CPU and network only, not memory. A box can look idle on CPU while its RAM is nearly full. Turn on enhanced infrastructure metrics (and install the CloudWatch agent so memory is actually reported), or Compute Optimizer may recommend a smaller instance that promptly runs out of memory.

Enhanced infrastructure metrics extend the look-back window to three months and are part of the paid recommendation preferences. To enable them via CLI:

aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --enhanced-infrastructure-metrics Active \
  --scope name=AccountId,value=111122223333

Output:

{
    "ResponseMetadata": {
        "HTTPStatusCode": 200
    }
}

Lambda memory recommendations

For Lambda, the only knob is memory, but memory also controls CPU and pricing. Compute Optimizer flags functions as MemoryUnderprovisioned, MemoryOverprovisioned, or Optimized.

aws compute-optimizer get-lambda-function-recommendations \
  --function-arns arn:aws:lambda:us-east-1:111122223333:function:process-orders

Output:

{
    "lambdaFunctionRecommendations": [
        {
            "functionArn": "arn:aws:lambda:us-east-1:111122223333:function:process-orders",
            "currentMemorySize": 1024,
            "finding": "Overprovisioned",
            "memorySizeRecommendationOptions": [
                { "memorySize": 512, "rank": 1, "projectedUtilizationMetrics": [] }
            ]
        }
    ]
}

Halving memory from 1024 MB to 512 MB roughly halves the per-millisecond Lambda cost for that function, as long as the function still runs fast enough.

Best Practices

• Opt in early and wait at least 14 days before acting, so recommendations reflect a full weekly cycle of traffic.
• Enable enhanced infrastructure metrics and install the CloudWatch agent so EC2 recommendations account for memory, not just CPU.
• Rightsize first, then commit. Clean up over-provisioned resources before buying Savings Plans or Reserved Instances.
• Treat every downsize as a hypothesis: check upcoming launches or seasonal demand before applying it to production.
• Prefer migrating EBS gp2 volumes to gp3 when recommended, it is usually cheaper and faster with no downtime.
• Review recommendations on a regular schedule (monthly) since workloads drift over time.

Related Topics

• Cost optimization
• Trusted Advisor
• Savings Plans & Reserved Instances
• Cost Explorer
• How AWS pricing works