EC2 Rightsizing: Cut Compute Costs Without Losing Performance

EC2 rightsizing means matching each instance's size and family to what the workload actually needs, instead of what felt safe at launch. Most instance types are chosen once and never revisited, so traffic changes, code gets more efficient, and the bill stays sized for a guess made a year ago.

I treat rightsizing as a measured change rather than a cleanup: establish a baseline, test the proposed configuration, deploy gradually, and verify both performance and cost afterwards. This guide walks through one case end to end, then the checks and mistakes that decide whether a downsize is safe.

Short answer: size from at least 30 days of CloudWatch data including peaks, with memory measured by the CloudWatch agent, not from average CPU alone. Moving to Graviton often saves as much as the size change. Check ARM64 compatibility, load-test the new instance, roll out gradually with a way back, and confirm the saving on the actual bill.

A rightsizing case: m5.2xlarge to Graviton

An illustrative case, representative of what these reviews find: a production API on EC2 behind an Application Load Balancer, running on m5.2xlarge (8 vCPU, 32 GiB, x86). Thirty days of CloudWatch metrics, including normal traffic and peak periods, showed:

• Average CPU utilisation of 12-18%.
• Peak CPU utilisation of about 45%.
• Memory utilisation of 35-50%, measured with the CloudWatch agent - EC2's standard metrics don't report memory at all.
• No sustained CPU saturation or memory pressure during traffic spikes.

The instance was oversized, and the Graviton migration offered a second saving on top of the size change. The proposed target was m7g.xlarge (4 vCPU, 16 GiB, ARM64).

What it saves

At us-east-1 Linux on-demand list prices at the time of writing (check EC2 on-demand pricing for your region):

Multiply by the number of instances behind the load balancer. I report compute savings separately from any change in data transfer, storage or other services, so the result can be checked against the bill line by line.

The two checks that decide whether it works

CPU at peak. 45% of 8 vCPUs is about 3.6 vCPUs busy at peak - roughly 90% of a 4-vCPU instance on naive arithmetic. That would be too tight. The arithmetic isn't the whole story, though: on m5, a vCPU is a hyperthread, while on Graviton every vCPU is a full physical core (see the AWS Graviton getting started guide), so per-vCPU throughput is usually higher. Only a load test settles it. The bar I use is peak CPU comfortably under about 70% on the new instance, with latency unchanged.

Memory. This is the check most often skipped when halving an instance. 35-50% of 32 GiB is 11-16 GiB; an m7g.xlarge has 16 GiB in total. At the top of that range there is no headroom left. Before committing, find out what the memory figure is made of - application heap and working set, or reclaimable cache - and watch it in the load test. If the peak working set doesn't fit with room to spare, r7g.xlarge keeps 32 GiB at 4 vCPUs and still saves about 44%.

# Peak memory over 30 days from the CloudWatch agent (dimensions depend on your agent config)
aws cloudwatch get-metric-statistics --namespace CWAgent --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-09-01T00:00:00Z --end-time 2026-10-01T00:00:00Z \
  --period 3600 --statistics Maximum \
  --query 'max(Datapoints[].Maximum)'

What I check before switching

1. Architecture compatibility. The application, container images, native dependencies and third-party agents all need to support ARM64.
2. Performance testing. Representative load tests against the Graviton build, comparing latency, throughput, CPU and memory with the existing version.
3. Peak capacity. Historical traffic peaks and autoscaling behaviour, to make sure the smaller instance keeps enough headroom.
4. Deployment and rollback. A gradual rollout - for example an Auto Scaling instance refresh or a weighted target group behind the ALB - with application and infrastructure metrics watched throughout, and the x86 version kept ready to switch back to.
5. Cost validation. Compare the actual bill and utilisation after the change, rather than relying only on the pricing estimate.

What can go wrong

Compatibility is the most easily overlooked issue. A container can build successfully for ARM64 while a native dependency, a monitoring agent or a third-party binary still assumes x86. It shows up at runtime, not at build time - which is why the load test runs the real image with the real agents installed.

Rightsizing against average CPU alone is the other. A workload can average 15% CPU and still hit latency spikes during traffic bursts, garbage collection pauses or CPU-heavy requests. Peaks, memory and latency decide the size; the average only tells you a review is worth doing.

Other rightsizing levers

• Use AWS Compute Optimizer to find candidates. It analyses CloudWatch metrics and recommends sizes for EC2, Auto Scaling groups, EBS and Lambda. Treat its output as a shortlist to verify, not a change list - it only sees memory if the CloudWatch agent is installed.
• Move to the current generation. Newer generations usually give better price-performance at the same or lower price, and the change is a new AMI and instance type rather than a redesign.
• Match the family to the bottleneck. Compute-bound services on C-family, memory-bound on R-family, general purpose on M-family. A memory-heavy workload on an M instance pays for vCPUs it never uses.
• Burstable T-family for spiky, low-average workloads such as internal tools and low-traffic APIs - priced for the average, not the peak.
• Mixed-instance Auto Scaling groups. A mixed instances policy lets the group use several compatible types instead of one fixed, oversized one.
• Commit last. Buy Savings Plans after rightsizing and the Graviton move, once the shape of the fleet has settled - committing first locks in the oversized baseline.

FAQ

How much data do I need before rightsizing an EC2 instance?

At least 30 days, including your known peak periods - month-end jobs, campaigns, batch windows. Two weeks catches the weekly cycle; it can miss the monthly one.

Why do I need the CloudWatch agent?

Standard EC2 metrics include CPU, network and disk but not memory. Without the agent you are rightsizing blind on the resource most likely to cause an outage when you shrink an instance.

Is Graviton always cheaper?

Per hour, Graviton instances are generally cheaper than the x86 equivalents, and each vCPU is a full physical core. Whether it is cheaper for your workload depends on ARM64 support across your whole stack and on how the workload performs - which is what the load test measures.

Should I rightsize before or after buying Savings Plans?

Before. A commitment made on the oversized fleet carries that waste for one or three years.

How do I know the saving was real?

Compare the EC2 line on the bill for the same number of instance-hours before and after, and keep compute separate from other line items. Pricing estimates are a forecast; the bill is the result.

Want your fleet reviewed?

Rightsizing with real metrics, peak checks and a rollback plan is part of every AWS cost optimization engagement I run. For where compute fits in the overall order of work, see the AWS cost optimization guide; the same method applied to databases is in the RDS right-sizing guide.

Sources

• Amazon EC2 on-demand pricing
• AWS Graviton getting started guide - vCPU model and porting guidance
• Metrics collected by the CloudWatch agent - memory metrics
• AWS Compute Optimizer
• Auto Scaling instance refresh and mixed instances groups