2026 prices for a 2017 machine: why I built CloudCostDB

Published October 25, 2026

A c5.xlarge and a c8a.xlarge look like the same machine on a spec sheet: 4 vCPUs, 8 GiB of memory. In us-east-1 the c8a costs 27% more per hour. It also does about two and a half times the work on the standard CPU benchmarks.

Instance names hide a generation gap, and the old generation is often the expensive one. I’ve watched teams pick the older instance on purpose for years, for reasons that made sense at the time. I built this site so the difference is on the page next to the price instead of buried in three other tabs.

Nobody pays full price for a 2017 car

The analogy I always reach for is a car lot. You wouldn’t pay full price for a 2017 car when the 2026 model sits on the same lot at about the same sticker. You’d expect a big discount on the old one, because you’re giving up nine years of engineering.

EC2 has no such discount. The c5 family launched in November 2017, and today a c5.xlarge costs $0.17 an hour in us-east-1. That’s the same price as a c6i.xlarge, four years newer, and more than a c8g.xlarge, seven years newer. The 2017 model never went on clearance.

A vCPU isn’t a fixed unit

The spec sheet hides the difference because “vCPU” doesn’t mean the same thing on every instance.

On Intel’s compute-optimized families, from c5 through the newest c8i, and on AMD’s up to c6a, each physical core runs two hardware threads (Intel calls this Hyper-Threading), and AWS counts each thread as a vCPU. AWS’s own example: an m5.xlarge has two cores and two threads per core, four vCPUs in total. The c5.xlarge works the same way.

Graviton instances and AMD’s c7a and newer don’t share cores this way. AWS’s C8a page says it plainly: “Each vCPU on a C8a instance is a physical CPU core.” So the c8a.xlarge and c8g.xlarge each get 4 full cores where the c5.xlarge gets 2. Two threads sharing one core add up to less than two cores.

Then the generations stack on top. Most newer chips also do more per clock and run on faster memory.

The same spec sheet, twice the work per dollar

The c8a costs more per hour, and per dollar it does about twice the work. Here are the two side by side, with c8g included for later. Prices are us-east-1 Linux on-demand. The benchmarks are the ones Vantage publishes for each instance: CoreMark is a standard CPU benchmark (higher is faster), and the ffmpeg figure is video frames transcoded per second.

The arithmetic, so you can redo it with your own pair. The c8a costs $0.21554 ÷ $0.17 = 1.27 times as much per hour. It scores 188,147 ÷ 72,684 = 2.59 times the CoreMark. Divide one by the other and each dollar buys about 2 times the CPU work. The ffmpeg number tells the same story: 68 frames per second against 27.

Sort by hourly price and the c8a loses. Sort by work per dollar and the c5 is the expensive one.

Cash in the difference by buying fewer vCPUs

A faster instance only saves money if you run less of it. If a c5.xlarge sits at 20% CPU today, a c8a.xlarge doing the same job will sit lower still, and you’ll pay 27% more for the privilege.

The savings come from sizing down. A c5.2xlarge has 8 vCPUs, which is 4 physical cores. A c8a.xlarge has 4 vCPUs, which is also 4 physical cores. Same core count, half the vCPU label, and a very different bill:

The c8a.xlarge does more CPU work than the c5.2xlarge for 37% less. It also has half the memory, and that’s the catch to check first. If the service needs its 16 GiB, the m8a.xlarge keeps the memory, still beats the c5.2xlarge on both benchmarks, and costs 28% less. (Whether you needed a C instance at all is its own question.)

Graviton: cheaper than the c5, with a different instruction set

The c8g is the second way out, and on price alone it’s the easiest call in the table. It costs less than the c5.xlarge in every one of the 29 regions that sell both, and it does about 1.7 times the CoreMark work. Graviton5 is out too: the c9g.xlarge launched in mid-2026 at $0.17388, a hair above the c5, with twice its CoreMark score. It’s sold in 8 regions so far, so the c8g is the one most teams can move to today.

The difference is the architecture. Graviton is AWS’s own Arm processor, so it runs arm64 code rather than x86. It’s a real change, and plenty of teams have made it. I’d sort the work into three piles:

