https://theawsblog.com/tags/graviton/Articles, tutorials and insights from the AWS community.Hugoen@theawsblog (The AWS Blog)@theawsblogSat, 04 Jul 2026 00:00:00 +0000https://theawsblog.com/news/emiliano-montesdeoca/graviton5-c9g-compute-cost-performance/Sat, 04 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://theawsblog.com/news/emiliano-montesdeoca/graviton5-c9g-compute-cost-performance/Amazon EC2 C9g and C9gd instances powered by AWS Graviton5 can improve compute price-performance, but teams need compatibility testing and workload-specific benchmarks.<p>Every new Graviton generation creates the same opportunity: revisit workloads that were left on x86 because the migration did not feel urgent.</p> <p>AWS announced <a href="https://aws.amazon.com/blogs/aws/amazon-ec2-c9g-and-c9gd-instances-powered-by-aws-graviton5-processors-are-now-available/">Amazon EC2 C9g and C9gd instances powered by AWS Graviton5</a>. The source article highlights higher performance per vCPU, faster memory, larger cache, stronger packet processing, higher network bandwidth, higher EBS bandwidth, and local NVMe on C9gd.</p> <p>For builders, this is not just a new instance family. It is another chance to reduce compute cost without changing the application architecture.</p> <h2 id="what-changed">What changed</h2> <p>C9g is compute-optimized Arm-based EC2 capacity. C9gd adds local NVMe SSD storage for workloads that need fast scratch space or low-latency local buffers.</p> <p>The obvious candidates include:</p> <ul> <li>batch processing,</li> <li>CPU-based inference,</li> <li>real-time analytics,</li> <li>video encoding,</li> <li>distributed services,</li> <li>high-throughput application servers,</li> <li>compute-heavy CI workers,</li> <li>agentic workloads with many concurrent CPU-bound steps.</li> </ul> <p>The article also calls out detailed NVMe statistics for Graviton5-based instance store volumes, which helps teams operate latency-sensitive local storage more carefully.</p> <h2 id="why-builders-should-care">Why builders should care</h2> <p>Graviton migrations are often one of the cleaner cost-optimization paths because the architecture stays familiar. You are not introducing a new service. You are changing the processor architecture and validating the software stack.</p> <p>For many managed runtimes, containers, and compiled languages, the compatibility story has improved significantly over the last few years. The remaining work is usually dependency validation, image build changes, performance testing, and rollout discipline.</p> <p>The payoff can be meaningful: better throughput per vCPU and lower cost per unit of work.</p> <h2 id="the-trade-offs">The trade-offs</h2> <p>Arm compatibility still needs proof.</p> <p>Check native dependencies, third-party agents, language runtimes, container base images, security tooling, observability agents, and any binary packages. A service can pass unit tests and still show different performance behavior under production traffic.</p> <p>Also avoid assuming all workloads benefit equally. Some workloads are memory-bound, some are network-bound, and some depend on libraries optimized for a different architecture. Benchmark before standardizing.</p> <h2 id="what-to-do-next">What to do next</h2> <p>Create a Graviton readiness lane in the platform backlog:</p> <ol> <li>Identify high-spend compute services with portable runtimes.</li> <li>Build multi-architecture container images.</li> <li>Run load tests on C9g or C9gd with production-like traffic.</li> <li>Compare cost per request, job, or transaction.</li> <li>Roll out behind canaries or weighted traffic.</li> <li>Track operational differences after the move.</li> </ol> <p>C9g is a good reminder that compute modernization does not always require a rewrite. Sometimes the biggest win is making the same software run better on a better-shaped instance.</p>