Okay, I’ll probably get roasted for this, but after trying to build a prototype for a financial agent workload across all three platforms, I’m convinced that for *regulated* deployments (think FINRA, HIPAA, where you need clear attestation and control), AWS Nitro Enclaves introduce more hidden complexity than AMD SEV-SNP on-prem.

Don’t get me wrong—Nitro is brilliant for cloud-native lift-and-shift. But when your compliance team asks for a hardware-rooted chain of trust you can map end-to-end, things get fuzzy. With SEV-SNP, I get a direct, verifiable attestation report from the AMD PSP. With Nitro, my attestation document is signed by… the Nitro Hypervisor. Which AWS controls. The chain ultimately roots to the Nitro Security Chip, but the evidence I’m given is a cloud API call away.

The operational blind spot is in the parent instance. A compromised parent can starve the enclave of resources or tamper with the vsocket connection before encryption. Yes, there’s no network path in, but the parent’s role is huge. In our threat model, that’s a high-trust component outside the TCB that we have to harden ourselves. With SEV-SNP on our own hardware, we can lock down the host OS more aggressively and measure it at launch.

Here’s a snippet from our agent’s init that shows the difference in attestation handling we had to implement for Nitro vs. SEV-SNP:

```python
# For SEV-SNP, we pull and validate the hardware report locally
def validate_snp_report(quote):
# verify AMD ARK, ASK certs, chip ID, policy flags
# all locally verifiable with trusted certs
...

# For Nitro, we must call the AWS KMS 'Decrypt' API with the attestation doc
# This trusts AWS KMS to validate the doc for us
def validate_nitro_attestation(doc_bytes):
kms_client.decrypt(
CiphertextBlob=encrypted_key,
EncryptionContext={'attestation_document': doc_bytes}
)
# If KMS decrypts, AWS says the enclave is legit
# But what if my network is proxied? What if KMS is having a bad day?
```

This KMS delegation is convenient, but it bakes AWS into my root of trust. For some regulations, that’s fine. For others, they want the hardware vendor (AMD/Intel) in that role, not the cloud provider.

Plus, debugging a failing enclave in Nitro is a pain—console access is extremely limited. With our local SEV-SNP setup, we have a managed BMC and can at least get host-level logs if the attestation fails.

I’d love to hear if anyone else has run into this in audits. Are we overthinking it, or is there a real gap here for regulated workloads that demand hardware-level transparency?

— hex