What Are AWS Graviton Memory Encryption and Cache Features?

AWS Graviton processors on Amazon EC2 provide hardware-level security through always-on DRAM memory encryption and dedicated physical cores that ensure strict cache isolation. Each Graviton vCPU maps directly to a physical processor core without simultaneous multithreading, eliminating shared L1 and L2 cache side-channel risks between threads. Additionally, the integrated memory controllers encrypt all data stored in main memory using ephemeral keys generated at boot time, safeguarding workloads against physical memory inspection and cross-tenant interference.

Always-On Memory Encryption

Every generation of AWS Graviton processors (starting from Graviton2 through Graviton3 and Graviton4) includes dedicated inline encryption engines integrated directly into the memory controllers. Unlike architectures where memory encryption is an optional feature that introduces noticeable latency, Graviton processors enforce DRAM encryption by default with negligible performance overhead.

How DRAM Encryption Works on Graviton

When an Amazon EC2 instance powered by an AWS Graviton processor boots or resets, the hardware generates random, ephemeral encryption keys using an internal hardware random number generator. These keys exist strictly within the processor silicon and are never exposed to the operating system, user software, or the underlying AWS Nitro System hypervisor.

Every write operation from the processor cache hierarchy to external DDR4 or DDR5 system memory passes through the inline encryption engine, which encrypts the cache line using 256-bit XTS-AES encryption. Conversely, every read operation from DRAM is decrypted as it enters the processor package. When the instance is stopped, terminated, or rebooted, the ephemeral keys are cryptographically destroyed, rendering any residual data in the physical memory modules unreadable.

Because each physical processor socket generates and maintains its own isolated encryption keys, memory encryption provides strong cryptographic isolation across instance boundaries and protects against cold-boot or physical bus-probing attacks.

Physical Core Mapping and Cache Isolation

One of the defining architectural security advantages of AWS Graviton processors over traditional x86 server processors is the absence of Simultaneous Multithreading (SMT), commonly known as Hyper-Threading.

In many conventional cloud instances, a single virtual CPU (vCPU) corresponds to a single hardware thread sharing a physical core with another thread. While this increases thread density, it forces two execution contexts to share internal core execution pipelines, Translation Lookaside Buffers (TLBs), and Level 1 (L1) and Level 2 (L2) caches. This resource sharing has historically enabled microarchitectural side-channel vulnerabilities such as Spectre, Meltdown, L1 Terminal Fault (L1TF), and Microarchitectural Data Sampling (MDS).

On AWS Graviton instances, the mapping between virtual and physical resources is strictly linear:

\[\text{1 vCPU} = \text{1 Physical Core}\]

Because there are no sibling threads sharing a physical core, each vCPU receives exclusive access to its core execution units and private cache levels.

L1 and L2 Cache Isolation

Each physical core in an AWS Graviton processor features its own dedicated Level 1 instruction cache, Level 1 data cache, and unified Level 2 cache:

• Graviton2: 64 KB L1 instruction cache, 64 KB L1 data cache, and 1 MB private L2 cache per vCPU.
• Graviton3: 64 KB L1 instruction cache, 64 KB L1 data cache, and 1 MB private L2 cache per vCPU.
• Graviton4: 64 KB L1 instruction cache, 64 KB L1 data cache, and 2 MB private L2 cache per vCPU.

Because L1 and L2 caches are never shared between different vCPUs, workloads running on separate vCPUs cannot observe or evict each other's L1 or L2 cache lines. This design provides complete hardware isolation at the core level, mitigating cross-thread cache timing attacks without requiring performance-degrading operating system mitigations like core scheduling or kernel page-table isolation.

System Level Cache (SLC) Management

At the socket level, Graviton processors implement a coherent mesh interconnect with a shared System Level Cache (SLC), which acts as a Level 3 (L3) cache across the cores on the die (32 MB on Graviton2, 32 MB on Graviton3, and 36 MB per die on Graviton4).

To maintain isolation across multi-tenant instances sharing a single physical processor socket, the AWS Nitro System hypervisor leverages Armv8 and Armv9 architecture partitioning extensions and strict memory tagging and address space isolation. Because the Nitro Hypervisor statically assigns physical cores and physical memory regions to individual EC2 instances without overcommitting CPU or RAM, one EC2 instance cannot access or alias the physical memory addresses of another instance in the shared SLC. Furthermore, hardware cache flushing and invalidation mechanisms ensure that when a core is reassigned to a new instance after termination, all private and shared cache lines associated with the previous instance are cleared.

Additional Microarchitectural Security Features

Beyond DRAM encryption and physical core cache isolation, later generations of AWS Graviton integrate advanced Arm security extensions that harden memory access and control flow within the CPU cache and memory hierarchy:

Pointer Authentication (PAC) and Branch Target Identification (BTI)

Introduced in Graviton3 (Armv8.4-A) and carried forward into Graviton4 (Armv9.0-A), Pointer Authentication signs memory pointers using a cryptographic hash stored in the unused upper bits of a 64-bit pointer address before the pointer is written to the cache or stack. If an attacker exploits a buffer overflow to overwrite a return address in memory or cache, the CPU signature verification fails before jumping to the corrupted address, preventing Return-Oriented Programming (ROP) attacks. Branch Target Identification complements PAC by ensuring indirect branches only land on valid instruction targets, mitigating Jump-Oriented Programming (JOP) exploits.

Encrypted High-Speed Coherent Interconnects

On multi-socket instances such as those powered by Graviton4 (for example, r8g.48xlarge), where two processor sockets work together as a coherent Non-Uniform Memory Access (NUMA) system, memory and cache coherency traffic travels across high-speed socket-to-socket interconnects. Graviton4 extends hardware encryption beyond the DRAM controllers to encrypt all high-speed coherent interconnect links and PCIe interfaces directly in hardware, ensuring data remains encrypted both in memory and in transit between processor sockets.

Hardware Mitigations Against Speculative Execution Attacks

AWS Graviton processors incorporate silicon-level mitigations against speculative execution side-channel vulnerabilities, including Speculative Store Bypass Safe (SSBS), Enhanced Branch Predictor Hardening (CSV2), and Data Value Prediction restrictions. Combined with the 1:1 physical core architecture and the minimal attack surface of the AWS Nitro Hypervisor, these features prevent speculative execution paths from leaking unauthorized data across privilege boundaries via the CPU caches.