Does Amazon EC2 Have Memory Optimized Instances with NVMe?

Amazon EC2 provides several Memory Optimized instance families equipped with physically attached local NVMe SSD volumes. These instances combine high memory-to-vCPU ratios with ultra-low latency block storage, making them ideal for high-performance databases, real-time analytics, and applications requiring rapid temporary cache or swap space. This article explores the specific EC2 instance families that offer this configuration, how their instance store volumes operate, and best practices for managing ephemeral storage.

Memory Optimized Instance Families with Local NVMe

In the Amazon EC2 naming convention, the inclusion of the letter d in the instance family name indicates the presence of physically attached NVMe SSD instance store volumes. Within the Memory Optimized category, AWS offers multiple options across Intel, AMD, and AWS Graviton processors.

R-Series (R5d, R6id, R6gd, R7gd, R8gd)

The R-series is the foundational Memory Optimized family designed for memory-intensive applications such as relational and NoSQL databases, distributed web scale in-memory caches, and real-time big data analytics.

  • R5d and R6id: Powered by Intel Xeon Scalable processors, these instances pair 8 GiB of memory per vCPU with local NVMe SSD storage. R6id instances offer up to 7.6 TB of local NVMe storage with enhanced memory bandwidth and network performance compared to R5d.
  • R6gd, R7gd, and R8gd: Powered by AWS Graviton2, Graviton3, and Graviton4 processors respectively, these Arm-based instances provide substantial price-performance benefits alongside local NVMe SSDs for workloads compatible with the Arm64 architecture.

X-Series (X1e, X2gd, X2idn, X2iedn)

The X-series targets enterprise-class, large-scale in-memory applications, such as SAP Hana, Apache Spark, and Presto, which require higher memory-to-compute ratios than the R-series.

  • X2gd: Powered by AWS Graviton2 processors, delivering 16 GiB of memory per vCPU alongside local NVMe SSD volumes.
  • X2idn and X2iedn: Powered by Intel Xeon Scalable processors, offering 16 GiB and 32 GiB of memory per vCPU respectively. Both include local NVMe storage and up to 100 Gbps of networking throughput.

High-Frequency Instances (z1d)

The z1d instance family delivers both high compute capacity and a high memory footprint. It features an all-core sustained turbo frequency of up to 4.0 GHz paired with up to 1.8 TB of local NVMe instance store capacity. It is frequently chosen for electronic design automation (EDA) and relational database workloads with high per-core licensing costs.

Why Use Local NVMe SSDs for Swap and Cache Storage?

Unlike Amazon Elastic Block Store (EBS), which is network-attached storage, EC2 instance store volumes are physically attached to the host server. This architectural difference yields several operational advantages for swap and caching workloads:

  1. Ultra-Low Latency and High IOPS: Because data does not traverse the network to reach the storage media, local NVMe drives deliver random read IOPS in the hundreds of thousands and sub-millisecond latency.
  2. Cost Efficiency: The cost of the local NVMe storage is included in the hourly or per-second price of the EC2 instance. You do not pay separate storage provisioning fees or per-IO charges.
  3. Dedicated Bandwidth: Utilizing local NVMe for heavy temporary read/write operations preserves your instance's network and EBS bandwidth for persistent data transfers and client traffic.

When calculating total memory capacity alongside swap space, the effective addressable memory \(M_{\text{total}}\) can be modeled as:

\[M_{\text{total}} = M_{\text{RAM}} + S_{\text{NVMe}}\]

While NVMe SSDs are orders of magnitude faster than traditional spinning disks, their access latency \(L_{\text{NVMe}}\) is still higher than system RAM latency \(L_{\text{RAM}}\):

\[L_{\text{RAM}} \ll L_{\text{NVMe}} < L_{\text{EBS}}\]

Therefore, local NVMe volumes are best used as an overflow safety net for swap or as a high-speed secondary tier (L2 cache) behind system memory.

Understanding Ephemeral Storage Lifecycle

Before configuring swap or cache directories on local NVMe volumes, it is critical to understand that EC2 instance store volumes are ephemeral. Data written to these volumes persists only during the lifecycle of the associated instance.

Data on local NVMe volumes remains intact when:

  • The operating system is rebooted (via the OS or the RebootInstances API).

Data on local NVMe volumes is permanently lost when:

  • The instance is stopped or hibernated.
  • The instance is terminated.
  • The underlying physical host drive experiences a hardware failure.

Because of this behavior, you should never store primary, un-replicated persistent data on instance store volumes. They should strictly be used for temporary storage, such as swap space, buffer pools, scratch data, or caches that can be reconstructed or tolerated if lost.

Configuring Local NVMe Volumes for Swap or Cache

When an instance with local NVMe storage launches, the volumes are exposed to the operating system as block devices (typically /dev/nvme1n1, /dev/nvme2n1, etc.), though they are not formatted or mounted by default on most standard AMIs.

To automate the setup of swap and cache across instance stop/start cycles, you should place configuration scripts in your EC2 User Data or systemd startup units.

Setting Up a Local NVMe Volume as Swap

To configure /dev/nvme1n1 as swap space on a Linux instance:

# Create the swap area on the NVMe device
sudo mkswap /dev/nvme1n1

# Enable the swap device
sudo swapon /dev/nvme1n1

# Verify that the swap space is active
swapon --show

You can also tune the kernel vm.swappiness parameter to control how aggressively the operating system moves memory pages to the NVMe swap volume:

# Set swappiness to a low value (e.g., 10) to prefer RAM over swap
sudo sysctl vm.swappiness=10

Setting Up a Local NVMe Volume as a Cache Directory

To format and mount an NVMe volume for application caching:

# Format the device with the XFS or ext4 filesystem
sudo mkfs.xfs /dev/nvme1n1

# Create the mount point
sudo mkdir -p /mnt/nvme-cache

# Mount the volume with noatime to reduce unnecessary metadata writes
sudo mount -o defaults,noatime /dev/nvme1n1 /mnt/nvme-cache

If your chosen instance size includes multiple NVMe drives (such as an r6id.16xlarge, which includes two 1900 GB NVMe SSDs), you can combine them into a RAID 0 array using mdadm to aggregate capacity and maximize throughput:

\[\text{Throughput}_{\text{RAID0}} \approx N \times \text{Throughput}_{\text{Single Drive}}\]

where \(N\) is the number of striped NVMe volumes.

Hardware Encryption on Instance Store Volumes

For security compliance, modern AWS Nitro-based Memory Optimized instances (such as R5d, R6id, R6gd, R7gd, and X2 series) automatically encrypt all data written to local NVMe instance store volumes using an XTS-AES-256 block cipher implemented in a hardware module on the Nitro card. The encryption keys are generated uniquely for each volume and are destroyed when the instance stops or terminates, ensuring zero performance overhead and complete cryptographic erasure between lifecycles.