A CPU can now keep a cloud provider’s own hypervisor from reading the memory of a virtual machine running on top of it. That single capability, built into silicon rather than bolted on through software, is what confidential computing promises, and by September 2026 all three major public clouds ship a production version of it. The catch is that Intel, AMD, and Amazon each solved the problem differently, and the differences show up in pricing, in which instance types you can pick, and in how much re-architecting a workload needs before it qualifies.
This comparison lines up the three technologies doing most of the real-world work in 2026: Intel Trust Domain Extensions (TDX) on Xeon 6, AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) across EPYC generations, and AWS Nitro Enclaves, the processor-agnostic isolation model built into the Nitro System. We pulled specs and pricing directly from Intel, AMD, AWS, Microsoft, and Google documentation current as of late September 2026, then mapped out where each option fits, what it costs per hour, and what it still won’t protect against.
Demand for confidential computing has shifted from a niche fintech and defense concern into a mainstream cloud-architecture decision. Enterprises moving proprietary AI models, patient records, or transaction data into shared cloud infrastructure increasingly face a contract clause or a regulator asking not just whether the data is encrypted, but whether it stays encrypted while a program is actively working with it. That question didn’t have a good technical answer a decade ago. By late 2026 it has three, and picking the wrong one for a given workload means paying for capacity you don’t need, hitting an instance-type wall mid-migration, or discovering too late that a feature you assumed would work, like hibernating an instance, silently stopped being available the moment you turned on hardware encryption.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Confidential Computing Actually Protects
Encryption at rest protects a database file sitting on disk. Encryption in transit protects data moving across a network. Neither protects data while a program is actively using it in RAM, which is the gap confidential computing closes. The moment a virtual machine boots and starts processing data, that data normally sits in plaintext in system memory, visible in principle to a hypervisor administrator, a malicious co-tenant that breaks isolation, or anyone with physical access to the server. Confidential computing encrypts that working memory with keys the hypervisor itself cannot access, and it adds a way to prove, through cryptographic attestation, that the workload is really running inside that protected environment before any secret gets released to it.
The technical name for the protected zone is a Trusted Execution Environment, or TEE. Intel TDX creates what it calls a Trust Domain. AMD SEV-SNP creates an encrypted guest VM with integrity protection against a malicious hypervisor. AWS Nitro Enclaves takes a different route entirely: rather than encrypting an entire VM’s memory, it spins up a separate, stripped-down virtual machine with no persistent storage, no network access, and no interactive shell, communicating with its parent instance only through a local, isolated channel. All three aim at the same outcome, a trust boundary that excludes the cloud operator, but they draw that boundary in different places, and that has real consequences for how you migrate a workload into one.
The threat model here is broader than a hacker breaking in from outside. It also covers a rogue cloud-provider employee with root access to the physical host, a government subpoena compelling a provider to hand over server memory rather than just stored files, and a misconfigured neighbor VM on the same physical hardware attempting to read across the isolation boundary. None of that is new territory for encryption generally; our guide to encrypting files covers the at-rest side of that same threat model. What’s new is extending the same guarantee to data the moment it becomes usable in memory, which historically has been the one place encryption couldn’t reach without help from the processor itself.
Intel TDX: Trust Domains Inside the Xeon 6
Intel’s confidential computing bet is built around Trust Domain Extensions, a hardware feature available on Xeon 6 processors. According to Intel’s TDX documentation, Xeon 6 supports up to 2,048 TDX encryption keys per processor, a figure Intel highlights specifically because it determines how many separate Trust Domains, and therefore how many isolated confidential VMs, can run on a single physical server at once. Each Trust Domain gets its own memory encryption key, generated and managed entirely inside the CPU, so a compromised or curious hypervisor sees only ciphertext even with full administrative access to the host.
Attestation is the other half of the TDX design. Before a workload releases a secret, such as a database encryption key or an API credential, into a Trust Domain, the party holding that secret can request a cryptographic report proving the Trust Domain is running the expected code on genuine Intel hardware with TDX active. That report gets checked against Intel’s own attestation infrastructure. This matters most for multi-party scenarios, where a bank or hospital wants proof a cloud-hosted workload hasn’t been tampered with before it hands over regulated data. Google Cloud has built its Confidential VM line on Intel TDX for its C3 machine series, which we cover in the pricing section below, while Microsoft Azure runs Intel TDX-based confidential VM families alongside its AMD-based ones.
AMD SEV-SNP: Encrypted Nested Paging Across EPYC Generations
AMD reached the market first with hardware memory encryption for VMs, and Secure Encrypted Virtualization-Secure Nested Paging is now the more widely deployed option simply because it has been shipping longer. SEV-SNP adds integrity protection on top of AMD’s earlier SEV and SEV-ES memory encryption, closing a known gap where a malicious hypervisor could remap or replay encrypted memory pages even without reading their contents. AWS documentation confirms SEV-SNP support on EC2 M6a, C6a, and R6a instance families, all of which run on AMD EPYC silicon. The R6a instance family specifically runs on third-generation EPYC, code-named Milan, and AWS notes it also includes AMD Transparent Secure Memory Encryption (TSME), which encrypts data in physical memory even outside the SEV-SNP guest boundary.
Microsoft has moved SEV-SNP further along the generation curve. Azure’s DCasv6 and DCadsv6 confidential VM families run on fourth-generation AMD EPYC 9004 processors, code-named Genoa, with a boosted clock of up to 3.7 GHz, according to Azure’s virtual machine series pricing page. Those VMs scale up to 96 vCPUs and 384 GiB of RAM, with the DCadsv6 variant adding up to 3,600 GiB of local temporary disk. That’s a meaningfully larger confidential VM than AWS currently offers on its SEV-SNP-enabled instance types, which matters for memory-hungry workloads like in-memory databases or large ML inference jobs that need to stay inside the encrypted boundary.
One operational wrinkle: on AWS, enabling SEV-SNP on shared-tenancy EC2 instances comes with a direct cost, and it also switches off two features you might otherwise expect, which we detail in the specs table next.
AWS Nitro Enclaves: Isolation Without a New Chip
AWS Nitro Enclaves takes a deliberately different architecture. Rather than depending on a specific CPU vendor’s memory-encryption feature, Nitro Enclaves is, in AWS’s own words from its Nitro Enclaves documentation, processor-agnostic and supported on most Intel, AMD, and AWS Graviton EC2 instance types built on the Nitro System. An enclave is carved out of an existing EC2 instance as an isolated, hardened virtual machine with no persistent storage, no network interface, and no interactive access; it communicates with its parent instance exclusively through a local vsock channel. That isolation model makes Nitro Enclaves a fit for narrow, high-value operations, generating a signing key, running a payment authorization check, or performing a specific piece of sensitive computation, rather than confidential computing for an entire application stack.
Nitro Enclaves ships with a built-in cryptographic attestation document that a verifier can check to confirm which exact code is running inside the enclave before releasing any secret to it, similar in spirit to TDX or SEV-SNP attestation but scoped to the smaller enclave boundary. AWS’s pricing documentation states there is no separate charge for the enclave itself; you pay the normal EC2 instance rate plus whatever other AWS services the workload touches. That is a meaningfully different cost model from a full confidential VM, and it’s one reason Nitro Enclaves shows up heavily in AWS reference architectures for key management services and blockchain validator nodes rather than general-purpose confidential computing.
How Attestation Actually Works
Attestation is the part of confidential computing that turns “trust me” into “verify this.” Without it, a Trust Domain or encrypted guest VM is just an encrypted box, and nothing stops an attacker from swapping in different code before the box boots. Here’s the sequence all three approaches follow in some form, even though the exact cryptographic details differ between Intel, AMD, and AWS.
- Measurement at launch. As the Trust Domain, encrypted VM, or enclave boots, the hardware records cryptographic measurements of the firmware, bootloader, and initial code image before anything else can run.
- Report generation. The hardware, or in Nitro Enclaves’ case the Nitro Hypervisor, signs those measurements into an attestation report or document using a key rooted in the physical chip.
- Report delivery to a verifier. The workload sends that signed report to whichever service holds the secret it needs, typically a key management service or a partner organization’s own verification endpoint.
- Verification against an expected baseline. The verifier checks the report’s signature against Intel’s, AMD’s, or AWS’s attestation infrastructure, then compares the measurements against the specific code version it expects to see running.
- Conditional secret release. Only if verification succeeds does the key, credential, or dataset actually get released into the Trust Domain, encrypted VM, or enclave.
The practical failure mode teams run into is treating step four as optional or building it loosely, for example accepting any signed report without checking the measurement matches an approved code version. That defeats the entire model, since an attacker who can get their own code running inside a technically genuine TEE would still pass a weak verification check. A properly designed pipeline fails closed: no verification, no secret, no exceptions for staging shortcuts that quietly make it into production.
Compliance Standards Are Starting to Ask for This by Name
Regulatory frameworks have historically talked about encryption in two buckets: data at rest and data in transit. Data in use sat in a gray zone, addressed indirectly through access controls and audit logging rather than a technical guarantee. That’s changing. Financial services examiners increasingly ask how a bank protects cardholder data during active processing, not just in the database, which pushes PCI DSS-scoped workloads toward confidential VMs for the processing tier. Healthcare organizations bound by HIPAA face similar questions from business-associate agreements when patient data moves into shared cloud infrastructure for analytics or AI model training. Government agencies working under FedRAMP or equivalent sovereign-cloud frameworks increasingly specify hardware-based memory encryption as a technical control rather than accepting a contractual assurance alone.
None of this means confidential computing is legally mandated yet in most jurisdictions. It means auditors are starting to ask the question, and once an auditor asks, security and compliance teams need an answer that holds up, which is a different bar than an answer that sounds reasonable. Organizations building a broader security program around this shift should treat confidential computing as one control among several; our cybersecurity threats coverage tracks the wider landscape of risks and controls this fits into.
Confidential Computing Specs Compared
The table below lines up the technical characteristics that actually change how you’d architect around each option, pulled from vendor documentation current in September 2026.
| Attribute | Intel TDX | AMD SEV-SNP | AWS Nitro Enclaves |
|---|---|---|---|
| Isolation unit | Full Trust Domain VM | Full encrypted guest VM | Carved-out sub-VM enclave |
| Underlying hardware | Intel Xeon 6 | AMD EPYC (Milan on AWS R6a, Genoa on Azure DCasv6) | Any Nitro-based Intel, AMD, or Graviton instance |
| Max encryption keys / domains | Up to 2,048 TDX keys per Xeon 6 processor | Per-VM guest key, count varies by host | Not applicable (per-enclave, not key-count limited) |
| Largest confidential instance | Varies by cloud (Google C3 series) | Up to 96 vCPUs / 384 GiB (Azure DCasv6) | Bound by parent instance’s spare vCPU/RAM allocation |
| Network access from TEE | Yes, standard VM networking | Yes, standard VM networking | No, vsock-only channel to parent instance |
| Persistent storage in TEE | Yes | Yes | No, ephemeral only |
| Attestation model | Intel-verified remote attestation report | AMD SEV-SNP attestation report | AWS Nitro attestation document |
| Cloud availability (2026) | Google Cloud C3 series, Azure DCesv6/ECesv6 family | AWS M6a/C6a/R6a, Azure DCasv6/DCadsv6/ECasv6/ECadsv6 | AWS only |
| Extra hourly charge | Included in confidential VM instance price | +10% of On-Demand rate on AWS shared tenancy | None beyond standard EC2 pricing |
| Compatible with hibernation | Cloud-dependent | No, on AWS SEV-SNP disables hibernation | Not applicable |
| Can combine with Nitro Enclaves on same instance | Not applicable | No, AWS disables Nitro Enclaves when SEV-SNP is on | Not applicable |
| Best-fit workload shape | Full confidential VM for regulated workloads | Full confidential VM, broadest cloud availability | Small, high-value secret operations (signing, key release) |
The most operationally important row is the ninth one. AWS explicitly states that enabling AMD SEV-SNP on a shared-tenancy EC2 instance disables both hibernation and Nitro Enclaves for that instance, and that the SEV-SNP surcharge does not apply on AWS Dedicated Hosts. That’s a real architectural decision, not a footnote: a team that wants both a full confidential VM and the ability to spin up narrow enclaves for key operations cannot get both on the same AWS instance today. They would need to either pick one model for the whole instance or split the workload across two instances.
What Confidential Computing Actually Costs
Pricing confidential computing isn’t a single number, because two of the three approaches charge a percentage premium on top of standard compute, one charges nothing extra, and the fourth vendor prices its confidential offering as a distinct machine series with its own hourly rate. Here’s what each vendor publishes as of September 2026.
| Provider / Product | Pricing model | Published rate |
|---|---|---|
| AWS EC2 with AMD SEV-SNP | Surcharge on top of instance On-Demand rate | +10% of the selected instance type’s hourly rate |
| AWS EC2 with SEV-SNP on Dedicated Hosts | Standard Dedicated Host billing | No additional SEV-SNP charge |
| AWS Nitro Enclaves | Standard EC2 instance pricing | No separate enclave charge |
| Google Cloud Confidential VM (Intel TDX, C3 series) | Per-vCPU and per-GiB, on-demand | $0.0033982/vCPU-hour, $0.0004555/GiB-hour |
| Google Cloud Confidential VM (Intel TDX, C3 series, Spot) | Per-vCPU and per-GiB, Spot | $0.001155/vCPU-hour, $0.0001549/GiB-hour |
| Azure DCasv6 / DCadsv6 (AMD SEV-SNP) | Dedicated confidential VM series pricing | Priced per size tier, up to 96 vCPUs / 384 GiB per VM |
Two things stand out. First, AWS is the only provider charging an explicit, published percentage surcharge for confidential computing on shared infrastructure, and that surcharge scales with the size of the instance, so a large SEV-SNP-enabled R6a instance costs proportionally more in absolute dollars than a small one, even though the percentage stays fixed at 10%. Second, Google’s per-vCPU and per-GiB pricing for Intel TDX confidential VMs on C3 lets you calculate an exact monthly cost with no guesswork, something neither AWS nor Azure’s published material makes as straightforward, since both require checking a size-specific rate card rather than a flat multiplier. Teams evaluating a move should also weigh this against key-management costs; our HashiCorp Vault vs AWS Secrets Manager vs Azure Key Vault comparison covers the secrets-management layer that typically sits alongside a confidential computing deployment.
Benchmarks: What the Performance Numbers Actually Show
Here’s the honest answer buyers deserve: as of September 2026, no vendor and no independent lab has published a single, universally applicable overhead percentage for confidential computing versus a standard VM, and any article claiming otherwise is guessing. What the available technical material does establish is that overhead is workload-dependent, driven mainly by memory-access patterns, page-table walk frequency under encrypted nested paging, and how often a workload triggers attestation or key-release operations. A September 2026 VMware Cloud Foundation walkthrough on deploying Intel TDX describes sizing enclave memory to the actual workload footprint plus a 10 to 15% buffer, which is a capacity-planning guideline rather than a performance benchmark, but it’s the kind of real operational guidance you won’t find repeated as a marketing statistic.
What we can benchmark directly, because the vendors publish it themselves, is capacity and cost rather than raw compute overhead. Intel’s own spec sheet puts a hard ceiling of 2,048 TDX keys per Xeon 6 processor. Azure’s own pricing page puts a hard ceiling of 96 vCPUs and 384 GiB per DCasv6 confidential VM. AWS’s own documentation puts a hard, published cost benchmark on SEV-SNP at exactly 10% above standard pricing. Those three figures, from three separate vendor sources, are the most concrete apples-to-apples numbers available right now, and they matter more for planning than an unverified overhead percentage would anyway: they tell you how many isolated workloads fit on one processor, how large a single confidential VM can get before you need to shard, and exactly what the security premium costs in dollars.
Teams that need a firmer performance number for their specific workload should run their own before-and-after benchmark on the target instance family rather than trust a generic industry figure, since page-table-heavy workloads (large in-memory databases, JIT-compiled runtimes) behave very differently under encrypted nested paging than I/O-bound or mostly-idle services do.
Five Real-World Use Cases for Confidential Computing
Multi-party data clean rooms. Advertisers, healthcare networks, and financial consortiums increasingly need to run joint analysis across datasets owned by separate organizations without any party seeing the other’s raw data. A confidential VM lets each party encrypt its contribution, hand it to a neutral compute environment attested to run only the agreed-upon analysis code, and receive only the aggregate result.
Cryptographic key custody and signing. AWS Nitro Enclaves shows up repeatedly in architectures for blockchain validator keys, payment-signing services, and certificate authorities, precisely because the enclave’s lack of network access and persistent storage minimizes the attack surface around a key that, once exposed, cannot be revoked cheaply.
Confidential AI inference and training. As enterprises move proprietary models and sensitive training data into public cloud GPU fleets, confidential VMs built on Intel TDX or AMD SEV-SNP give a way to run that pipeline without exposing model weights or training data to the cloud operator’s own infrastructure staff, an increasingly common requirement in AI vendor contracts that touch regulated data.
Regulated healthcare and financial workloads. Organizations bound by HIPAA, PCI DSS, or regional banking regulation frequently need to prove, not just assert, that patient records or transaction data were processed inside a verified trust boundary. Remote attestation gives compliance and audit teams a cryptographic artifact to point to, rather than a contractual promise from the cloud provider.
Sovereign and government cloud deployments. Government agencies moving workloads to commercial cloud infrastructure, particularly across borders, use confidential computing as a technical control to satisfy data-sovereignty requirements that no longer treat a cloud provider’s promise not to look as sufficient assurance on its own. A defense contractor processing classified or export-controlled data on a commercial hyperscaler, for instance, can point to a signed attestation report as evidence that only approved code touched that data, which is a materially stronger position in an audit than a data-processing agreement alone.
These five categories share a common thread: they all involve a moment where trusting the infrastructure operator isn’t good enough, either because a third party needs independent proof, a regulator requires it, or the value of what’s being protected is high enough that even a low-probability insider risk becomes unacceptable. Workloads without that specific pressure rarely justify the added cost and complexity today.
Migration Guide: Moving a Workload Into Confidential Computing
Moving an existing workload into a confidential VM or enclave is not a flag you flip in production without groundwork. Here’s the sequence that avoids the most common failure points.
- Classify the workload’s actual secret. Identify precisely what data or key needs protection while in use, not the whole application. This determines whether you need a full confidential VM or a narrow enclave.
- Pick the TEE that matches your cloud and workload shape. A workload needing full networking and persistent storage inside the trust boundary rules out Nitro Enclaves; a workload that’s just a signing operation is often overkill for a full confidential VM.
- Check instance-type and family compatibility first. Confirm your target cloud offers a confidential variant of the instance family your workload actually needs, since not every size or family in a provider’s catalog supports TDX or SEV-SNP.
- Design the attestation and key-release flow before writing code. Decide which service verifies the attestation report and what happens if verification fails; this logic sits outside the application itself.
- Test with a non-production replica first. Stand up the workload on the confidential instance type in a staging environment and run your own load test, since public overhead figures don’t exist for most workload shapes.
- Update your incident-response runbook. Confidential VMs change what forensic tooling can see inside memory during an investigation, so document what’s now inaccessible to your own ops team as well as to the cloud provider.
- Roll out with a rollback path. Keep the ability to redeploy on a standard, non-confidential instance type during initial rollout in case an unexpected compatibility or performance issue surfaces.
- Re-audit compliance documentation. Update data-processing agreements and audit evidence to reference the attestation mechanism now in place, since auditors increasingly ask for it explicitly in regulated industries.
A practical example of the AWS side of step three: enabling SEV-SNP on a supported instance at launch time uses a CPU options flag rather than a separate service, illustrated here for a standard EC2 launch via the AWS CLI.
aws ec2 run-instances \
--image-id ami-0123456789abcdef0 \
--instance-type r6a.xlarge \
--cpu-options "AmdSevSnp=enabled" \
--key-name my-key-pair \
--security-group-ids sg-0123456789abcdef0Note that this flag is only valid on the M6a, C6a, and R6a families, and AWS will reject the launch request on any instance type that doesn’t support SEV-SNP.
Pros and Cons of Each Platform
Intel TDX
Pros: high per-processor Trust Domain density at up to 2,048 keys, mature attestation infrastructure backed directly by Intel, growing multi-cloud availability across Google Cloud and Azure. Cons: availability is currently narrower than AMD SEV-SNP across AWS specifically, and migration requires Xeon 6-based instance families that not every cloud region has rolled out yet.
AMD SEV-SNP
Pros: the broadest cloud coverage of the three, available on AWS, Azure, and other providers, with a clear, published cost model on AWS. Azure’s Genoa-based DCasv6 family currently offers the largest published confidential VM size among the options compared here. Cons: on AWS, turning it on disables hibernation and Nitro Enclaves for that instance, and the 10% surcharge scales with instance size, which can add up quickly on large memory-optimized instances.
AWS Nitro Enclaves
Pros: no extra charge beyond the parent instance’s normal rate, processor-agnostic so it works across Intel, AMD, and Graviton fleets, and its minimal attack surface (no network, no persistent storage) suits high-value secret operations well. Cons: locked to AWS only, no persistent storage or direct network access inside the enclave rules out many general-purpose workloads, and it cannot run alongside SEV-SNP on the same instance.
Where the Industry Is Heading
The Confidential Computing Consortium, a Linux Foundation project bringing together chipmakers, cloud providers, and open-source maintainers, continues to serve as the neutral venue where Intel, AMD, AWS, Microsoft, Google, and others coordinate on shared attestation standards rather than shipping three incompatible verification schemes. That standardization work matters because a healthcare network running a clean room across AWS and Azure, for example, needs a common way to verify attestation reports regardless of which chip sits underneath. By 2026, all three major clouds ship a production confidential computing option, a shift from just a few years earlier when the technology was largely confined to early-adopter fintech and government pilots, as reflected in Azure’s expansion of its confidential VM lineup to a sixth generation of DC and EC families and Google’s addition of Spot pricing for Intel TDX-based Confidential VMs, both signals that providers now expect mainstream, cost-sensitive workloads rather than only compliance-driven ones.
Cryptographic groundwork is moving in parallel, too. Post-quantum key exchange is increasingly paired with confidential computing in security-conscious deployments, since a quantum-resistant algorithm protecting data in transit means little if that same data sits unprotected in memory once it arrives. Our OpenSSL vs BoringSSL vs wolfSSL comparison covers how the major TLS libraries are rolling out post-quantum algorithms, a complementary layer to everything covered here.
What Confidential Computing Doesn’t Protect Against
None of these three technologies is a silver bullet, and treating any of them as one is a mistake worth flagging directly. Side-channel attacks, techniques that infer secrets from timing, power consumption, or cache-access patterns rather than reading memory directly, have historically affected earlier generations of hardware TEEs, including SGX and early SEV implementations, and remain an active area of academic research against newer TEE designs. No verified, publicly disclosed CVE against Intel TDX, AMD SEV-SNP, or AWS Nitro Enclaves specifically was identified as of late September 2026, but the absence of a disclosed flaw today is not the same as a guarantee of future safety, and organizations relying on these technologies for regulated data should track vendor security advisories as a standing practice rather than a one-time check.
It’s also worth being clear about scope: confidential computing protects data while a specific, attested workload is processing it. It does not protect against a vulnerability in the application code running inside the TEE, it does not replace network segmentation or identity and access management, and it does not make a poorly secured API any safer once data leaves the trust boundary. Teams building a broader cloud security posture around this layer should also look at CSPM tooling; our Wiz vs Orca vs Prisma Cloud comparison covers the posture-management layer that typically wraps around confidential and non-confidential workloads alike.
Which Confidential Computing Option Should You Choose?
Running signing or key-custody operations on AWS: Nitro Enclaves is the direct fit, given zero extra cost and a minimal attack surface built for exactly this narrow job.
Running a full confidential VM on AWS for a broader application: AMD SEV-SNP on M6a, C6a, or R6a is currently the only full-VM confidential option AWS offers, accepting the 10% surcharge and the hibernation trade-off.
Building on Azure with a memory-hungry workload: DCasv6 or DCadsv6 offers the largest published confidential VM footprint compared here, up to 96 vCPUs and 384 GiB, making it a fit for in-memory databases or large inference jobs.
Cost-sensitive workloads on Google Cloud: the per-vCPU, per-GiB pricing on Intel TDX-based C3 Confidential VM instances, with Spot pricing available, gives the clearest and most granular cost model of the three clouds.
Multi-cloud compliance requirements: favor whichever TEE has attestation infrastructure your compliance or audit tooling already integrates with, since switching attestation verification logic later is more disruptive than switching cloud regions.
Early-stage projects without a hard compliance driver: confidential computing adds real operational and cost overhead for uncertain benefit if there’s no specific regulatory or contractual requirement driving it yet; standard VM isolation plus solid IAM and network controls remains the more practical starting point. For teams evaluating broader cloud provider trade-offs beyond just this layer, our AWS vs Google Cloud comparison covers market share and performance differences that often matter more day to day.
The Verdict
There is no single winner here because the three technologies solve overlapping but distinct problems. AWS Nitro Enclaves wins on cost, adding nothing to the bill and offering the smallest attack surface, but it only fits narrow, self-contained secret operations rather than full application stacks. AMD SEV-SNP wins on availability, reaching the widest set of clouds and instance families, and Azure’s Genoa-based DCasv6 family currently offers the largest confidential VM size in this comparison at up to 96 vCPUs and 384 GiB. Intel TDX wins on raw Trust Domain density per processor, at up to 2,048 keys on Xeon 6, which matters most to cloud operators packing many isolated tenants onto shared hardware rather than to a single enterprise customer renting one confidential VM.
For most teams evaluating this in late 2026, the practical decision tree is simpler than the underlying silicon: if the job is a narrow secret operation on AWS, use Nitro Enclaves and pay nothing extra. If it’s a full workload that needs broad cloud availability, use SEV-SNP. If it’s a memory-heavy workload on Azure specifically, DCasv6 or DCadsv6 currently gives the most room to grow. And if a hard compliance mandate isn’t driving the decision yet, it’s worth confirming that mandate exists before taking on the architectural complexity and, on AWS, the direct 10% cost of turning any of this on.
Frequently Asked Questions
What is confidential computing in simple terms?
Confidential computing encrypts data while a program is actively using it in memory, not just while it sits on disk or travels across a network. It relies on hardware-based Trusted Execution Environments built into modern CPUs so that even a cloud provider’s own administrators cannot read the data being processed.
Is confidential computing the same as encryption at rest?
No. Encryption at rest protects stored data, and encryption in transit protects data moving across a network. Confidential computing closes the remaining gap by protecting data during active processing in system memory.
Which cloud offers the cheapest confidential computing?
AWS Nitro Enclaves adds no separate charge beyond standard EC2 pricing, making it the cheapest option for workloads narrow enough to fit its enclave model. For full confidential VMs, Google Cloud’s per-vCPU, per-GiB pricing on Intel TDX-based C3 instances offers the clearest, most granular cost structure, including Spot pricing.
Does AMD SEV-SNP work on all AWS instance types?
No. As of September 2026, AWS supports SEV-SNP only on the M6a, C6a, and R6a instance families, all built on AMD EPYC processors. Enabling it adds a 10% surcharge on shared tenancy and disables hibernation and Nitro Enclaves for that instance.
Can I use Intel TDX and AWS Nitro Enclaves together?
Not directly, since Intel TDX is currently offered by Google Cloud and Azure rather than AWS, and Nitro Enclaves is an AWS-specific technology. A multi-cloud architecture could use TDX-based confidential VMs on one cloud and Nitro Enclaves for a specific AWS-hosted component, but they don’t combine within a single AWS instance.
Does confidential computing protect against all attacks?
No. It protects data in use from a hypervisor or physical-access attacker but does not replace application security, network segmentation, or identity and access management. Side-channel attacks against hardware TEEs remain an active area of security research industry-wide.
How much performance overhead does confidential computing add?
No vendor or independent lab has published a single universal overhead figure as of September 2026, since it varies heavily by workload, particularly memory-access patterns and how often attestation or key-release operations occur. Teams should benchmark their own workload on the target confidential instance type rather than rely on a generic percentage.
Do I need confidential computing for a typical business application?
Most applications don’t need it yet. It’s most justified when a specific regulatory requirement, multi-party data-sharing arrangement, or high-value secret (like a signing key) demands cryptographic proof that data was processed inside a verified trust boundary, rather than a contractual promise from the cloud provider.
Related Coverage
- DeleteMe vs Incogni vs Optery: 556-Broker Gap [2026]
- Yoti vs k-ID vs Persona: 0.73-Year Accuracy Gap [2026]
- Salt vs Wallarm vs Akamai API Security: 48x G2 Gap [2026]
- Who Is ShinyHunters? 7.1M Records, 3 Arrests [2026]
- Dutch Hacker Arrested in ShinyHunters Probe Tied to FBI Breach [2026]