• Usually just works. Code in Python, Node.js, Ruby, Java, or Go, as long as its native dependencies ship arm64 builds (the popular ones do). Managed services where AWS runs the software for you, like RDS and ElastiCache, where moving to Graviton is an instance class change rather than a code change.
• Takes some work. Container images need an arm64 build, which usually means a multi-architecture build in CI. Compiled C, C++, or Rust needs a rebuild and a test pass. Older native libraries sometimes need a version bump.
• Can block you. A vendor agent or proprietary binary that only ships for x86. Windows, which EC2 doesn’t offer on Graviton.

If most of your stack lands in the first pile, the c8g costs less per hour and does more work per dollar. The Graviton vs x86 guide walks through the move step by step, and Graviton versions covers how each generation changed the math. If the third pile applies, the c8a is the x86 route, and it usually needs nothing but a new instance type.

Newer isn’t automatically better

The generation gap is uneven, so check each pair instead of assuming the newest family wins.

Two rows break the pattern. The c6i, four years newer than the c5 and the same price, scores slightly lower on CoreMark. Its gains are elsewhere: more network bandwidth and a newer platform. And the c8i, the newest Intel family, does less work per dollar than the 2022 Graviton c7g. Like every Intel C family since c5, the c8i still counts two threads per core as two vCPUs.

Benchmarks have limits too. CoreMark is a synthetic test that mostly measures raw integer throughput on the core. It says little about memory bandwidth, disk, or network, which is why the ffmpeg column doesn’t move in lockstep with it. Use the numbers to build a shortlist, then run your own workload on the two finalists before you move a fleet.

Why old instances stick around

Teams running c5 fleets usually have a reason. Old instance types stay in service for ordinary ones:

• The template. The Terraform module, launch template, or Helm values file was written when c5 was the right answer, and nobody has had a reason to open it since.
• The commitment. Standard Reserved Instances and EC2 Instance Savings Plans are tied to an instance family, so moving off c5 early can leave a commitment underused. Compute Savings Plans aren’t tied to a family, which makes them the friendlier option if you plan to change generations.
• The binary. Something in the stack only runs on x86, which rules out Graviton (though not the newer AMD and Intel families).
• It works. A service that’s been stable for years is a reasonable thing to leave alone, right up until someone prices the alternative.

It’s common, too. Datadog’s 2024 State of Cloud Costs report found that 83% of organizations still spend an average of 17% of their EC2 budgets on previous-generation technologies. That probably undercounts the c5 problem, because AWS doesn’t call the c5 previous generation. It’s on AWS’s current-generation list, under the line “For the best performance, we recommend that you use the following instance types when you launch new instances.”

Why does AWS price old and new this way? My read, and it is a read rather than anything AWS has said: newer hardware does more work per watt and per rack, so it costs AWS less per unit of work, and pricing the new families at or below the old ones per unit of work nudges customers toward them.

Why this site exists

I spent years learning cloud pricing the hard way—deciphering offer files, running benchmarks, and discovering what the spec sheets left out only after the invoice arrived. Most of what saved me came from practitioners who took the time to write down what they learned.

I built CloudCostDB to be the reference I needed back then, and it’s still the tool I pull up daily to sanity-check decisions and explain architectures to others. This site is my way of passing that clarity back to the community.

The prices are public, but they’re spread across a dozen AWS pages, the specs live somewhere else, and the benchmarks live somewhere else again. CloudCostDB puts them on one page. Every instance page shows physical cores next to vCPUs, CoreMark and ffmpeg next to the hourly price, and the price in every region that sells it. The compare page lines up any instances you pick, side by side.

Before your next launch

An instance type is a decision, and it’s worth making again every generation or two.

1. Check the generation. The digit after the family letter (the 5 in c5, the 8 in c8a) is the generation. The newest compute families are generation 8 and 9, so a 5 or 6 deserves a second look.
2. Compare work per dollar, not price per hour. Put your current type and two newer candidates on the compare page and read the benchmark and price columns together.
3. Count physical cores. Four vCPUs can mean two cores or four. Match cores, not the vCPU label, when you size down.
4. Size down where memory allows. That’s where the newer generation turns into savings. If memory is the binding constraint, look at the M family of the same generation.
5. Check region and commitments. The c8a is sold in 7 regions in our data, against 31 for the c5 (plus four Local and Wavelength Zones). And check what your Reserved Instances or Savings Plans cover before you switch.
6. Benchmark your own workload. Run a production-like load on the old and new types before the fleet moves.