How Do EC2 Graviton vCPUs Map Directly to Physical Cores?

When each virtual CPU on an Amazon EC2 Graviton instance maps directly to a dedicated physical processor core without simultaneous multithreading, workloads gain predictable performance, dedicated cache resources, and enhanced hardware-level security isolation. Unlike traditional x86 processors that split a single physical core into two logical threads, AWS Graviton processors allocate an entire physical Arm Neoverse core to each vCPU. This architecture eliminates thread-level resource contention on the same core, resulting in linear scalability, lower tail latency, and improved energy efficiency for cloud-native applications, databases, and microservices.

Understanding Traditional x86 Simultaneous Multithreading vs Graviton Physical Cores

In most x86-based Amazon EC2 instances powered by Intel Xeon or AMD EPYC processors, Simultaneous Multithreading (SMT)—commonly known as Hyper-Threading on Intel platforms—is enabled by default. Under an SMT architecture, a single physical CPU core exposes two logical execution threads to the operating system. In the context of EC2, each of these logical threads is provisioned as a single vCPU:

\[\text{vCPUs}_{\text{x86}} = 2 \times \text{Physical Cores}\]

While SMT improves overall throughput when threads are stalled waiting on memory fetches, both vCPUs on the same physical core must share critical internal execution units, including the Arithmetic Logic Units (ALUs), Floating Point Units (FPUs), and L1 and L2 CPU caches.

By contrast, AWS Graviton processors (Graviton, Graviton2, Graviton3, and Graviton4) do not use SMT. Every vCPU on a Graviton instance corresponds to a complete, independent physical core:

\[\text{vCPUs}_{\text{Graviton}} = 1 \times \text{Physical Cores}\]

Because there are no sibling threads competing for execution pipelines inside the core, each vCPU operates as a self-contained processing unit.

Elimination of Intra-Core Resource Contention

When two threads share a physical core under SMT, a compute-intensive workload running on one thread directly degrades the performance of the sibling thread. This phenomenon, often referred to as the noisy neighbor effect at the microarchitectural level, causes unpredictable instruction execution times.

With Graviton's 1:1 vCPU-to-physical-core mapping, every vCPU has exclusive access to its own:

Instruction fetch and decode pipelines
Integer and vector execution units (including Neon and SVE units)
Branch prediction buffers and Translation Lookaside Buffers (TLBs)

Because a vCPU never waits for a sibling thread to release an execution pipeline, CPU utilization metrics reported by the operating system accurately reflect actual hardware capacity. On SMT-enabled instances, moving from \(50\%\) to \(100\%\) CPU utilization often yields only a \(15\%\) to \(30\%\) increase in actual throughput because the second thread is scavenging unused cycles from the first. On Graviton instances, throughput scales almost linearly with CPU utilization all the way up to \(100\%\):

\[T(u) \approx u \cdot T_{\max} \quad \text{for } u \in [0, 1]\]

where \(T(u)\) is the application throughput at utilization rate \(u\), and \(T_{\max}\) is the maximum physical core throughput.

Dedicated Cache Hierarchy and Memory Bandwidth

Memory latency is one of the primary bottlenecks in modern cloud workloads, particularly for in-memory caches like Redis, relational databases like PostgreSQL, and containerized microservices.

On an x86 instance with SMT, two vCPUs share the same L1 instruction cache, L1 data cache, and L2 cache. If one thread executes a memory-intensive operation, it can evict cache lines belonging to the sibling thread, leading to higher cache miss rates and frequent fetches from slower L3 cache or main memory (DRAM).

On EC2 Graviton instances, each vCPU receives dedicated L1 and L2 caches:

Graviton2 and Graviton3: Each vCPU has a private \(64\text{ KB}\) L1 instruction cache, a \(64\text{ KB}\) L1 data cache, and a private \(1\text{ MB}\) L2 cache.
Graviton4: Each vCPU doubles the private L2 cache to \(2\text{ MB}\) per physical core.

Having a dedicated L2 cache per vCPU significantly reduces cache thrashing and context-switch penalties. Workloads maintain higher cache hit ratios, keeping the average memory access time (\(T_{\text{avg}}\)) low:

\[T_{\text{avg}} = H_{\text{L1}} T_{\text{L1}} + (1 - H_{\text{L1}}) \left[ H_{\text{L2}} T_{\text{L2}} + (1 - H_{\text{L2}}) T_{\text{memory}} \right]\]

where \(H_{\text{L1}}\) and \(H_{\text{L2}}\) represent the hit rates of the dedicated L1 and L2 caches, and \(T_{\text{L1}}\), \(T_{\text{L2}}\), and \(T_{\text{memory}}\) represent their respective access latencies.

Predictable Tail Latency (P99 and P99.9)

For latency-sensitive applications such as high-frequency trading, real-time bidding, API gateways, and interactive web services, average latency is far less important than tail latency—specifically the 99th percentile (\(P_{99}\)) and 99.9th percentile (\(P_{99.9}\)) response times.

In SMT architectures, tail latency spikes frequently occur when two demanding requests are scheduled onto sibling hyperthreads of the same physical core simultaneously. Both requests experience pipeline stalls and cache evictions, causing response times to jump even when overall cluster utilization is moderate.

Because Graviton vCPUs are backed by independent physical cores, the variance in request service time (\(\sigma^2\)) is substantially lower. Operating system schedulers (such as the Linux Completely Fair Scheduler) do not need complex topology-aware logic to avoid scheduling two heavy tasks onto sibling threads of the same core, because sibling threads do not exist. This results in a tighter latency distribution and significantly lower \(P_{99}\) and \(P_{99.9}\) latencies under high load.

Enhanced Security and Side-Channel Isolation

Simultaneous multithreading has historically introduced classes of microarchitectural side-channel vulnerabilities—such as Microarchitectural Data Sampling (MDS), L1 Terminal Fault (L1TF), and variants of Spectre—that exploit the sharing of execution units, caches, and buffers between two threads on the same core. Mitigating these vulnerabilities on x86 processors often requires kernel-level patches, microcode updates, or core scheduling techniques that flush buffers on context switches, introducing measurable performance overhead.

When each vCPU maps directly to a physical core without SMT:

Cross-thread side-channel attacks within a single core are eliminated by design because no two threads ever share core pipeline state simultaneously.
Security-sensitive workloads do not need to disable half of their vCPUs (which happens when disabling Hyper-Threading on x86 instances) to achieve physical core isolation.
Combined with always-on DRAM encryption and pointer authentication in newer Graviton generations, the lack of SMT provides strong hardware isolation without sacrificing compute density.

Impact on Instance Sizing and Cost Optimization

When migrating workloads from x86 EC2 instances to Graviton instances, the 1:1 physical core mapping directly affects capacity planning and right-sizing:

Higher Per-vCPU Throughput under Load: While a lightly loaded x86 vCPU may exhibit high single-thread burst clock speeds, a fully loaded Graviton instance delivers more consistent aggregate compute power per vCPU because its cores are not splitting execution cycles between two threads.
Headroom Buffer Reduction: Engineering teams often over-provision x86 instances, setting auto-scaling thresholds at \(50\%\) or \(60\%\) CPU utilization to prevent SMT contention from degrading tail latencies. With Graviton, teams can safely raise target CPU utilization thresholds to \(75\%\) or \(80\%\) without experiencing sudden latency cliffs, reducing the total number of instances required.
Software Licensing Efficiency: For commercial software licensed per vCPU, having a full physical core behind every vCPU ensures maximum compute work is extracted from each licensed unit, rather than paying for logical threads that only offer fractional performance gains.