Choosing a trusted execution environment used to be an Intel SGX conversation. In 2026 the realistic shortlist for server-side regulated workloads is AMD SEV-SNP, Intel TDX, and AWS Nitro Enclaves, and they are not interchangeable. They differ in threat model, attestation mechanics, I/O plumbing, and whether you can attach a GPU at all. This comparison is written for teams putting regulated data, health records, payment flows, model weights, into infrastructure they do not fully control.
What problem does a TEE solve that disk and TLS encryption do not?
A trusted execution environment protects data in use: while it sits decrypted in RAM and CPU registers. It isolates the workload from the host OS, the hypervisor, and the cloud operator, and it produces remote attestation, hardware-signed evidence of exactly what code booted, which you verify before releasing keys or data to the environment.
That last property is what regulated teams are actually buying. Encryption at rest and TLS already cover storage and transit; a TEE closes the third state and, more importantly, converts a contractual promise (the provider will not look) into a cryptographic control (the workload proves what it is before it receives secrets). Every difference between the three platforms below comes down to how that guarantee is produced, verified, and plumbed into your systems.
How do SEV-SNP, TDX, and Nitro Enclaves differ architecturally?
SEV-SNP and TDX are confidential VMs: the CPU encrypts all guest memory with a per-VM key held in hardware, so a largely unmodified OS and application stack runs inside. Nitro Enclaves is different, an isolated compute partition carved out of a parent EC2 instance, with no network card, no persistent disk, and no interactive access.
- ▸AMD SEV-SNP (EPYC 7003 series and later): per-VM AES memory encryption managed by the AMD Secure Processor, plus integrity protection through the Reverse Map Table, which blocks the hypervisor from remapping or replaying guest pages, the architectural weakness of the earlier SEV and SEV-ES generations.
- ▸Intel TDX (4th-generation Xeon Scalable and later): runs guests as Trust Domains under the SEAM-mode TDX module, with both memory encryption and integrity. Conceptually close to SEV-SNP; the trust anchors, measurement registers, and attestation pipeline differ.
- ▸AWS Nitro Enclaves: not a CPU feature at all. The Nitro hypervisor partitions vCPUs and memory from your instance into a separate environment reachable only over vsock. The isolation claim is architectural, no AWS operator and no parent-instance root can reach in, rather than a per-VM memory-encryption key the guest can prove.
The practical consequence: confidential VMs minimize migration effort, while Nitro Enclaves minimizes the trusted surface but forces a re-architecture of packaging and I/O.
How does remote attestation work on each platform?
All three emit hardware-signed evidence, but the verification chains differ. SEV-SNP reports are signed by a chip-unique VCEK key that chains to the AMD Key Distribution Service. TDX produces quotes over the MRTD and RTMR measurement registers, verified through Intel Trust Authority or self-hosted DCAP collateral. Nitro emits COSE-signed attestation documents carrying PCR values.
- ▸SEV-SNP: the guest requests an attestation report containing the launch measurement, guest policy, and 64 bytes of report data you control (typically a nonce or a hash of an ephemeral public key). Verification tooling includes snpguest and, on Azure, the managed Microsoft Azure Attestation service. Clouds differ on whether you see the raw report or a paravisor-mediated one, check this per provider before you commit.
- ▸Intel TDX: MRTD measures the initial TD image; four RTMRs extend at runtime the way TPM PCRs do, letting you measure kernel, initrd, and application layers separately. Quotes are produced via the host quoting infrastructure and verified against Intel-provided collateral.
- ▸Nitro Enclaves: the enclave image hash lands in PCR0 and the signing certificate in PCR8. The standout integration is AWS KMS condition keys, a key policy can require a valid attestation document with specific PCR values before a Decrypt call succeeds, which gives you attestation-gated key release without writing a custom verifier.
The recurring anti-pattern we see in reviews is identical on all three platforms: the TEE is enabled, but nothing ever verifies attestation. If no component in your system refuses to hand a secret to an unattested environment, the control has quietly degraded into a checkbox.
What does I/O look like inside each TEE?
Confidential VMs keep ordinary virtio networking and block storage, but every byte crossing the VM boundary passes through shared bounce buffers outside the encrypted region, so you still need TLS on the wire and disk encryption inside the guest. Nitro Enclaves has no NIC and no disk; every interaction flows over vsock through code you write on the parent instance.
- ▸On SEV-SNP and TDX, pair dm-crypt for confidentiality with dm-verity for integrity, and gate the disk unlock key on successful attestation so the root filesystem only opens inside a verified guest.
- ▸Expect the bounce-buffer path (SWIOTLB) to tax I/O-heavy workloads; benchmark your actual database or proxy rather than extrapolating from CPU benchmarks.
- ▸On Nitro, AWS ships a vsock proxy for reaching KMS; everything else is yours to build. A common design terminates TLS inside the enclave so the parent instance only ever forwards ciphertext it cannot read.
Which TEE has a workable GPU story for confidential AI?
Only the confidential-VM route. NVIDIA GPUs from the Hopper generation onward (H100, H200, and successors) implement a confidential-computing mode designed to pair with a SEV-SNP or TDX host VM: PCIe transfers are encrypted, and the GPU produces its own attestation verifiable against NVIDIA attestation services. Nitro Enclaves does not support GPUs.
We covered the GPU side, driver stack, encrypted VRAM behavior, and the throughput cost, in Confidential AI Inference on GPUs: Running LLMs with NVIDIA TEE and Encrypted VRAM. For platform selection the short version is: if regulated inference is anywhere on your roadmap, that requirement alone eliminates Nitro Enclaves and narrows the question to which cloud offers Hopper-class GPUs attached to confidential VMs in your region. That availability is still uneven, so verify it before you architect around it.
What performance and operational overhead should you budget?
For CPU-bound work, overheads on SEV-SNP and TDX are typically in the low single-digit percentages; I/O-heavy workloads see more because of bounce-buffer copies. Nitro Enclaves adds little runtime penalty but permanently reserves the vCPUs and memory you assign it. On all three, the dominant cost is engineering time for attestation plumbing, not lost throughput.
Budget real effort for:
- ▸Measurement management: every kernel, firmware, or image update changes launch measurements, so attestation policies must update in lockstep. Automate this in your release pipeline or the verification layer rots within months.
- ▸Debugging constraints: production TEEs restrict introspection by design. Build structured logging and failure paths early, because attaching a debugger is either impossible or breaks attestation.
- ▸Key-release design: decide which secrets are gated on attestation, what happens during host maintenance events, and how you rotate when a measurement changes. This design work, not the hypervisor flag, is the project.
How do TEEs map to GDPR, DORA, and NIS2 obligations?
No EU regulation names a specific TEE technology. Confidential computing functions as a strong technical measure under the state-of-the-art language of GDPR Article 32, supports supplementary-measures arguments for third-country processing, and gives DORA and NIS2 programs concrete, logged evidence of confidentiality controls. Treat it as evidence, not exemption, and validate interpretations with counsel.
- ▸For residency-driven architectures, a TEE strengthens but does not replace data-locality controls, the trade-offs are mapped in Sovereign Cloud and EU Data Residency in 2026: An Engineering Playbook.
- ▸Financial-sector teams can fold attestation verification logs into their resilience evidence; DORA in Practice: What Resilience Really Asks of Your Stack shows where that evidence lands in the framework.
- ▸Attestation-gated key release also composes naturally with the secretless patterns in The End of the Long-Lived API Key: Workload Identity and Secretless Architecture in 2026, the attestation document becomes the workload credential.
Which TEE should you choose? A decision framework
Choose by workload shape, not vendor preference. Lifting an existing regulated VM: SEV-SNP or TDX, decided by which cloud and region you run in. A narrow, high-assurance function on AWS, key custody, signing, PII tokenization: Nitro Enclaves. GPU inference over sensitive data: a confidential VM with a Hopper-class GPU is currently the only real option.
- ▸Existing application, minimal rework: a confidential VM. SEV-SNP currently has the broadest cross-cloud availability, with TDX instance families expanding, verify current offerings rather than assuming parity.
- ▸Highest-assurance narrow function on AWS: Nitro Enclaves. The KMS attestation integration is the most production-ready key-release story of the three, and the small trusted surface is easier to reason about in an audit.
- ▸Multi-cloud or sovereignty requirements: confidential VMs with a portable, self-hosted attestation verification layer, so your trust decisions are not welded to one provider's attestation service.
- ▸Confidential AI: confidential VM plus GPU confidential-computing mode; validate regional availability and driver maturity early in the project.
How TuniCyberLabs helps
We design and build confidential-computing deployments for regulated EU workloads: threat modeling, confidential VM and enclave architecture, attestation verification pipelines, and key-release policies auditors can follow. If you are weighing TEEs for a specific workload, talk to our engineers, a short architecture review usually settles the platform question in days rather than months.