Rightsizing EC2 Instances in AWS

Most AWS accounts have instances that are two or three sizes too large. Engineers provision conservatively — which makes sense — but revisiting that sizing once the actual workload is known is not always a priority. The result is thousands of dollars per month in unused compute.

Why over-provisioning happens

Over-provisioning is rational at launch time. When you’re setting up a new service, you don’t know the exact CPU, memory, and network requirements. The consequences of being too small (slow responses, OOM errors, dropped requests) are worse than being too large (wasted money). So teams provision large and plan to review later.

“Later” rarely happens. Once a service is running and stable, there’s no urgent reason to resize it. The instance is working. The team moves on to other work. The over-provisioned instance runs at 8% CPU for two years.

At scale, this adds up quickly. Twenty m5.2xlarge instances running at 8% average CPU:

  • Current cost: 20 × $0.384/hr × 730hr = $5,606/month
  • After rightsizing to m5.medium: 20 × $0.048/hr × 730hr = $701/month
  • Saving: $4,905/month — without changing any code or architecture

That’s a real finding from an actual AWS Compute Optimizer report. The savings were there for two years before anyone looked.

AWS Compute Optimizer

AWS Compute Optimizer is a free service that uses machine learning to analyse 14 days of CloudWatch metrics — CPU utilisation, memory utilisation (requires CloudWatch agent), network I/O, and disk I/O — and recommends appropriately sized resources.

Compute Optimizer covers:

  • EC2 instances
  • Auto Scaling Groups
  • EBS volumes
  • Lambda functions
  • ECS tasks on Fargate

To see recommendations via the AWS CLI:

# Get EC2 instance recommendations for your account
aws compute-optimizer get-ec2-instance-recommendations \
  --region us-east-1

# Get recommendations for a specific instance
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0

The output for each instance includes:

  • Current instance type and finding (e.g., “OVER_PROVISIONED”)
  • Recommendation options (up to 3 alternative instance types)
  • Estimated monthly savings per option
  • Performance risk rating (Low, Medium, High)

Reading Compute Optimizer recommendations

Each recommendation includes a finding and finding reason codes:

Findings:

  • OVER_PROVISIONED — the instance is larger than needed based on utilisation
  • UNDER_PROVISIONED — the instance is too small and is approaching resource limits
  • OPTIMIZED — the instance size appears appropriate
  • NOT_OPTIMIZED — not enough data or mixed signals

Finding reason codes explain what metric is out of range:

  • CPUOverprovisioned — CPU utilisation is consistently low
  • MemoryOverprovisioned — memory utilisation is consistently low (requires CloudWatch agent for memory metrics)
  • NetworkBandwidthOverprovisioned — network I/O is very low
  • DiskIOPSOverprovisioned — disk IOPS are much lower than available

Compute Optimizer uses p99 percentile metrics, not just averages. A recommendation to downsize includes the confidence that peak usage would still fit within the recommended instance’s capacity.

The performance risk field tells you how confident Compute Optimizer is:

  • Low risk — the recommendation has high confidence; peak usage is well within the new instance’s capacity
  • Medium risk — there are some peak periods that approach the recommended instance’s limits
  • High risk — downsize with caution; test thoroughly before applying to production

The Graviton opportunity: rightsize and switch architecture

Rightsizing alone can save 50–75% on over-provisioned instances. Combining rightsizing with a move to Graviton (ARM-based) instances can push savings to 60–80%.

Compute Optimizer recommends Graviton instances when they are likely to provide equivalent or better performance at lower cost. For a workload on m5.2xlarge ($0.384/hr) that is over-provisioned:

  • Rightsize to m5.large (same x86 family): $0.096/hr — 75% saving
  • Rightsize AND move to m6g.large (Graviton): $0.077/hr — 80% saving
  • Move to m7g.large (Graviton 3): ~$0.082/hr — often faster at 79% saving

For Linux workloads in Python, Node.js, Java, or Go: Graviton compatibility is almost always achievable. The migration is: build your application image/binary for ARM64, test on Graviton in staging, deploy to production.

Compute Optimizer’s “enhanced infrastructure metrics” (a paid option for $0.0003360/instance-hour) provides more granular data including GPU, disk, and network metrics, which gives more accurate recommendations for large fleets.

Rightsizing RDS instances

The same over-provisioning pattern applies to RDS. A team might start with a db.r5.2xlarge for the expected database load, find that average CPU is 7%, and leave it running at over $600/month.

Compute Optimizer does not currently analyse RDS instances (it covers EC2, EBS, Lambda, and ECS). For RDS rightsizing, use:

  • CloudWatch metrics: CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS
  • Performance Insights: identifies query-level bottlenecks and actual resource consumption
  • RDS Recommendations in the RDS console: AWS now provides some rightsizing guidance directly in the console

RDS rightsizing carries the same caution as EC2: verify peak load, not just average. A database at 5% average CPU may spike to 90% during reporting runs.

To resize an RDS instance:

aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --db-instance-class db.r5.large \
  --apply-immediately

