EC2 R9g instances (Graviton5) became GA, so I checked the CPU information and other details
This page has been translated by machine translation. View original
Introduction
On August 31, 2026, the EC2 R9g / R9gd memory-optimized instances featuring the AWS Graviton5 processor became generally available.
The changes from the previous generation R8g are summarized below, combining actual measurement results with officially announced values.
| Item | R8g (Graviton4) | R9g (Graviton5) |
|---|---|---|
| BIOS Model name | AWS Graviton4 | AWS Graviton5 |
| CPU part | 0xd4f (Neoverse V2) | 0xd84 (Neoverse V3) |
| Architecture family | ARMv9 | ARMv9 |
| Clock frequency | 2800 MHz | 3300 MHz |
| L2 cache | 2 MiB | 2 MiB |
| L3 cache (lscpu display) | 36 MiB | 48 MiB |
| L3 cache (entire chip) | Baseline | 5x |
| SVE vector length | 128 bit | 128 bit |
| Pointer authentication algorithm | QARMA5 | QARMA3 |
| Memory | DDR5 5600 MT/s | DDR5 8800 MT/s |
| Nitro configuration | Nitro System | Nitro System + Nitro Isolation Engine |
| Compute performance | Baseline | Up to 25% improvement |
| Packet processing performance | Baseline | Up to 3x |
| Maximum vCPU count | 192 | 192 |
| Maximum memory | 1536 GiB | 1536 GiB |
| Network bandwidth (maximum) | 50 Gbps | 100 Gbps |
| EBS bandwidth (maximum) | 40 Gbps | 72 Gbps |
| EBS IOPS (maximum) | 240,000 | 288,000 |
In this article, I actually launched an R9g instance and used OS commands to verify how the CPU is recognized. I also launched an R8g under the same conditions to observe generational differences, and cross-referenced the results with CPU information confirmed on the previously GA'd M9g / C9g instances.
Verification Details
I set up both an R9g and an R8g side by side to check CPU information and availability.
Verification Environment
I launched one r9g.medium and one r8g.medium instance. To observe only the generational difference, I matched the region, AZ, AMI, and kernel, and ran the same series of commands on both.
instance-type: r9g.medium
availability-zone: us-east-1a
ami-id: ami-07987a01dcdb011ef
kernel: 6.18.44-99.149.amzn2023.aarch64
PRETTY_NAME="Amazon Linux 2023.12.20260831"
instance-type: r8g.medium
availability-zone: us-east-1a
ami-id: ami-07987a01dcdb011ef
kernel: 6.18.44-99.149.amzn2023.aarch64
PRETTY_NAME="Amazon Linux 2023.12.20260831"
Both instances have 1 vCPU / 8 GiB, and the AMI is the arm64 version of Amazon Linux 2023.
CPU Information
First, I ran lscpu. Here are the key excerpts from the output.
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Vendor ID: ARM
BIOS Vendor ID: AWS
BIOS Model name: AWS Graviton5
Model: 1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti ecv afp wfxt
L1d cache: 64 KiB (1 instance)
L1i cache: 64 KiB (1 instance)
L2 cache: 2 MiB (1 instance)
L3 cache: 48 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0
The BIOS Model name displayed AWS Graviton5 directly. Thread(s) per core is 1, and since the Graviton series does not use SMT, 1 vCPU corresponds to 1 physical core. The L3 reported by lscpu is 48 MiB, L2 is 2 MiB, and both L1d and L1i are 64 KiB. The stepping r0p1 is the initial revision of the Neoverse V3. The flags include sve2, and machine learning-oriented bf16 and i8mm were also confirmed. The values from BIOS Model name through the flags match those confirmed on M9g / C9g.
The same output also includes information on mitigations for speculative execution vulnerabilities.
lscpu Vulnerabilities section
Vulnerability Gather data sampling: Not affected
Vulnerability Ghostwrite: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Old microcode: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
Mitigations were applied for Spectre v1 / v2 and Speculative Store Bypass. Vulnerabilities such as Meltdown, MDS, and L1TF, which are primarily issues with x86 processors, showed Not affected.
Next, I checked the processor information with dmidecode -t processor.
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU0
Type: Central Processor
Family: ARMv9
Manufacturer: AWS
ID: 41 D8 0F 41 00 00 00 00
Signature: Implementor 0x41, Variant 0x0, Architecture 15, Part 0xd84, Revision 1
Version: AWS Graviton5
Voltage: Unknown
External Clock: Unknown
Max Speed: 3300 MHz
Current Speed: 3300 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: AWS Graviton5
Asset Tag: AWS Graviton5
Part Number: AWS Graviton5
Core Count: 1
Core Enabled: 1
Thread Count: 1
Characteristics: None
The Family is ARMv9 and the Manufacturer is AWS. The fact that this is a processor designed by AWS is also stated in the official blog. Both Max Speed and Current Speed are 3300 MHz. Running the same command on R8g showed 2800 MHz, meaning R9g is 500 MHz (+18%) higher. The Part 0xd84 in the Signature is the CPU part number for the Arm Neoverse V3. There were no discrepancies with the output from M9g / C9g articles for the same size (1 vCPU).
CPU identifiers can also be checked via /proc/cpuinfo.
processor : 0
BogoMIPS : 2000.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti ecv afp wfxt
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd84
CPU revision : 1
The CPU part is 0xd84, the same as in dmidecode. The CPU architecture displays as 8, but when viewing the same CPU via dmidecode, the Family is ARMv9 and the Signature shows Architecture 15. This combination of display values is the same on R8g as well.
I also ran the same series of commands on r8g.medium.
Results of running the same commands on R8g (Graviton4)
The key portion of lscpu output.
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Vendor ID: ARM
BIOS Vendor ID: AWS
BIOS Model name: AWS Graviton4
Model: 1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 64 KiB (1 instance)
L1i cache: 64 KiB (1 instance)
L2 cache: 2 MiB (1 instance)
L3 cache: 36 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0
I also ran dmidecode -t processor under the same conditions.
Handle 0x0004, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU0
Type: Central Processor
Family: ARMv9
Manufacturer: AWS
ID: F1 D4 0F 41 00 00 00 00
Signature: Implementor 0x41, Variant 0x0, Architecture 15, Part 0xd4f, Revision 1
Version: AWS Graviton4
Max Speed: 2800 MHz
Current Speed: 2800 MHz
Core Count: 1
Core Enabled: 1
Thread Count: 1
An excerpt of CPU-related lines from dmesg.
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd4f1]
[ 0.000000] CPU features: detected: Address authentication (architected QARMA5 algorithm)
[ 0.001131] CPU features: detected: Generic authentication (architected QARMA5 algorithm)
[ 0.002861] SVE: maximum available vector length 16 bytes per vector
[ 0.002862] SVE: default vector length 16 bytes per vector
I also checked the SVE default vector length.
16
The R8g values match the difference table at the beginning. L1d and L1i at 64 KiB and L2 at 2 MiB are unchanged from R9g. The SVE default vector length of 16 bytes (128 bits), Thread(s) per core of 1, and Stepping r0p1 are also shared.
The number of CPU flags was 44 for R8g and 47 for R9g. The three flags present only on R9g are ecv, afp, and wfxt, while there were no flags present only on R8g. Among these, wfxt corresponds to WFx with timeout, which appears in the kernel log shown next.
Kernel Log
I extracted CPU-related lines from dmesg at boot time.
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd841]
[ 0.000000] Detected PIPT I-cache on CPU0
[ 0.000000] CPU features: detected: Address authentication (architected QARMA3 algorithm)
[ 0.000000] CPU features: detected: Spectre-v4
[ 0.000000] CPU features: detected: Spectre-BHB
[ 0.001114] smp: Brought up 1 node, 1 CPU
[ 0.001119] CPU features: detected: Branch Target Identification
[ 0.001129] CPU features: detected: Generic authentication (architected QARMA3 algorithm)
[ 0.001131] CPU features: detected: LSE atomic instructions
[ 0.001134] CPU features: detected: Random Number Generator
[ 0.001136] CPU features: detected: WFx with timeout
[ 0.001138] CPU features: detected: Scalable Vector Extension
[ 0.001978] SVE: maximum available vector length 16 bytes per vector
[ 0.001978] SVE: default vector length 16 bytes per vector
The boot CPU ID 0x410fd841 can be broken down into 0x41 (ARM), 0xd84 (Neoverse V3), and the trailing revision 1. The pointer authentication (PAC) algorithm is QARMA3. Branch Target Identification and Scalable Vector Extension are also detected. The SVE vector length is 16 bytes for both the maximum and the default.
The default vector length was also confirmed via /proc/sys/abi/sve_default_vector_length.
16
This is the same 128 bits confirmed on M9g / C9g.
Specification Cross-Check
I retrieved all 22 types of R9g and R9gd using describe-instance-types and cross-checked them against the table in the official blog. There were no discrepancies in vCPU, memory, network bandwidth, or EBS bandwidth. All 11 sizes of R9g are EBS-Only, while R9gd keeps the same vCPU and memory configuration but adds local NVMe SSDs.
R9gd local NVMe SSD configuration
| Instance size | vCPU | Memory (GiB) | Instance storage |
|---|---|---|---|
| r9gd.medium | 1 | 8 | 1 x 59 GB |
| r9gd.large | 2 | 16 | 1 x 118 GB |
| r9gd.xlarge | 4 | 32 | 1 x 237 GB |
| r9gd.2xlarge | 8 | 64 | 1 x 474 GB |
| r9gd.4xlarge | 16 | 128 | 1 x 950 GB |
| r9gd.8xlarge | 32 | 256 | 1 x 1900 GB |
| r9gd.12xlarge | 48 | 384 | 3 x 950 GB |
| r9gd.16xlarge | 64 | 512 | 1 x 3800 GB |
| r9gd.24xlarge | 96 | 768 | 3 x 1900 GB |
| r9gd.48xlarge | 192 | 1536 | 3 x 3800 GB |
| r9gd.metal-48xl | 192 | 1536 | 3 x 3800 GB |
Available Regions
I queried r9g.medium using describe-instance-type-offerings and listed the returned results. The coverage spans 7 regions: the 4 regions listed in the official blog, plus Tokyo, Singapore, and Ireland. 1 indicates available, 0 indicates not available.
us-east-1: 1
us-east-2: 1
us-west-2: 1
eu-central-1: 1
ap-northeast-1: 0
eu-west-1: 0
ap-southeast-1: 0
Of the 7 regions queried, the 4 regions listed in the official blog were available: US East (N. Virginia / Ohio), US West (Oregon), and Europe (Frankfurt). The Tokyo region was not yet available.
Pricing
I retrieved the Linux / Shared / On-Demand pricing for us-east-1 via the Pricing API on September 2, 2026.
Comparison with R8g
| Size | R9g (USD/hr) | R8g (USD/hr) | Difference |
|---|---|---|---|
| medium | 0.06421 | 0.05891 | +9.0% |
| large | 0.12842 | 0.11782 | +9.0% |
| xlarge | 0.25684 | 0.23564 | +9.0% |
| 2xlarge | 0.51368 | 0.47128 | +9.0% |
| 4xlarge | 1.02736 | 0.94256 | +9.0% |
| 8xlarge | 2.05472 | 1.88512 | +9.0% |
| 12xlarge | 3.08208 | 2.82768 | +9.0% |
| 16xlarge | 4.10944 | 3.77024 | +9.0% |
| 24xlarge | 6.16416 | 5.65536 | +9.0% |
| 48xlarge | 12.32832 | 11.31072 | +9.0% |
| metal-48xl | 12.32832 | 11.31072 | +9.0% |
The price increase over R8g was a uniform +9.0% across all 11 sizes. This is the same rate as the c8g→c9g and m8g→m9g differences. If the officially announced performance improvement (up to 25%) is achieved, a simple calculation factoring in this price difference shows that price-performance improves by approximately 15% (1.25 / 1.09 ≈ 1.147). Actual cost-effectiveness depends on the workload. The metal-48xl and 48xlarge are priced identically.
Comparison Across 3 Families
I compared the three families now available in the Graviton5 generation, using the 4xlarge size.
| Instance | USD/hr | vCPU | Memory (GiB) | GiB/vCPU | USD/vCPU/hr | USD/GiB/hr |
|---|---|---|---|---|---|---|
| c9g.4xlarge | 0.69552 | 16 | 32 | 2.0 | 0.04347 | 0.02174 |
| m9g.4xlarge | 0.78272 | 16 | 64 | 4.0 | 0.04892 | 0.01223 |
| r9g.4xlarge | 1.02736 | 16 | 128 | 8.0 | 0.06421 | 0.00803 |
The per-vCPU and per-memory-GiB unit prices were consistent within each family across all sizes from medium to 48xlarge. In the order of C9g, M9g, and R9g, the per-vCPU price increases while the per-GiB price decreases.
Summary
The CPU confirmed on R9g is the same AWS Graviton5 (Arm Neoverse V3) as on the previously GA'd M9g / C9g. On-demand pricing is uniformly +9.0% higher than R8g across all 11 sizes. This price increase rate is the same as c8g→c9g and m8g→m9g.
With the Graviton5 generation, the three families of general purpose, compute optimized, and memory optimized are now complete. Expansion to RDS and Aurora, as well as availability in the Tokyo region, are areas to look forward to.
