Guides · EC2
Three EC2 problems are worth checking: instances doing almost nothing, instances much bigger than their load needs, and instances on older families that cost more than newer ones. All three show up in data you already have: CloudWatch CPU metrics and AWS's own price list.
In the m5 family, each size up doubles the price. An m5.large is $0.096 an hour ($70.08 a month), an m5.xlarge is $0.192 ($140.16) and an m5.2xlarge is $0.384. So:
Same size, newer family:
| Running today | Per month | Newer x86 | Per month | Graviton | Per month |
|---|---|---|---|---|---|
| m4.large | $73.00 | m6a.large | $63.07 | m6g.large | $56.21 |
| c4.xlarge | $145.27 | c6a.xlarge | $111.69 | c7g.xlarge | $105.85 |
| t2.medium | $33.87 | t3.medium | $30.37 | t4g.medium | $24.53 |
Hourly prices: m4.large $0.10, m6a.large $0.0864, m6g.large $0.077; c4.xlarge $0.199, c6a.xlarge $0.153, c7g.xlarge $0.145; t2.medium $0.0464, t3.medium $0.0416, t4g.medium $0.0336. Monthly figures use AWS's 730-hour month.
AWS lists M4, C4 and R4, along with M1, M2, M3, C1, C3, R3, T1, I2, A1, G3, P3 and P3dn, as previous generation. It recommends current-generation types for the best performance. T2 is still listed as current generation, but T3 is cheaper at the same size, and the Graviton-based T4g is cheaper still.
Graviton instances (the "g" families such as m6g, c7g and t4g) use AWS-designed Arm-based processors. Linux distributions such as Amazon Linux 2, Red Hat Enterprise Linux, SUSE and Ubuntu support them. Software has to run on Arm, so containers need arm64 images and native binaries need Arm builds.
1. List running instances and their types:
aws ec2 describe-instances --region us-east-1 \
--filters Name=instance-state-name,Values=running \
--query 'Reservations[].Instances[].[InstanceId,InstanceType,Tags[?Key==`Name`].Value|[0]]' --output table2. Pull 14 days of CPU for each one, as daily average and daily peak:
aws cloudwatch get-metric-statistics --region us-east-1 --namespace AWS/EC2 \
--metric-name CPUUtilization --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-09-19T00:00:00Z --end-time 2026-10-03T00:00:00Z \
--period 86400 --statistics Average Maximum --output tableIn the console: EC2 → Instances → select an instance → Monitoring tab, and set the time range to two weeks.
3. Read the numbers. These are the thresholds the checkup uses. They're rules of thumb, not AWS guidance:
4. Check memory before you resize. CPU isn't the only constraint. Compute Optimizer only includes memory when it gets memory metrics: from the CloudWatch agent, or from a supported monitoring tool (AWS lists Datadog, Dynatrace, Instana and New Relic). Without those, run free -m on the box.
5. Turn on AWS Compute Optimizer. It's free. It analyzes the last 14 days of CloudWatch metrics and recommends instance types, and it includes memory if it gets memory metrics (the CloudWatch agent or a supported monitoring tool). Console: Compute Optimizer → Get started.
The free checkup finds this and 20 other kinds of issues automatically. It reads 14 days of CPU data for every running instance in every region you use, and applies the idle and oversized thresholds above. Where Compute Optimizer marks an instance over-provisioned, it uses AWS's recommended type instead. It then compares t, m, c and r instances with the cheapest same-size newer x86 and Graviton types. Each step is priced on what's left after the one before, so savings don't double count.
Prices are AWS on-demand list prices for US East (N. Virginia), checked October 3, 2026. Other regions, operating systems and licensed software are priced differently. Savings Plans or reservations you already hold change the numbers.