AWS Nitro Enclaves

An enclave has no attached storage of any kind—no instance store volumes, no EBS volumes, no ephemeral disks. The only data available is what is explicitly copied into the enclave's memory during initialization. This design eliminates an entire class of attacks that target data-at-rest. Any output that must survive enclave termination must be encrypted and sent to the parent instance via the vsock, where the parent handles persistence. This constraint forces architects to treat the enclave as a pure, stateless compute function.

There is no SSH, no serial console, no debugger, and no shell inside an AWS Nitro Enclave. Once launched, the enclave is a cryptographic black box. The only communication channel is a local virtual socket (vsock) to the parent EC2 instance. This constraint prevents even privileged cloud operators from inspecting the enclave's memory or runtime state. Debugging must be done through structured logging emitted over vsock, fundamentally shifting operational practices toward design-for-auditability rather than interactive troubleshooting.

An enclave has no network interface, no IP address, and no ability to make outbound connections. It cannot reach the internet, other instances, or AWS APIs. All external communication must be proxied through the parent instance over the vsock channel. This network isolation ensures that even if an attacker compromises the enclave's application logic, they cannot exfiltrate data directly. The parent instance acts as a mandatory network guard, enforcing policy on what data leaves the enclave boundary.

Enclaves run on the same Nitro hypervisor that isolates all EC2 instances, but with an additional layer of separation. The Nitro system uses a dedicated hardware card (the Nitro Security Chip) that manages the enclave's memory encryption keys. The hypervisor enforces that the parent instance cannot read the enclave's memory, and vice versa. This is not software isolation—it is hardware-enforced memory partitioning backed by the Nitro Controller, which operates outside the reach of the host operating system.

Before trusting an enclave with sensitive data, a client can demand cryptographic proof of its identity and integrity. The Nitro Security Chip generates an attestation document containing:

• Platform Configuration Registers (PCRs): Hashes of the enclave image, kernel, and bootstrap parameters
• Instance identity: Binding to the specific EC2 instance
• AWS signature: Verifiable against the AWS Nitro Attestation PKI This allows a remote system to verify that the exact intended code is running in an authentic Nitro Enclave before releasing decryption keys or accepting results.

The sole I/O primitive available to an enclave is a local virtual socket (vsock) connection to the parent EC2 instance. This is a point-to-point, host-internal channel with no routing capabilities. The parent instance typically runs a proxy application that brokers communication between the enclave and external services, enforcing authentication, rate limiting, and data filtering. This architecture creates a natural choke point for security policy enforcement, ensuring no data enters or leaves the enclave without passing through a controlled, auditable intermediary.

A mechanism that allows a TEE to encrypt data for persistent storage by binding it to a specific enclave identity. Sealed data can only be decrypted by the same application on the same platform.

• Prevents host-level access to sensitive persisted data
• Binds encryption keys to the enclave's measurement and platform identity
• Enables stateful confidential workloads without exposing secrets to the host
• Used in Nitro Enclaves for secure key material storage across restarts

The protection of data while it is actively being processed in memory. Unlike data-at-rest (disk encryption) or data-in-transit (TLS), data-in-use encryption closes the final gap in the confidential computing triad.

• Prevents memory scraping by the host OS or hypervisor
• AWS Nitro Enclaves achieve this through dedicated, isolated memory inaccessible to the parent instance
• Essential for processing PII, financial data, and proprietary AI model weights
• Complements AWS KMS for end-to-end cryptographic protection

The set of all hardware, firmware, and software components critical to a system's security. A smaller TCB reduces the attack surface and simplifies formal verification.

• AWS Nitro Enclaves have a minimal TCB with no persistent storage, interactive access, or external networking
• Excludes the Linux kernel, drivers, and userspace of the parent instance
• Reduces exposure to zero-day vulnerabilities in the host stack
• The Nitro hypervisor itself is a lightweight, verified component

A model serving endpoint that runs entirely within a TEE, ensuring that client input data and proprietary model parameters are invisible to the cloud provider. AWS Nitro Enclaves enable this by isolating the inference engine.

• Protects intellectual property embedded in model weights from infrastructure operators
• Ensures user prompts and responses are never exposed to the host
• Enables sovereign AI deployments where data must remain jurisdictionally bound
• Used with AWS KMS for secure model decryption only within the attested enclave