EC2 R9g instances (Graviton5) are now generally available, so I checked the CPU information and more

Introduction

On August 31, 2026, the EC2 R9g / R9gd memory-optimized instances powered by AWS Graviton5 processors became generally available.

https://aws.amazon.com/jp/about-aws/whats-new/2026/08/amazon-ec2-r9g-and-r9gd-memory-optimized-instances-are-now-available/

https://aws.amazon.com/jp/blogs/aws/amazon-ec2-r9g-and-r9gd-instances-powered-by-aws-graviton5-processors-are-now-generally-available/

I summarized the changes from the previous-generation R8g, combining measured results with the values from the official announcements.

In this article, I actually launched R9g and checked how the CPU is recognized using OS commands. I also launched the previous-generation R8g under the same conditions to look at the generational differences, and cross-checked against the CPU information I confirmed on M9g / C9g, which became GA earlier.

https://dev.classmethod.jp/articles/ec2-m9g-graviton5-instance-launch/

https://dev.classmethod.jp/articles/ec2-c9g-graviton5-instance-launch/

What I Verified

I ran R9g and R8g side by side and checked the CPU information and availability.

Test Environment

I launched one r9g.medium and one r8g.medium. To see only the generational difference, I matched the region, AZ, AMI, and kernel, and ran the same series of commands.

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 have 1 vCPU / 8 GiB, and the AMI is the arm64 version of Amazon Linux 2023.

CPU Information

First, I ran lscpu. Only the key points of the output are excerpted.

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

BIOS Model name showed AWS Graviton5 as is. Thread(s) per core is 1, since the Graviton series does not use SMT, so 1 vCPU corresponds to 1 physical core. lscpu showed L3 as 48 MiB, L2 as 2 MiB, and L1d and L1i as 64 KiB each. The Stepping r0p1 is an early revision of Neoverse V3. The flags include sve2, and bf16 and i8mm for machine learning were also confirmed. The values from BIOS Model name through the flags match those I confirmed on M9g / C9g.

The same output also includes the mitigation status for speculative execution vulnerabilities.

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

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

Family was ARMv9 and Manufacturer was AWS. The official blog also states that this is a processor designed by AWS. Max Speed and Current Speed were both 3300 MHz. Running the same command on R8g gave 2800 MHz, so R9g is 500 MHz (+18%) higher. Part 0xd84 in the Signature is the CPU part number of Arm Neoverse V3. There were no items that conflicted with the output for the same size (1 vCPU) in the M9g / C9g articles.

The CPU identifiers can also be checked in /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

CPU part was 0xd84, the same as dmidecode. CPU architecture is displayed as 8, but looking at the same CPU with dmidecode, Family is ARMv9 and Signature shows Architecture 15. This combination of displays is the same on R8g.

I ran the same series of commands on r8g.medium as well.

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

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

[    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

16

The number of CPU flags was 44 on R8g and 47 on R9g. The ones only on R9g are ecv, afp, and wfxt, and there were no flags only on R8g. Of these, wfxt corresponds to WFx with timeout that appears in the kernel log below.

Kernel Log

I extracted the CPU-related lines at boot from dmesg.

[    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 breaks 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 was 16 bytes for both the maximum and the default.

I also checked the default vector length via /proc/sys/abi/sve_default_vector_length.

16

This is 128 bits, the same as the value I confirmed on M9g / C9g.

Cross-Checking Spec Values

I retrieved all 22 types of R9g and R9gd with describe-instance-types and compared them against the table in the official blog. There were no conflicting values for vCPU, memory, network bandwidth, or EBS bandwidth. All 11 sizes of R9g are EBS-only, while R9gd keeps the same vCPU and memory configurations and adds local NVMe SSDs.

Available Regions

I queried r9g.medium with describe-instance-type-offerings and listed the results returned. The targets are 7 regions: the 4 regions listed in the official blog plus Tokyo, Singapore, and Ireland. 1 means available, and 0 means 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, those with availability were the 4 regions listed in the official blog: US East (N. Virginia and Ohio), US West (Oregon), and Europe (Frankfurt). It was not available in the Tokyo region.

Pricing

I retrieved the Linux / Shared / On-Demand prices for us-east-1 via the Pricing API on September 2, 2026.

Comparison with R8g

The increase over R8g was a uniform +9.0% across all 11 sizes. This is the same as the differences for M9g / M8g and C9g / C8g. If the performance improvement announced officially (up to 25%) is achieved, a simple calculation that accounts for this price difference gives roughly a 15% improvement in performance per price (1.25 / 1.09 ≒ 1.147). The actual cost-effectiveness depends on the workload. metal-48xl and 48xlarge were priced the same.

Comparison of the Three Families

I lined up the three families that are now available in the Graviton5 generation, all at 4xlarge.

The unit price per vCPU and the unit price per memory GiB were constant per family across all sizes from medium to 48xlarge. In the order C9g, M9g, R9g, the per-vCPU price gets higher and the per-GiB memory price gets lower.

Summary

The CPU I confirmed on R9g was the same AWS Graviton5 (Arm Neoverse V3) as on M9g / C9g, which became GA earlier. The on-demand price is a uniform +9.0% higher than R8g across all 11 sizes. The price increase rate is the same as for c8g→c9g and m8g→m9g.

In the Graviton5 generation, three families are now available: general purpose, compute optimized, and memory optimized. I'm also looking forward to expansion to RDS and Aurora, and to availability in the Tokyo region.