VM-Level Isolation, AWS Style
AWS Nitro Enclaves takes a pragmatic, operationally simple approach. Instead of requiring application rewrites (like SGX) or a special CPU (like AMD SEV), it carves isolated compute resources out of an existing EC2 instance using the AWS Nitro System — the custom hardware and software stack that underpins all modern EC2 instances.
How Nitro Enclaves Work
-
The Split: You start with a standard EC2 instance (e.g., 4 vCPUs, 16 GB RAM). You instruct the Nitro Hypervisor to partition some of those resources — say, 2 vCPUs and 8 GB RAM — into a separate, isolated VM called the Enclave.
-
The Isolation Guarantees: The Enclave is deliberately stripped of all standard attack surfaces:
- No network interface — cannot make or receive network connections.
- No persistent storage — no EBS volumes, no local disk.
- No interactive access — no SSH, no console, no AWS Systems Manager Session Manager.
-
No metadata service access — cannot query the EC2 instance metadata endpoint.
-
The Only Channel — VSock: The sole communication path between the parent EC2 instance and the Enclave is a VSock (Virtual Socket) — a local, in-memory socket that never leaves the physical host. There is no network stack involved.
-
The Trust Model: AWS Nitro Enclaves integrate with AWS KMS (Key Management Service). You can configure a KMS key policy that only releases a decryption key to a verified Nitro Enclave — one that passes Remote Attestation (covered next). This means even if an attacker compromises the parent EC2 instance, they cannot get the KMS key, because they are not inside the Enclave.
Operational simplicity: You package your enclave application as a Docker image, convert it to an Enclave Image File (EIF) using the nitro-cli tool, and launch it. No SGX SDK, no application rewrite.