← Blog
#AWS#Cloud Infrastructure#Graviton#EC2#Cost Optimization

AWS Graviton5 Lands in C9g Instances — Is It Worth the Migration?

webhani·

What shipped

AWS announced new EC2 C9g and C9gd instance families built on Graviton5, its fifth-generation Arm-based processor. According to AWS, the new instances deliver up to 25% better compute performance than Graviton4-based instances, a 5x larger cache, and the fastest memory of any processor instance currently offered in the cloud. The "d" variant (C9gd) adds local NVMe storage, following AWS's usual naming convention for instances with attached instance store.

C-family instances are compute-optimized: batch processing, media encoding, high-throughput web and API tiers, gaming servers, and scientific simulation are the classic fits. If your workload is CPU-bound rather than memory- or I/O-bound, this is the family where a generational jump shows up fastest on your bill.

Why this matters beyond the spec sheet

Every Graviton generation announcement reads similarly — "faster, cheaper, more efficient" — and it's easy to let that become background noise. The number that actually matters for a migration decision is not the vendor's benchmark, it's your own price-performance ratio on your own workload. A 25% compute uplift only translates into savings if your workload is actually compute-bound on the current generation; if you're bottlenecked on network I/O or disk, more raw CPU compute buys you very little.

The other detail worth taking seriously is the "fastest memory" and "5x larger cache" claims. Bigger cache in particular tends to matter disproportionately for workloads with large working sets that don't fit cleanly in previous-generation cache — things like in-memory data processing, some categories of search indexing, and JIT-heavy runtimes. If your current C-family instances show high cache-miss rates in profiling, this generation is worth benchmarking specifically for that reason, independent of the headline compute number.

A migration checklist, not a leap of faith

Moving to a new Graviton generation is usually low-risk if you've already migrated once (from x86 to an earlier Graviton generation), since the Arm64 compatibility work is already done. If this would be your first move to Arm64, budget real time for it. A practical sequence:

  1. Confirm Arm64 compatibility for your full dependency tree, not just your application code — native modules, base images, and any vendored binaries need Arm64 builds.
  2. Build multi-architecture images so you can run the same pipeline against both architectures during evaluation.
  3. Benchmark on your actual workload, not a synthetic one — a load test replaying real traffic patterns tells you far more than a generic CPU benchmark.
  4. Roll out gradually behind your existing autoscaling group, watching cost-per-request and p99 latency side by side with the current fleet.
# Multi-arch build so the same Dockerfile targets both
# the current fleet and a Graviton5 evaluation fleet.
FROM --platform=$BUILDPLATFORM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
 
FROM node:22-slim
WORKDIR /app
COPY --from=build /app ./
CMD ["node", "dist/server.js"]
# Build and push for both architectures in one pass
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t your-registry/your-app:eval \
  --push .
# Terraform: stand up a small evaluation fleet on C9g
# alongside the existing production instance type
resource "aws_instance" "graviton5_eval" {
  count         = 2
  ami           = data.aws_ami.arm64_app.id
  instance_type = "c9g.xlarge"
  subnet_id     = var.private_subnet_id
 
  tags = {
    Name    = "app-graviton5-eval"
    Purpose = "c9g-benchmark"
  }
}

Where the savings actually come from

The realistic outcome of a Graviton generation upgrade is rarely "everything gets 25% faster." It's closer to: some services that were already compute-bound get meaningfully cheaper per unit of throughput, and services that were bottlenecked elsewhere see little change. That's not a disappointing result — it's useful information. A cost optimization pass that identifies which services are compute-bound and worth migrating, rather than lifting-and-shifting the entire fleet, tends to produce a better return for the engineering time spent.

Takeaways

Graviton5-based C9g and C9gd instances are worth benchmarking if you run compute-bound workloads on EC2, particularly ones already on an earlier Graviton generation where the migration cost is near zero. Treat the headline performance numbers as a reason to test, not a reason to migrate outright — the actual savings depend entirely on where your current bottleneck sits. At webhani, this kind of workload-by-workload cost-performance audit is a routine part of the cloud infrastructure reviews we run for clients before recommending an instance family change.

References: AWS Weekly Roundup (AWS News Blog), AWS News Blog

← Back to Blog