# AWS Graviton5 and the new EC2 instances: why ARM chips in the cloud matter
Table of Contents
On 10 June 2026 AWS made two new kinds of virtual server generally available in its cloud: the EC2 instances called M9g and M9gd. The news under the hood is the processor that powers them, Graviton5, first shown in preview in late 2025 and now reaching general availability. It’s a good moment to explain, without needless jargon, something that by now concerns anyone who rents servers in the cloud: why ARM processors are gaining ground, and what’s worth checking before moving your own programs onto them.
What “ARM” and “instance” mean, briefly
An EC2 instance is simply a virtual server you rent by the hour: you give it some computing power and memory, install Linux on it, and run your services. The “engine” of that server is the processor - the chip that does the calculations.
For years, server processors nearly all followed the same underlying design, the one used by Intel and AMD chips, known as x86. ARM is a different way of building processors: it’s the same architecture family found in smartphones and modern laptops, born with a strong focus on power consumption. The technical difference doesn’t concern the end user; the practical consequence does: for the same amount of work, an ARM chip tends to draw less power and cost less to run.
Graviton is the line of ARM processors AWS designs itself, rather than buying from others. It isn’t brand new: it has existed for a few years and has now reached its fifth generation. Graviton5 is that latest step.
Why ARM chips in the cloud matter
The point isn’t rooting for one technology over another. The point is the bill, and the power draw.
In the cloud you pay for compute time. If the same service runs on a chip that gets more done for the same electricity, the provider can offer that compute at a lower price. Historically, AWS’s ARM instances have been listed below their x86 equivalents, and it’s this combination - performance per euro spent and modest consumption - that led many companies to start looking at them.
Then there’s the data-centre side, both environmental and financial. A processor that does the same job with less energy means less heat to remove and less electricity on the bill: two heavy line items for anyone running thousands of servers.
What changes with Graviton5
AWS describes Graviton5 as the most powerful and most energy-efficient processor it has ever built. The stated figures - always to be read with the “up to” in front, since they’re peak values and not guaranteed averages - are these:
- up to 25% more compute performance than the previous generation, Graviton4;
- looking at specific workloads, up to 35% faster for web applications, up to 35% for machine-learning inference (that is, using a model that has already been trained) and up to 30% for databases;
- 192 cores per processor (cores are the independent computing units: more cores means more things running in parallel);
- five times more L3 cache than the previous generation. Cache is a small, very fast memory next to the processor: the larger it is, the less the chip has to stop and wait for data;
- up to 33% lower latency between cores, meaning the cores exchange information more quickly;
- DDR5-8800 memory, among the fastest available in the cloud today.
These are vendor figures. They remain a useful indication of the direction, but the real gain always depends on the specific workload.
The two instances: M9g and M9gd
The new instances come in two variants that share the same processor.
M9g is the general-purpose version, suited to most services: websites, web applications, backends, normal-sized databases. Sizes range from 1 vCPU with 4 GiB of memory up to 192 vCPUs with 768 GiB. A vCPU is the slice of processor assigned to the instance; here the ratio is one vCPU for every four GiB of memory.
M9gd adds local NVMe storage - very fast solid-state memory physically attached to the server - up to 11.4 TB. It’s for those who need to read and write data locally at high speed, for example certain databases or caching systems, without going through a network disk. For this variant AWS also cites an increase in read/write operations per second compared with the past.
The instances can be bought in AWS’s usual ways (on demand, with savings plans, as Spot for interruptible workloads, and in dedicated forms) and, at launch, are available in a handful of regions: the United States (Northern Virginia, Ohio, Oregon) and Europe (Frankfurt). Coverage is therefore still partial, as is normal for something just released.
On security, AWS builds them on the sixth generation of its Nitro system and introduces a component called the Nitro Isolation Engine, which strengthens the isolation between virtual machines sharing the same physical hardware.
What to weigh before moving your Linux workloads
Going from x86 to ARM isn’t just a change of size. It’s a change of processor architecture, and that has concrete consequences. Here are the points to check, in order of importance.
The software must exist in an ARM build. A program compiled for x86 won’t run on ARM as it is. The good news is that the most common Linux distributions (Debian, Ubuntu, Amazon Linux, RHEL and its relatives) have long offered 64-bit ARM builds, labelled arm64 or aarch64. Most interpreted languages - PHP, Python, Node.js, Java - work without rewriting anything.
Watch the compiled dependencies. The trouble hides in “native” components: language extensions, system libraries, proprietary software shipped as a ready-made binary. If a piece exists only for x86, it has to be replaced, recompiled or set aside. It’s worth taking stock of what your stack relies on ahead of time, a faster job when the infrastructure is already described as code.
Check your container images. Anyone using Docker should confirm the images are “multi-architecture”, that is, also available for linux/arm64. Many official images already are; ones built in-house need rebuilding for ARM.
Test with your own data, not with the list figures. The stated percentages are peak values. The only test that counts is measuring your real workload on a small ARM instance and comparing it with the x86 one you use today, looking at both performance and the actual cost in your region.
Confirm the price case by case. ARM’s cost advantage is historically real, but it isn’t a fixed law: it depends on the region, the size and the purchase form. Confirm it on the quote, don’t take it for granted.
In practice, for many modern Linux services the move to ARM is less painful today than people fear, and the saving can be real. For older stacks, or ones full of proprietary components, it’s better to take it slowly: first an inventory of the software, then a side-by-side trial, and only then the decision. Graviton5 makes the ARM option more appealing, but the right choice is still the one measured against your own case.
