Amazon EC2 Cost Optimization

Why EC2 Bills Stay High

EC2 is usually the largest line on an AWS bill, and the waste in it has a predictable shape. Instances are sized for a launch-day guess and never revisited. Steady workloads stay on On-Demand rates for years. Commitments get bought against the oversized fleet, which turns a temporary problem into a three-year contract. And EBS volumes created before gp3 existed are still paying gp2 rates.

We work the problem in a fixed order because each step changes the baseline for the next one.

Who This Is For

This work is typically worth it when:

• EC2 and EBS together make up a large share of your AWS bill, and the fleet has not been resized since launch.
• Nearly everything runs On-Demand, or commitments were bought years ago and nobody has checked coverage and utilization since.
• You are about to renew or buy a Savings Plan and want it sized against a rightsized baseline.
• You run non-production environments around the clock.
• Your team knows the bill is high but has no time to work through the Cost and Usage Report.

It is a poor fit when your EC2 footprint is small enough that Compute Optimizer and a calculator will cover it, or when a migration is already about to replace the fleet. In both cases we will say so before you spend anything.

Step 1: Measure and Rightsize

Rightsizing starts with AWS Compute Optimizer recommendations, but we do not apply them blind. Compute Optimizer needs the CloudWatch agent to see memory, and an instance that looks idle on CPU can be memory-bound. For each candidate we check:

• p99 CPU and memory, not averages, over at least 14 days
• Burst patterns such as nightly batch or month-end jobs that a short window misses
• Instance generation, since moving from m5 to m7g or m8g often beats a size change

Memory is the usual trap. EC2 does not publish memory utilization by default, and Compute Optimizer only analyzes it when the CloudWatch agent (or a supported third-party tool) provides it. We confirm the agent is running on every candidate before trusting a recommendation. Databases, caches, and JVM services are where this matters most.

The rightsizing playbook covers the method in detail, and the rightsizing savings calculator gives a first estimate from your instance list.

Step 2: Change the Architecture Where It Pays

Graviton. Arm64 instances list below their x86 equivalents: in our pricing data (us-east-1 list price, 2026-10-17) an m7g.large is $0.0816/hr against $0.1008/hr for an m7i.large. We rebuild container images as multi-arch, benchmark each service on Graviton, and move the ones that hold their throughput. See the Graviton cost optimization guide.

Before a Graviton move, we assess each service for compatibility: whether the language runtime and base images have arm64 builds, whether native libraries and agents (APM, security, backup) ship arm64 packages, and whether the CI pipeline can build and test multi-arch images. Services that clear that check get a benchmark on your own load, and we compare throughput per dollar, not just hourly price.

Spot. For stateless and fault-tolerant capacity, Spot runs at up to 90% off On-Demand. Safe Spot use needs diversified instance types, the price-capacity-optimized allocation strategy, Capacity Rebalancing, and a shutdown handler for the two-minute notice. On EKS, Karpenter handles most of this. The Spot selection guide and the Spot instance advisor help pick pools.

EBS gp2 to gp3. gp3 is 20% cheaper per GiB-month than gp2. It includes a baseline of 3,000 IOPS and 125 MiB/s regardless of volume size, and you can provision IOPS and throughput independently of capacity. gp2 gives 3 IOPS per GiB, so a volume over 1 TiB can have a higher baseline than gp3’s default. We convert in place and set IOPS and throughput explicitly for any volume whose gp2 baseline was above 3,000 IOPS. See the orphaned volumes and snapshots guide for the cleanup side.

Idle, orphaned, and non-production resources. Unattached EBS volumes, old snapshots, unassociated Elastic IPs, and idle load balancers cost money and carry no risk to remove once an owner confirms them. Dev, test, and staging fleets that run 24 hours a day can usually be scheduled to stop outside working hours. That cuts compute hours directly, and it should happen before commitments are sized so you do not commit to capacity you plan to switch off.

Step 3: Commit Against the Smaller Baseline

Only after the fleet is rightsized and the architecture changes are in flight do we buy commitments:

Discount figures are AWS’s published maximums. Your actual rate depends on the instance family, Region, term, and payment option. Savings Plans do not reserve capacity; if you need guaranteed capacity in a zone, that takes a zonal RI or an On-Demand Capacity Reservation. We usually cover a conservative floor first, because an over-sized commitment is paid for whether or not you use it. The commitment level optimizer shows how coverage trades against utilization risk. The RI vs Savings Plans decision guide walks through the trade-offs, and the Savings Plans calculator models coverage at your spend level.

Step 4: Keep the Savings

Savings decay without guardrails. We set up AWS Budgets, Cost Anomaly Detection, and alerts on Savings Plans coverage and utilization, and hand over a monthly review checklist. For a full FinOps operating model beyond EC2, see FinOps consulting and AWS cost optimization services.

What We Cannot Promise

Savings depend on the workload, how steady its utilization is, and the availability you need. We do not promise a percentage. Rightsizing carries performance risk, which is why we check p99 and memory first. Spot adds interruptions, so it only fits workloads that tolerate them. Commitments save money only if the covered usage keeps running for the full term. Graviton needs working arm64 builds and a benchmark before it pays off.

The only figures we cite are from our published SaaS cost optimization case study: a total AWS bill moving from $85k to $58k a month ($27k a month, or $324k a year, a 32% reduction) with p99 latency unchanged. It is a composite based on anonymized client work, it covered more than EC2 (database rightsizing and NAT Gateway data transfer included), and Reserved Instance coverage was one of three tracks. Treat it as an example of the process, not a benchmark for your fleet.

Deliverables and Engagement Boundaries

You get:

• An assessment report covering fleet, commitment coverage and utilization, EBS, and idle resources.
• A prioritized backlog, with an estimated monthly dollar value per item calculated from your own Cost and Usage Report data, plus the risk and effort of each.
• Implementation of the items you approve, either as pull requests and runbooks for your team or hands-on changes under your change control.
• Governance: budgets, Cost Anomaly Detection, coverage and utilization alerts, and a monthly review checklist.

Boundaries:

• We do not buy a commitment without your written approval of the term, amount, and payment option.
• We do not resize or migrate a production workload without a rollback plan and your sign-off.
• Application code changes for arm64 compatibility are scoped separately.
• This page covers EC2 and EBS. For the whole bill, see AWS cost optimization services, and for an ongoing operating model, FinOps consulting.

Tools and Guides

Price it yourself first, then talk to us. If you want a quick look at the whole account, start with the free AWS cost audit.

Calculators

• EC2 pricing calculator
• Rightsizing savings calculator
• Graviton savings calculator
• Savings Plans calculator
• Reserved Instance calculator
• Commitment level optimizer
• Spot instance advisor
• EBS pricing calculator

Guides

• Rightsizing with Compute Optimizer
• Graviton cost optimization guide
• Reserved Instances vs Savings Plans
• Orphaned EBS volumes and snapshots
• Spot instance selection
• EC2 On-Demand pricing breakdown