All posts
Cost Optimization

Still on m4, c4, t2 or m5? Moving Old EC2 Generations to Graviton and Current Intel

By

October 25, 2026

6 min read

Old instance families cost the same or more than current ones and deliver less. A current Graviton instance is usually 15–20% cheaper at list price than the Intel generation many fleets still run, before any performance gain. What moves easily, what does not, and how to do it without a big-bang migration.

EC2
Graviton
Cost Optimization
Upgrades
Instance Types

Instances launched years ago keep running on the family they were launched with. Nobody changes them because nothing is broken. Meanwhile each new generation has been faster, and Graviton has been cheaper per hour.

List prices for a 2 vCPU, 8 GiB instance

Instance

Generation

US East Linux on-demand

m4.large

Intel, 2015

$0.100/hour

m5.large

Intel, 2017

$0.096/hour

m6g.large

Graviton2

$0.077/hour

m7g.large

Graviton3

$0.0816/hour

From the EC2 on-demand pricing page. Newer generations are typically faster per vCPU as well as cheaper or similar per hour. Graviton4 (the 8g families) and Graviton5 (R9g, from September 2026) are newer still.

Want a second opinion on this for your system?

Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.

What moves easily

  • Anything on a managed runtime with Arm support: Lambda, Fargate, RDS, Aurora, ElastiCache and OpenSearch can move to Graviton with a setting change and a test.

  • Interpreted and JIT languages: Node.js, Python, Java, .NET, Ruby and PHP run on Arm without code changes, provided native dependencies have Arm builds.

  • Containers built as multi-architecture images.

What needs work

  • Windows workloads: Graviton runs Linux. Move to current Intel or AMD generations instead, or port to modern .NET on Linux first.

  • Native binaries and third-party agents without Arm builds. Check your security and monitoring agents early.

  • Software licensed per core or tied to x86.

How we do it

  1. Start with managed services (RDS, ElastiCache, Lambda), which are usually a setting change, then stateless services behind load balancers.

  2. Build multi-architecture container images in CI so a service can run on either architecture.

  3. Run a canary: a share of capacity on Graviton, compare latency and error rates, then shift the rest.

  4. Revisit Savings Plans after the move; Compute Savings Plans follow you across families, EC2 Instance Savings Plans do not.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.