EC2 M9g instances (Graviton5) are now GA, so I checked the CPU information and more
This page has been translated by machine translation. View original
Introduction
On 2026/6/10, Amazon EC2 M9g and M9gd instances powered by AWS Graviton5 processors became generally available (GA).
Graviton5 is AWS's fifth-generation Arm processor, designed in-house. It uses Arm Neoverse V3 cores and is said to deliver up to 25% higher compute performance compared to the previous-generation Graviton4.
M9g was announced in preview at re:Invent in 2025/12, and we introduced it on our blog as well.
Now that it has reached GA, I launched an actual instance and checked the CPU information using OS commands.
The main spec differences between M9g and the previous-generation M8g are summarized below.
| Item | M8g (Graviton4) | M9g (Graviton5) |
|---|---|---|
| Core architecture | Neoverse V2 | Neoverse V3 |
| Architecture family | ARMv9 | ARMv9 |
| Max cores per processor | 96 | 192 (doubled) ※1 |
| Clock frequency | 2800 MHz | 3300 MHz (+18%) |
| L2 cache | 2 MiB | 2 MiB |
| L3 cache (lscpu display) | 36 MiB | 48 MiB (+33%) |
| L3 cache (whole chip) | ~36 MB | ~180 MB (5x) ※2 |
| SVE vector length | 128 bit | 128 bit |
| Memory | DDR5 | DDR5-8800 ※2 |
| PCIe | Gen5 | Gen6 ※2 |
| Nitro System | v5 | v6 + Nitro Isolation Engine ※2 |
| Process | 5nm | 3nm ※2 |
| Compute performance | Baseline | Up to 25% higher ※2 |
| Network bandwidth (max) | 50 Gbps | 100 Gbps (doubled) ※1 |
| EBS bandwidth (max) | 40 Gbps | 72 Gbps ※1 |
| EBS IOPS (max) | 160,000 | 288,000 ※1 |
- ※1 Official documentation
- ※2 Official blog
- Items without a note are values confirmed through OS command verification (dmidecode, lscpu, etc.) on both M8g and M9g
※ The L1d/L1i cache (64 KiB), L2 cache (2 MiB), and SVE vector length (128 bit) are the same as M8g. The same applies to NitroTPM, Nitro Enclaves, EFA, and Encryption in transit.
The available regions are four: us-east-1, us-east-2, us-west-2, and eu-central-1.
Launching the Instance
When you type "m9g" into the instance type field on the EC2 launch screen, a list of candidates is displayed.
This time I selected the smallest size, m9g.medium (1 vCPU, 4 GiB).
The test environment is as follows.
- Instance type: m9g.medium (1 vCPU, 4 GiB)
- Region: us-east-1
- AMI: Amazon Linux 2023 (arm64)
- Kernel: 6.1.174-217.345.amzn2023.aarch64
Checking CPU Information with OS Commands
lscpu
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
lscpu Vulnerabilities section
Vulnerability Gather data sampling: 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 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 for Spectre v1/v2 are enabled, and x86-specific vulnerabilities (Meltdown, MDS, L1TF, etc.) are all Not affected.
- BIOS Model name: AWS Graviton5 — The processor name is displayed directly
- Thread(s) per core: 1 — The Graviton series does not use SMT; 1 vCPU = 1 physical core
- L2 cache: 2 MiB — The same value as Graviton4
- L3 cache: 48 MiB — In the test environment (1 vCPU), 48 MiB was displayed as the L3 cache (36 MiB for Graviton4)
- sve2 in Flags — SVE2 (Scalable Vector Extension v2) is supported. Instruction sets for machine learning such as bf16 and i8mm can also be confirmed. Compared with M8g, the flags added on M9g are ecv, afp, and wfxt
- Stepping: r0p1 — An early revision of Neoverse V3
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: ARMv9 — An ARMv9 family, same as Graviton4. lscpu shows Architecture as aarch64, but this is because the Linux kernel treats ARMv9 as a superset of ARMv8. "CPU architecture: 8" in
/proc/cpuinfoand "Architecture 15" in dmidecode are also consistent with ARMv9 - Max Speed / Current Speed: 3300 MHz — An improvement of 500 MHz (+18%) from Graviton4's 2800 MHz
- Part 0xd84 — The CPU part number of Arm Neoverse V3
- Manufacturer: AWS — Indicates that it is designed in-house by AWS
/proc/cpuinfo
The same information can be confirmed in /proc/cpuinfo. The CPU part 0xd84 indicates Neoverse V3.
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
dmesg (CPU-related)
I extracted CPU-related kernel messages with sudo dmesg | grep -i 'cpu\|booting\|QARMA\|SVE'.
[ 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: GIC system register CPU interface
[ 0.000000] CPU features: detected: Hardware dirty bit management
[ 0.000000] CPU features: detected: Spectre-v4
[ 0.000000] CPU features: detected: Spectre-BHB
[ 0.000493] smp: Bringing up secondary CPUs ...
[ 0.000494] smp: Brought up 1 node, 1 CPU
[ 0.000496] CPU features: detected: Branch Target Identification
[ 0.000499] CPU features: detected: CRC32 instructions
[ 0.000500] CPU features: detected: Enhanced Counter Virtualization
[ 0.000501] CPU features: detected: Generic authentication (architected QARMA3 algorithm)
[ 0.000502] CPU features: detected: LSE atomic instructions
[ 0.000503] CPU features: detected: RAS Extension Support
[ 0.000503] CPU features: detected: Random Number Generator
[ 0.000506] CPU features: detected: Scalable Vector Extension
[ 0.000535] CPU: All CPU(s) started at EL1
- [0x410fd841] — The ID of the boot CPU. It breaks down as 0x41 = ARM, 0xd84 = Neoverse V3, revision 1
- QARMA3 algorithm — The pointer authentication (PAC) algorithm is QARMA3. It was QARMA5 on Graviton4
- Scalable Vector Extension — Detection of SVE can be confirmed
- Branch Target Identification — Security hardening through BTI (restriction of indirect branch targets)
lstopo-no-graphics
I also visualized the cache hierarchy confirmed with lscpu using lstopo (hwloc).
lstopo-no-graphics output
Machine (3782MB total)
Package L#0
NUMANode L#0 (P#0 3782MB)
L3 L#0 (48MB) + L2 L#0 (2048KB) + L1d L#0 (64KB) + L1i L#0 (64KB) + Core L#0 + PU L#0 (P#0)
HostBridge
PCI 00:04.0 (NVMExp)
Block(Disk) "nvme0n1"
HostBridge
PCIBridge
PCIBridge
PCIBridge
PCI 27:00.0 (Ethernet)
Net "ens34"
You can confirm the hierarchy of L3 48MB → L2 2048KB → L1d/L1i 64KB, and that NVMe and Ethernet are connected via PCIe (Nitro System).
nvme id-ctrl (EBS NVMe controller)
NVME Identify Controller:
vid : 0x1d0f
ssvid : 0x1d0f
mn : Amazon Elastic Block Store
fr : 2.0
rab : 32
ieee : a002dc
mdts : 6
cntlid : 0
ver : 0x10400
- vid: 0x1d0f — Amazon's PCI Vendor ID
- fr: 2.0 — The revision of the EBS NVMe firmware. The same 2.0 was also confirmed on M8g (Graviton4)
- ver: 0x10400 — Conforms to NVMe spec 1.4
SVE Vector Length
I checked the default SVE vector length from /proc/sys/abi/sve_default_vector_length.
$ cat /proc/sys/abi/sve_default_vector_length
16
16 bytes = 128 bits. I confirmed that M8g (Graviton4) also has the same 128 bits, so from Graviton4 onward the width is unified at 128 bit. It was Graviton3 (Neoverse V1) that had 256 bits.
Neoverse V3 is an SVE implementation with 128-bit width. The SVE2 instruction set itself is available (sveaes, svepmull, svebitperm, svesha3).
Cost Comparison
I compared the On-Demand prices of M9g and M8g. These are the us-east-1 / Linux / On-Demand prices obtained from the AWS Pricing API (GetProducts) (retrieved on 2026/6/11).
| Size | M9g (USD/hour) | M8g (USD/hour) | Difference |
|---|---|---|---|
| medium | 0.04892 | 0.04488 | +9.0% |
| large | 0.09784 | 0.08976 | +9.0% |
| xlarge | 0.19568 | 0.17952 | +9.0% |
| 2xlarge | 0.39136 | 0.35904 | +9.0% |
| 4xlarge | 0.78272 | 0.71808 | +9.0% |
| 8xlarge | 1.56544 | 1.43616 | +9.0% |
| 12xlarge | 2.34816 | 2.15424 | +9.0% |
| 16xlarge | 3.13088 | 2.87232 | +9.0% |
| 24xlarge | 4.69632 | 4.30848 | +9.0% |
| 48xlarge | 9.39264 | 8.61696 | +9.0% |
| metal-48xl | 9.39264 | 8.61696 | +9.0% |
Pricing is a uniform +9.0% over M8g across all sizes. In a simple calculation that applies the officially announced performance improvement (up to 25%) as is, performance per price improves by up to about 15% (1.25 / 1.09 ≒ 1.147). Actual cost-effectiveness varies by workload.
※ metal-48xl and 48xlarge have the same price, which is usual for the Graviton series, and the values are listed as obtained from the Pricing API.
Summary
I launched an M9g instance and checked the CPU information of Graviton5 / Neoverse V3 using OS commands.
In comparison with M8g (Graviton4), the CPU core changed from Neoverse V2 to Neoverse V3, and the clock frequency increased from 2800 MHz to 3300 MHz. I also confirmed that the L3 cache displayed by lscpu increased from 36 MiB to 48 MiB, and that the pointer authentication algorithm changed from QARMA5 to QARMA3.
On the other hand, the L2 cache (2 MiB), SVE vector length (128 bit), and EBS NVMe firmware (2.0) were the same as M8g. The "1 vCPU = 1 physical core" configuration without SMT, which is a characteristic of the Graviton series, also remains the same.
The price was a uniform +9.0% over M8g across all sizes. Since the official announcement indicates up to 25% compute performance improvement over Graviton4, an improvement in performance per price can be expected depending on the workload. However, actual cost-effectiveness depends on application characteristics, so if you are considering migration, it would be best to obtain benchmarks with your actual workloads and verify.
As of this writing it is not yet available in the Tokyo region, but M9g may become a strong candidate when selecting Graviton-based instances going forward. Even if you are anticipating availability in the Tokyo region, validating the operation and performance of your actual workloads in regions where it is already available will make migration decisions easier once it is offered.
