AWS has spent years designing its own server processors. With Graviton5, infrastructure teams have another reason to examine the cost of running applications, not simply the advertised speed of a newer chip.
A company moves its applications to the cloud expecting greater flexibility. It no longer needs to buy physical servers or predict computing demand years ahead. A few years later, its applications have grown, the AWS bill keeps increasing, and the infrastructure team needs more capacity without continuously spending more.
Adding servers is one option. Choosing larger instances is another. But what if the company could get more useful work from the computing capacity it already pays for?
That is where AWS Graviton5 becomes interesting. This Amazon-designed processor uses Arm technology rather than the x86 architecture commonly associated with Intel and AMD servers.
AWS reports that Graviton5 can deliver up to 25% better compute performance than Graviton4 in its comparisons. It also positions the new processor for applications supporting AI agents. Those claims are worth exploring, but neither guarantees a smaller bill. AWS’s June 2026 launch announcement describes the release and intended workloads.
Why AWS builds its own processors
A processor follows a set of basic instructions when software asks it to perform work. That set is called an instruction-set architecture. Intel and AMD server processors commonly use x86. AWS Graviton uses Arm.
Think of two workers who can accomplish the same task but follow different instruction manuals. Software prepared for one instruction set may need rebuilding or adapting to work on the other.
AWS introduced its first Graviton-powered A1 EC2 instances in 2018. The objective was not to invent a new kind of application: it was to give AWS more control over the performance and efficiency of the hardware running cloud workloads. The original A1 announcement identifies web servers, containers, caches and distributed data stores among the intended use cases.
For customers, that choice brings both opportunity and responsibility. An alternative CPU architecture can improve the economics of some applications, but the software and supporting tools must be compatible with it.
What Graviton5 improves, and what it cannot promise
Graviton5-powered M9g and M9gd general-purpose EC2 instances became generally available on June 10, 2026. EC2 instances are virtual servers: customers choose configurations with particular amounts of processing power, memory, network capability and storage. The largest M9g configuration provides 192 vCPUs and 768 GiB of memory.
On these Graviton instances, one vCPU maps to one physical core. Matching vCPU counts between Arm and some x86 instances therefore does not guarantee equal performance. AWS M9g specifications list the configurations and capabilities.
The processor also introduces faster memory, a larger shared cache and PCIe 6.0 support. Cache is fast memory close to the CPU that keeps frequently used information within easier reach. PCIe is a high-speed connection used to transfer data between the processor and attached devices.
The sixth-generation AWS Nitro system provides important EC2 virtualization, network, storage and isolation functions. These features improve potential capacity, but an application benefits only when the newer hardware addresses something that actually limits it. AWS’s launch engineering overview describes the changes.
For example, faster processing may help a busy web service. It may do little for an application whose response time mostly consists of waiting for an external service. AWS’s claims of up to 25% better compute performance, and larger gains on certain database, web and machine-learning workloads, are vendor-reported results from particular comparisons, not promises for every workload.
Why a general-purpose CPU matters to AI agents
An AI assistant does more than call a model. Imagine an employee asking it to summarize customer accounts.
The application checks permissions, retrieves records, prepares information, calls a language model, and may use other business tools. The model’s intensive mathematical operations may run on GPUs or purpose-built accelerators elsewhere. The surrounding retrieval, request handling and orchestration can run on CPUs.
That explains AWS’s interest in Graviton5 for agentic applications. But it also sets a limit: if most of the request is spent waiting for a remotely hosted language model, replacing the orchestrator’s CPU may barely change the user’s experience. The relevant question is where the application spends computing time, not whether the product is labelled agentic AI. AWS explicitly lists real-time reasoning, code generation and multi-step orchestration among its targeted use cases in the M9g availability announcement.
Five generations of Graviton at a glance
Graviton5 is not an isolated launch. It is the fifth step in a long-running AWS effort to make Arm a practical choice for ordinary cloud services.
| Generation | First generally available EC2 instances | Key change | AWS-reported comparison |
|---|---|---|---|
| Graviton1 | 2018 | First Arm-powered A1 instances | Starting point |
| Graviton2 | 2020 | Broader general-purpose Arm support | Up to 40% better price performance than comparable x86-based M5 instances |
| Graviton3 | 2022 | DDR5 memory and newer compute design | Up to 25% better performance than Graviton2 |
| Graviton4 | 2024 | Increased processing and memory capacity | Up to 30% better performance than Graviton3 |
| Graviton5 | 2026 | 192-core design, larger cache, faster memory and PCIe 6.0 | Up to 25% better compute performance than Graviton4 |
Sources: official AWS Graviton2, Graviton3, Graviton4 and Graviton5 announcements. These are vendor comparisons with different baselines and workloads. The percentages cannot be added together.
The important shift is not simply that newer generations are faster. Arm has become easier to evaluate for increasingly ordinary server applications. For the company in our example, the next decision has three parts: Can its applications move safely? Do customer performance gains translate into actual savings? How can it test both claims?
1. Can existing applications move to Arm?
Many common runtimes, including Java, Node.js, Python, Go and .NET, support Arm64, the 64-bit Arm architecture used by Graviton. Container systems can build images for both x86 and Arm, making gradual adoption practical. But application language support does not guarantee that every native library, commercial extension, monitoring agent or security tool is available for Arm.
A successful startup also proves less than a successful production test. The application still needs to meet its latency and reliability requirements, produce usable telemetry and remain supportable. For Kubernetes or ECS environments, mixed-architecture deployments can allow a smaller trial rather than a sudden fleet-wide replacement. AWS’s Graviton getting-started guide provides dependency and migration guidance.
For our company, a CPU-intensive web service with modern dependencies might be a first candidate. A legacy application tied to an x86-only vendor product may not be.
2. Will Graviton5 actually reduce the cloud bill?
AWS has published customer-reported benchmark results, which show why workload-level comparisons are more informative than a single processor headline.
| Customer | Reported Graviton5 result | Important context |
|---|---|---|
| ClickHouse | 36% performance increase. 16% more concurrency | Early Graviton5 benchmarking against Graviton4 |
| Atlassian | 30% higher performance. 20% lower latency | Jira testing on M9g compared with the previous generation |
| Honeycomb | 36% better throughput per core. 28% lower latency | Graviton5 versus Graviton4, including production ingestion evaluation |
| HubSpot | Queries 45 to 60% shorter. CPU usage 20 to 30% lower | MySQL OLTP, pre-production M9g versus M8g |
| Hard Rock Bet | 23% lower CPU usage. About 6% lower p99 latency while processing 9% more queries/second | CockroachDB gateways alongside an existing Graviton4 fleet |
Source for all rows: AWS M9g customer statements. These are customer statements selected and published by AWS, not an independently standardized benchmark. Tests, baselines and measurement conditions differ.
These results are substantial, but higher throughput and lower latency are not the same thing as verified cost savings. Honeycomb might use extra throughput to serve more customers rather than reduce instance count. HubSpot could choose to spend its gain on faster query responses. A financial benefit depends on actual instance pricing, resource use, right-sizing and purchasing commitments.
HubSpot separately reports approximately 15 to 20% lower costs at comparable performance from its earlier Graviton adoption. That is useful historical evidence, but it must not be described as a Graviton5 cost result. The company should compare the cost per unit of useful work: for example, cost per million requests at the required response time, or cost per completed batch job. Migration engineering, licensing and ongoing support belong in the calculation too.
Storage creates a related decision. M9gd has fast local NVMe storage that can suit caches and temporary working data.
But EC2 instance-store data does not survive a stop, hibernation or termination. It must not be the only copy of valuable records. See AWS’s instance-store lifecycle guidance. In hybrid environments, another cost may be supporting both Arm and x86: Arm64 software can be portable, but Graviton’s particular hardware characteristics are AWS-specific.
3. How should the company test the benefit?
Start with one representative service. Record its current traffic, throughput, CPU and memory use, response times, error rate and full monthly running cost. Build an Arm-compatible version, then compare it on a suitable Graviton5 instance under the same realistic traffic and service-level targets.
Do not assume that two instances with the same vCPU count provide the same capacity. Choose the right family: general-purpose M9g, compute-optimized C9g, or memory-optimized R9g, subject to availability and workload needs.
Compare the cost to serve the required load, not the hourly price alone. Include the effort to prepare and operate the new environment, test failure recovery, and maintain a rollback route. The AWS migration guide provides a starting point.
If the improvement is worthwhile, the team can expand gradually to similar services. If the measured benefit is small or the compatibility cost is high, staying on x86 may be the sounder engineering decision.
The bigger change behind Graviton5
AWS is increasingly building the infrastructure underneath its cloud rather than relying entirely on traditional server processors. That gives customers another way to improve efficiency, but it also makes workload understanding more important. The same pattern appears elsewhere: our analysis of AWS and NVIDIA’s two-million-GPU expansion covers the GPU side of AWS’s build-out, and our Google Cloud Q3 2026 article shows how Google’s own TPU systems contributed to its revenue growth.
For the company with a growing cloud bill, the answer may not be another server or a wholesale Arm migration. It may be identifying where its services actually consume processing capacity and testing whether a different architecture can deliver the same outcome more efficiently.
The value of Graviton5 is not simply a faster processor. It is the possibility of paying less for the computing work that matters.
Go deeper
- AWS Graviton5 launch and engineering overview, June 2026. Architecture, release context and vendor-reported gains.
- M9g specifications and customer results, current instance features and attributed customer benchmarking statements.
- AWS C9g and C9gd announcement, June 30, 2026. Compute-optimized Graviton5 instances and AWS’s comparison with Graviton4-based C8g.
- AWS R9g and R9gd announcement, August 31, 2026. Memory-optimized Graviton5 instances and AWS’s comparison with Graviton4-based R8g.
- AWS Graviton getting-started guide, assessing dependencies, building compatible software and testing migrations.
- EC2 instance-store data persistence, lifecycle and data-loss consequences for local NVMe.
- Graviton family technical overview, broader processor-family background and references.