Note: --apply-immediately causes a brief outage. Without it, the change applies during the next maintenance window.

Establishing a utilisation baseline first

Before rightsizing, you need sufficient data. Compute Optimizer requires at least 14 days of CloudWatch metrics. For accurate recommendations, 30 days or more is better — it captures weekly patterns (month-end reporting runs, weekly batch jobs, etc.).

Key CloudWatch metrics to review before rightsizing:

# Get EC2 CPU statistics for the last 30 days
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2026-02-17T00:00:00Z \
  --end-time 2026-03-19T00:00:00Z \
  --period 86400 \
  --statistics Average Maximum \
  --output table

Look at both the average AND the maximum. An instance with 8% average CPU but 75% maximum is not safe to aggressively downsize. An instance with 8% average and 15% maximum can safely go to a much smaller size.

Memory metrics require the CloudWatch agent to be installed on EC2 instances — CPU and network metrics are collected by default, but memory is not. Enable the CloudWatch agent on instances you plan to rightsize to get full utilisation visibility.

Scheduling quarterly rightsizing reviews

Rightsizing is not a one-time activity. Traffic patterns change. Services grow. New features add load. Features get removed. An instance appropriately sized in January may be over-provisioned by July.

A practical cadence: run get-ec2-instance-recommendations at the start of each quarter and review findings for every service. Assign ownership of the review to whoever owns the service. For services running more than $500/month, the review is justified even if it saves only 10%.

Automate the data collection:

# Export all recommendations to a file
aws compute-optimizer get-ec2-instance-recommendations \
  --region us-east-1 \
  --output json > compute-optimizer-recommendations.json

Then use a simple script or jq to extract the instances flagged as OVER_PROVISIONED and their estimated monthly savings.

Note: When rightsizing, change one instance at a time, not the entire fleet simultaneously. If a rightsized instance shows unexpected performance problems, you want to know which instance was the cause. Roll out rightsizing changes gradually, monitor for 24–48 hours, then proceed with the next instance.

Common mistakes

  1. Rightsizing based on averages alone — An instance at 5% average CPU may spike to 90% during a daily batch job. Use peak (maximum) metrics alongside averages. Compute Optimizer handles this with p99 percentile data, but if you’re doing manual analysis, look at maximum as well.
  2. Not enabling memory metrics — Without the CloudWatch agent, memory utilisation is invisible. An instance may have plenty of CPU headroom but be memory-constrained. Enable the CloudWatch agent before making rightsizing decisions.
  3. Applying all rightsizing recommendations at once — Changing the instance type of 50 instances simultaneously means if something breaks, you don’t know which change caused it. Rollout changes incrementally.
  4. Rightsizing without testing at peak load — Dev and staging traffic patterns are usually much lighter than production. Test rightsized instances under production-equivalent load before applying widely.
  5. Ignoring RDS and Lambda — EC2 is the obvious target, but RDS instances and Lambda memory settings also benefit from rightsizing. Check Compute Optimizer’s Lambda recommendations too.

Summary

  • Over-provisioning is rational at launch time but creates ongoing waste — the fix is periodic review
  • AWS Compute Optimizer analyses 14+ days of CloudWatch metrics and flags over-provisioned instances
  • Use p99 percentile metrics (or check both average and maximum) to ensure peak load fits in the smaller size
  • Rightsizing to Graviton at the same time can push savings from 50% to 70–80%
  • Memory metrics require the CloudWatch agent — enable it before making rightsizing decisions
  • RDS rightsizing uses CloudWatch metrics and Performance Insights rather than Compute Optimizer
  • Schedule quarterly rightsizing reviews and automate data collection with the AWS CLI

Related topics to read next

Rightsizing connects to broader EC2 cost optimisation and CloudWatch monitoring.

  • EC2 cost optimisation — rightsizing is one of several EC2 cost levers — this page covers all of them together.
  • CloudWatch overview — understand CloudWatch metrics and how to set up the agent for memory utilisation tracking.
  • Identifying expensive resources — find which specific resources are worth rightsizing and which are already optimised.
  • EC2 overview — EC2 instance families and what each is optimised for.

Frequently asked questions

What is AWS Compute Optimizer?

AWS Compute Optimizer is a free service that analyses CloudWatch metrics for your EC2 instances, Auto Scaling Groups, Lambda functions, EBS volumes, and ECS services, and recommends better-sized resources based on actual utilisation patterns. It uses machine learning on 14 days of metrics data.

Is rightsizing risky?

Done carefully, no. The risk comes from using only average CPU as the metric — a server at 5% average but 95% peak needs a size that handles the peak. Compute Optimizer uses p99 percentile metrics, not just averages, and flags instances where peak usage approaches the current capacity.

How much can rightsizing save?

Savings vary widely. Teams that have never reviewed instance sizes often find 30–60% savings. A common finding is instances running at 5–15% average CPU that could comfortably run on an instance one or two sizes smaller. At scale, rightsizing is often the single largest cost reduction lever available.

Last verified: 19 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.