AWS makes Graviton5-based R9g and R9gd memory-optimised EC2 instances generally available
Custom Arm silicon keeps reshaping cloud price-performance, and knowing what a memory-optimised instance is for is the first step to using one well.
Amazon Web Services announced on 31 August 2026 that its R9g and R9gd Amazon EC2 instances, built on the company's Graviton5 processors, are now generally available. The post, written by Daniel Abib on the AWS News Blog, positions the instances as memory-optimised options for databases, in-memory caches such as Valkey, Redis and Memcached, real-time analytics and containerised applications.
According to AWS, R9g delivers up to 25 percent better compute performance than the Graviton4-based R8g instances. Memory runs DDR5 at 8800 MT/s compared with 5600 MT/s on the prior generation, the L3 cache is five times larger, network and EBS bandwidth are up to twice as high, and packet-processing performance is up to three times higher. The largest sizes provide up to 100 Gbps of network bandwidth and up to 72 Gbps to EBS.
Both families come in 11 sizes, from medium with 1 vCPU and 8 GB of memory through to 48xlarge and a metal-48xl bare-metal option, each with 192 vCPUs and 1,536 GB. The R9gd variant adds local NVMe SSD storage, ranging from a single 59 GB drive on the medium size to three 3,800 GB drives on the largest. All instances run on the AWS Nitro System with the Nitro Isolation Engine, which AWS describes as a formally verified hypervisor.
At launch the instances are available in US East (N. Virginia and Ohio), US West (Oregon) and Europe (Frankfurt). AWS lists supported runtimes including C and C++, Rust, Go, Java, Python, .NET, Node.js, Ruby and PHP, and names Kubernetes deployments as a target workload.
Why it matters
Hyperscalers now iterate on their own CPUs at a cadence closer to accelerators than to the traditional server market, and each generation changes the price-performance maths for common workloads. Memory speed and cache size are the headline gains here, which reflects how often database and cache workloads are limited by memory rather than raw compute. Arm-based instances have moved from niche to default for many new deployments. The regional rollout order also shows where capacity is being built first.
R8g on Graviton4
DDR5 memory at 5600 MT/s; baseline for compute, cache, network and EBS bandwidth comparisons.
R9g on Graviton5
Up to 25% better compute; DDR5 at 8800 MT/s; 5x larger L3 cache; up to 2x network and EBS bandwidth; up to 3x packet processing.
What you can learn from this
- Memory-optimised instances trade cores for bytes. Cloud instance families are defined by their ratio of vCPUs to memory: the R family pairs each vCPU with 8 GB, compared with 4 GB in general-purpose M and 2 GB in compute-optimised C instances. Workloads such as in-memory caches, analytical databases and large JVM heaps are limited by how much data they can hold close to the processor, not by arithmetic throughput. Choosing the family by ratio first is the simplest way to avoid paying for cores you cannot use. Sizes within a family keep the ratio fixed, so moving up one size doubles both cores and memory.
- Memory bandwidth and cache size often matter more than clock speed. A processor that is waiting on memory is idle, and modern cores spend much of their time doing exactly that. Faster DDR5 transfer rates raise the ceiling on how quickly data arrives, while a larger last-level cache keeps hot working sets on the chip and avoids the trip to DRAM altogether. That is why a generation's uplift on database workloads can exceed its uplift on synthetic compute benchmarks. A cache miss costs hundreds of core cycles, so shaving misses is worth more than a few percent of clock speed.
- A vCPU on Graviton is a physical core. On many x86 instances a vCPU maps to one hyperthread, so two vCPUs share one core's execution units. Graviton instances expose one vCPU per physical core, which changes how throughput scales as you add vCPUs and is one reason like-for-like size comparisons across architectures can mislead. Benchmark with your own workload rather than trusting vCPU counts. A workload that scales poorly across hyperthreads may scale better per vCPU on Arm, and the reverse can also be true.
- Local NVMe is fast but ephemeral. The "d" suffix means the instance has SSDs attached directly to the host, delivering very high IOPS with low latency. That storage disappears when the instance stops or fails, so it suits scratch space, caches and database logs that are replicated elsewhere, not primary durable data. EBS volumes persist independently of the instance and are the durable counterpart.
- The hypervisor is now part of the silicon story. Offloading networking, storage and security to dedicated Nitro cards lets nearly all of the host CPU go to the guest, and a small, formally verified isolation layer reduces the attack surface between tenants. Understanding this split explains why bare-metal and virtualised sizes can share the same specifications and why the guest sees almost the full processor.
We teach this
How to use this in practice
- Check whether your code already runs on Arm. Pull the
arm64variant of your application's base container image, for exampledocker pull --platform linux/arm64 python:3.12-slim, and build your project on it, or usedocker buildx build --platform linux/arm64. Note any dependency that fails to compile or lacks a prebuilt wheel, and run your test suite inside the Arm container so you catch runtime differences, not only build failures. Done looks like: either a working multi-architecture image tag or a list of the dependencies that block an Arm build. - Measure your workload's memory-to-CPU ratio. On a running server, record peak resident memory and average CPU utilisation over a typical day using
top,htopor your monitoring tool. Divide memory by the cores actually in use and compare the result with the 2, 4 and 8 GB per vCPU ratios of the C, M and R families. Repeat the measurement for a peak day, because sizing to the average leaves no headroom. Done looks like: one line stating which family fits your workload and why. - Price a like-for-like move on paper. Take one instance you run today, find the R9g size with the same vCPU count, and compare hourly prices in the AWS pricing calculator for your region. Add a column for the performance uplift you would need to break even, then note whether the region you use is among the four launch regions. Include the cost of any EBS volumes you would keep alongside the instance. Done looks like: a small table with current cost, candidate cost and the break-even percentage.
- Draw the Nitro split. Sketch a host with the guest operating system on top, the Nitro hypervisor beneath it, and the Nitro cards handling network, EBS and local NVMe on the side. Label which path each of your workload's I/O operations takes and where isolation between tenants is enforced. Done looks like: a one-page diagram that explains why the guest sees nearly the full CPU.
Sources
- Amazon EC2 R9g and R9gd instances powered by AWS Graviton5 processors are now generally available — AWS News Blog
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report