Confidential computing

How it works

Encryption at rest and in transit leaves a gap: to work on data, a program has to decrypt it in memory, where the kernel, the hypervisor and anyone who controls them can read it. Confidential computing closes the gap with a trusted execution environment (TEE), a region the CPU or a trusted hypervisor walls off from everything else on the machine. There are three common shapes. A process enclave, such as Intel SGX, protects part of one application’s memory; the rest of the program and the operating system stay outside, so applications must be written for enclaves or wrapped in a library OS such as Gramine. A confidential VM, built on AMD SEV-SNP or Intel TDX, protects a whole virtual machine: the CPU encrypts its memory with a key generated inside the processor that the hypervisor never sees, so an ordinary guest OS and unmodified software run inside. A hypervisor-isolated enclave, such as AWS Nitro Enclaves, carves vCPUs and memory off a parent instance into a separate VM with no storage, networking or login, reachable only over a local socket. Isolation alone proves nothing to the outside world, so every TEE supports attestation: the hardware signs a report containing a measurement, a hash of the code and initial state that was loaded, and a verifier checks the signature back to the vendor’s root key and the measurement against the value it expects. Only then does a key service release the secrets, such as a database key or a model’s weights, and it can bind them to that exact measurement, so a changed binary gets nothing.

Reach for it when

• Processing data you must not expose to the cloud operator or your own administrators, such as payment card numbers, health records or private keys, on shared infrastructure
• Several parties pooling sensitive data for a joint computation that none of them should see in full, such as fraud models across banks
• Releasing secrets only to a specific, measured build: a key service checks attestation before handing over a key, so a tampered or debug build gets nothing
• Regulations or contracts that ask for protection of data in use, not just at rest and in transit

Think twice when

• Your threat is a bug in your own application: a TEE protects code from the host, not from itself, and an injection flaw inside the enclave still leaks data
• You need to trust nobody at all: the CPU vendor’s hardware and firmware, or with Nitro Enclaves the cloud provider’s hypervisor, stay in the trusted base
• The workload can’t tolerate the restrictions: enclaves add overhead (up to 2x in Graphene-SGX’s measurements), Nitro Enclaves have no network or disk, and only some instance types and regions offer each TEE
• Nothing checks attestation: without a verifier and a key policy tied to the measurement, a TEE is only memory encryption

Technologies

Specific products, and what each does differently.

GramineOpen sourceA library OS that runs unmodified Linux applications, including multi-process ones, inside Intel SGX enclaves, with a manifest that pins every trusted file and built-in remote attestation.

What each provider calls it

AWS

Nitro Enclaves: isolated VMs carved from an EC2 instance, reachable only over a local socket, with attestation built into KMS key policies, at no extra charge. AMD SEV-SNP on M6a, C6a and R6a instances, at 10% of the On-Demand rate extra on shared tenancy

Google Cloud

Confidential VM on AMD SEV, AMD SEV-SNP or Intel TDX; Confidential GKE Nodes; Confidential Space for sharing data with an agreed workload; NVIDIA confidential GPUs on AMD SEV or Intel TDX

Azure

Confidential VMs on AMD SEV-SNP (DCasv5, ECasv5) and Intel TDX (DCesv6, ECesv6), confidential H100 GPU VMs, confidential AKS nodes, confidential containers on Container Instances and Azure Attestation. The Intel SGX enclave VMs (DCsv3) retire on October 31, 2029

Open source & others

Confidential Computing Consortium projects such as Gramine (LGPL 3.0), Open Enclave SDK, Veraison and COCONUT-SVSM; Confidential Containers, a CNCF incubating project