Quick Answer: AWS Nitro Enclaves trust AWS's own Nitro Hypervisor for attestation. Intel TDX trusts the CPU silicon itself. For GDPR Article 25 and Schrems II compliance, that difference isn't academic — it's the gap between "we promise" and "physics prevents us."
TL;DR: I spent 3 weeks comparing both stacks for a French fintech's DPO. Nitro Enclaves: 14-23% performance hit, AWS-controlled root of trust, US legal jurisdiction. Intel TDX on bare metal: 3-7% overhead, CPU-bound attestation, EU-hosted. Their DPO picked TDX. Here's the data.
The Attestation Root Problem Nobody Talks About
Every confidential computing pitch sounds identical. "Encrypted memory." "Isolated workloads." "Verifiable trust."
Then you read the fine print.
AWS Nitro Enclaves generates its attestation document from the Nitro Hypervisor. That hypervisor runs on AWS-controlled hardware. AWS issues the certificate. AWS validates it. The root of trust is AWS.
Intel TDX generates attestation from the CPU's own Measurement Root Key (MRK), burned into the silicon at manufacturing. Intel signs the initial certificate, yes. But verification chains to the physical CPU, not the cloud operator. The host — us, VoltageGPU, anyone — is cryptographically excluded.
For regulated workloads, that's the difference between contractual trust and architectural trust.
Why This Matters Now: Schrems II and Data Transfers
The 2020 Schrems II ruling killed Privacy Shield. US cloud providers became legal minefields for EU personal data. The new EU-US Data Privacy Framework (2023) helped, but Article 47 of GDPR still requires "supplementary measures" for sensitive transfers.
Hardware attestation with a non-US root of trust is emerging as one of those measures. Not because lawyers love CPUs. Because regulators are asking: "What technically prevents the cloud operator from accessing this data?"
"Contractual clauses" is the wrong answer. "The CPU encrypts memory and proves it cryptographically" is better.
AWS Nitro Enclaves: How It Actually Works
Nitro Enclaves splits a parent EC2 instance. The enclave runs as a separate, hardened VM. Communication happens only through a vsock channel.
Attestation uses the Nitro Secure Module (NSM). The NSM generates a signed document containing:
- Enclave image hash (PCR0)
- Kernel hash (PCR1)
- Application hash (PCR2)
- AWS-issued certificate
Verification requires AWS's root certificate. You trust AWS issued it correctly. You trust AWS hasn't compromised the NSM. You trust US legal process won't compel AWS to misissue.
Real numbers from our testing (c5.2xlarge parent, enclave with 2 vCPU):
| Metric | Bare Metal EC2 | Nitro Enclave | Overhead |
|---|---|---|---|
| AES-256-GMB throughput | 4.2 GB/s | 3.2 GB/s | 23% |
| RSA-4096 sign/s | 1,840 | 1,582 | 14% |
| Memory latency (random) | 78 ns | 96 ns | 23% |
| Attestation generation | N/A | 45-120 ms | — |
The 14-23% overhead is real. The bigger issue: attestation fails entirely if AWS's NSM service is unreachable. We tested this. Terminate the enclave, restart, NSM handshake required. No offline verification possible.
Intel TDX: CPU-Bound Trust
Intel Trust Domain Extensions (TDX) takes a different approach. The CPU itself creates a "Trust Domain" — a hardware-isolated VM. The TDX Module (firmware) manages it, but the CPU's root key signs the attestation.
Key difference: the attestation report includes a TD Quote. This quote chains to Intel's SGX/TDX root, not the cloud operator. You can verify it against Intel's published collateral without trusting us, without trusting the host, without trusting anyone except Intel's silicon manufacturing.
Our live TDX numbers (Intel Sapphire Rapids, H200 GPU passthrough):
| Metric | Standard VM | TDX Trust Domain | Overhead |
|---|---|---|---|
| LLM inference (tok/s, Qwen3-32B) | 124 | 118 | 4.8% |
| TTFT (ms) | 755 | 798 | 5.7% |
| Memory bandwidth (GB/s) | 320 | 308 | 3.8% |
| Attestation verification | N/A | 12 ms (offline) | — |
The 3-7% TDX overhead is consistent across our fleet. The attestation verifies offline. No network call to VoltageGPU. No network call to Intel. Just cryptography.
The Comparison That Matters
| AWS Nitro Enclaves | Intel TDX (Bare Metal) | |
|---|---|---|
| Attestation root | AWS Nitro Hypervisor | Intel CPU silicon (MRK) |
| Verification dependency | AWS online service | Offline, Intel collateral |
| Performance overhead | 14-23% | 3-7% |
| GPU access | No direct GPU | Full GPU passthrough (H200, B200) |
| Jurisdiction of trust | USA (AWS) | USA (Intel) — but operator-agnostic |
| GDPR Art. 25 alignment | Contractual | Technical (encryption by design) |
| Setup complexity | Moderate (AWS-only) | Higher (bare metal tuning) |
| Cost (comparable GPU) | ~$4.10/hr (g5.48xlarge) | $4.94/hr (H200 TDX) |
One metric where AWS wins: ecosystem maturity. Nitro Enclaves has broader SDK support, more documentation, managed integrations with KMS and ACM. TDX bare metal requires more tuning. We spent 6 hours on TDX Module version compatibility that Nitro handles automatically.
What I Learned the Hard Way
I tried setting up Azure Confidential Computing first. Gave up after 3 hours. TDX on Azure requires specific VM sizes, specific regions, and a 6+ month enterprise agreement for GPU access. The "confidential" label felt like marketing by the time I got to pricing.
AWS Nitro was faster to deploy. Fifteen minutes to first enclave. But then I hit the GPU wall. Nitro Enclaves doesn't support GPU passthrough. For LLM inference — what our fintech actually needed — that's a dealbreaker. They wanted confidential AI, not confidential batch scripts.
Intel TDX on bare metal with H200 passthrough was the only architecture that gave them: GPU acceleration, hardware attestation, and operator-exclusion in one stack.
The Honest Limitation
TDX isn't perfect. The TDX Module is still firmware — Intel firmware, updated by the host operator. If you don't verify the TDX Module version in your attestation policy, a malicious host could run an outdated, vulnerable module. We check this. You should too.
Also: no SOC 2 certification for our TDX stack yet. We rely on GDPR Article 25, Intel TDX attestation, and zero data retention. If your procurement requires SOC 2 Type II, we're not there. Yet.
Verifying Attestation Yourself
Here's real code. No custom SDK. Standard OpenAI client, but the endpoint returns attestation headers:
from openai import OpenAI
import base64
client = OpenAI(
base_url="https://api.voltagegpu.com/v1/confidential",
api_key="vgpu_YOUR_KEY"
)
# Every response includes X-TDX-Attestation header
response = client.chat.completions.create(
model="compliance-officer",
messages=[{"role": "user", "content": "Analyze this DPA for GDPR Article 28 gaps..."}],
extra_headers={"X-Request-Attestation": "true"}
)
# Verify offline against Intel collateral
attestation = response.headers.get("X-TDX-Attestation")
print(f"TD Quote: {base64.b64decode(attestation)[:64].hex()}...")
# Full verification: https://voltagegpu.com/guides/intel-tdx-attestation-verification
print(response.choices[0].message.content)
The attestation header contains the TD Quote. Verify it with Intel's DCAP libraries. No trust in VoltageGPU required.
When to Choose What
Nitro Enclaves fits when: You're all-in AWS, no GPU needs, and contractual trust meets your compliance. Good for payment processing, key management, basic tokenization.
Intel TDX fits when: You need GPU-accelerated AI, operator-exclusion, or Schrems II resilience. Better for LLM inference, multi-modal models, regulated document analysis.
The fintech DPO's final question: "If VoltageGPU receives a US court order, what can you hand over?"
With Nitro Enclaves: potentially the enclave image, potentially KMS logs