Cutting Your AWS Bill with Graviton & Savings Plans

If your AWS bill is climbing, two levers give the biggest return for the least effort: moving workloads to Graviton (AWS's ARM chips) and committing steady usage with Savings Plans. Together they routinely cut compute spend 30-50%. Here's how to use both well.

Graviton: better price/performance for free-ish

Graviton is AWS's own ARM-based processor. Compared to equivalent x86 instances, you typically get ~20% lower cost and better performance per dollar: for workloads that run on ARM.

What runs on Graviton today: most modern languages and runtimes (Go, Rust, Node, Python, Java, .NET), containers (build multi-arch images), and managed services (RDS, ElastiCache, OpenSearch, Lambda) that offer Graviton options.

The migration:

1. Check your dependencies are ARM-compatible (most are; native binaries are the thing to verify).
2. Build multi-arch container images (docker buildx --platform linux/amd64,linux/arm64).
3. Test on a Graviton instance/node pool alongside x86.
4. Shift gradually: a Graviton node group in EKS, or switch RDS instance class, and compare metrics + cost.

For managed services it's often just changing the instance type. For your own containers it's a multi-arch build away.

Savings Plans: pay less for what you'll use anyway

On-demand pricing is the "no commitment" premium. If you run a steady baseline of compute, you're overpaying for it. Savings Plans give up to ~72% off in exchange for committing to a consistent spend (measured in $/hour) for 1 or 3 years.

• Compute Savings Plans: most flexible: apply across EC2, Fargate, and Lambda, any region, any instance family. Start here.
• EC2 Instance Savings Plans: deeper discount but locked to an instance family/region.
• Reserved Instances: the older mechanism; Savings Plans are usually the better choice now.

The strategy: commit to your baseline (the floor you always run), and let everything above it run on-demand or spot. Don't over-commit, an unused commitment is wasted money. Look at your last few months of usage and commit to roughly the steady floor, not the peak.

Stacking the levers

These compound:

1. Right-size first (don't commit to oversized instances, see my AWS cost guide).
2. Move the baseline to Graviton for the per-unit discount.
3. Cover that baseline with a Compute Savings Plan for the commitment discount.
4. Burst on spot/on-demand above the baseline.

Right-sizing × Graviton × Savings Plans is multiplicative, not additive, each one shrinks what the next is applied to.

Watch-outs

• Don't commit before right-sizing: you'd lock in waste.
• Verify ARM compatibility in a test environment before a wide Graviton rollout.
• Track Savings Plan utilization: aim for high coverage without over-committing.
• Re-evaluate quarterly as usage changes.

These two levers are about the highest ROI in AWS cost work: a multi-arch build and a well-sized commitment can knock a third or more off your compute bill, durably.

---

Want your AWS bill brought under control? Cloud cost optimisation is part of my consulting work, reach out.