What are the storage and networking limits in Nitro Enclaves?

Amazon EC2 Nitro Enclaves are isolated compute environments engineered with strict hardware and architectural boundaries that eliminate all direct persistent storage and external network connectivity. This overview explains how an enclave operates exclusively in volatile system memory allocated from its parent instance, completely detached from block storage volumes and Elastic Network Interfaces, while relying on a local virtual socket channel for all input and output operations.

Persistent Storage Constraints

An Amazon EC2 Nitro Enclave has no attached persistent storage and cannot directly mount external storage services such as Amazon Elastic Block Store (EBS), Amazon Elastic File System (EFS), or Amazon S3. When an enclave is launched from the parent EC2 instance, the Nitro Hypervisor carves out dedicated CPU cores and a fixed portion of system memory from the parent instance's hardware resources.

The entire runtime environment of the enclave, which is packaged as an Enclave Image File (EIF), is loaded directly into this dedicated volatile memory as an initial ramdisk (initramfs). Because the root filesystem resides completely in RAM, several storage constraints apply:

  • Total Volatility: Any files created, modified, or stored inside the enclave's filesystem exist only in memory and are permanently erased as soon as the enclave terminates or the parent instance stops.
  • Memory-Bound Capacity: The available space for both the operating system image, application binaries, and temporary runtime data is strictly bounded by the RAM allocated to the enclave at launch. If the parent instance has total memory \(M_{\text{parent}}\) and allocates \(M_{\text{enclave}}\) to the enclave, the total storage and working memory inside the enclave cannot exceed \(M_{\text{enclave}} < M_{\text{parent}}\).
  • Persistence via Parent Proxy: To persist state or retrieve external datasets, the enclave application must encrypt the data in memory and transmit it over the local virtual socket to a helper process on the parent instance, which then writes the encrypted payload to an EBS volume or external storage service.

External Networking Constraints

Nitro Enclaves have no external network interfaces, no IP addresses, no routing tables for public or VPC traffic, and no access to an Elastic Network Interface (ENI). An enclave cannot directly initiate or accept TCP/IP connections over a Virtual Private Cloud (VPC) or the public internet, nor can it query the EC2 Instance Metadata Service (IMDS) or resolve DNS names directly.

The only communication mechanism available to a Nitro Enclave is a point-to-point virtual socket (AF_VSOCK) interface provided by the Nitro Hypervisor. This virtual socket connects the enclave exclusively to the parent EC2 instance that spawned it.

All network communication must obey the following constraints:

  • CID-Based Addressing: Instead of IP addresses and subnet masks, vsock connections use a 32-bit Context Identifier (CID) and a 32-bit port number. The parent EC2 instance is always assigned a fixed CID of \(3\), while the enclave is assigned a unique CID (such as \(16\)) upon creation.
  • Mandatory Traffic Forwarding: For an enclave to communicate with external endpoints such as AWS Key Management Service (KMS) or a remote HTTPS API, a proxy service (such as vsock-proxy or socat) must run on the parent EC2 instance. The enclave sends frames over the local vsock channel to CID \(3\), and the parent proxy forwards those packets over the parent instance's standard network interface.
  • End-to-End Cryptographic Security: Because the parent EC2 instance acts as an untrusted network relay for all external traffic, the enclave must terminate TLS sessions and perform cryptographic verification inside its own isolated memory space so the parent instance only handles encrypted ciphertext.