By 2029, Gartner predicts that more than 75 percent of operations processed in untrusted infrastructure will be secured in-use by confidential computing, up from a small fraction today. That forecast is not a marketing claim from a TEE vendor. It is a recognition that encryption at rest and in transit, the two protections most architects have spent a decade perfecting, leave a gap exactly where the most sensitive processing happens: in memory, while the CPU is working on it. Every cloud provider now sells a version of the fix, and the three implementations are not interchangeable, despite marketing pages that make them sound like commodity features.
The traditional response to data-in-use risk has been organisational rather than technical: restrict who can access production systems, log everything, and hope the audit trail deters misuse. This works until it doesn’t. A privileged insider with root access to a hypervisor can still read plaintext memory regardless of how tightly IAM policies are scoped, and a growing list of regulated use cases (multi-party data collaboration, confidential AI inference, cross-border financial data sharing) simply cannot proceed under an insider-trust model, no matter how well governed. Financial institutions have been particularly exposed here: only a small fraction of banking workloads have historically moved to the cloud, and data-in-use risk is consistently cited as a reason why.
Confidential computing closes that gap by encrypting memory with keys the hypervisor and cloud operator never see, and by giving you cryptographic proof of exactly what code is running before you release a secret to it. AWS, Azure, and GCP have converged on the same broad goal but diverged sharply on architecture: AWS builds confidentiality into the Nitro System by default and layers isolated enclaves on top, Azure and GCP both offer discrete “Confidential VM” products built on AMD SEV-SNP and Intel TDX. None of the three is a drop-in replacement for another, and getting the comparison wrong has real consequences: this piece checks every comparative claim against current release notes and documentation, in both directions, because “Vendor B doesn’t support X” claims in this space go stale within a single product cycle.
Current State: From Research Curiosity to Compliance Requirement
Confidential computing spent most of the 2010s as an academic and niche security topic, largely confined to Intel SGX research and blockchain key-management use cases. The shift to mainstream enterprise relevance happened in three stages. AMD shipped SEV-SNP and Intel shipped TDX as CPU-level features rather than application-level enclaves, which meant existing virtual machines could be “lifted and shifted” into a confidential posture without rewriting a single line of application code. Cloud providers then productised those CPU features as VM types customers could launch directly from the console, removing the specialist hardware knowledge that SGX development required. Most recently, generative AI has become the dominant adoption driver: training and inference workloads increasingly touch proprietary model weights and regulated training data simultaneously, adding a security dimension to the platform choices covered in our AI infrastructure comparison, and confidential GPU support (NVIDIA H100 and, more recently, RTX PRO 6000 Blackwell) has made TEE protection practical for AI workloads rather than just batch cryptographic operations.
The most persistent misconception among architects who haven’t touched this space recently is that confidential computing still means Intel SGX: small, hand-partitioned application enclaves requiring significant refactoring. That was true five years ago. Today the dominant pattern is VM-level confidentiality through AMD SEV-SNP or Intel TDX, which protects an entire unmodified guest OS and application stack. The second common misconception is treating the three major clouds as offering equivalent products under different names. They don’t. AWS has no VM-branded confidential computing product at all in the way Azure and GCP do; it defaults to always-on memory encryption across the Nitro System and adds isolated Nitro Enclaves for the highest-sensitivity workloads, a materially different architecture from a lift-and-shift confidential VM. Getting this distinction right shapes almost every decision later in this piece, from which workloads fit which platform to how you scope a proof of concept.
Confidential Computing Architecture: TEEs, Attestation, and Memory Encryption
A trusted execution environment protects data in use by combining hardware-enforced memory encryption with a way to prove, cryptographically, that the code running inside it is exactly what you expect. Two implementation families dominate production cloud deployments today. Process-based TEEs, exemplified by Intel SGX, isolate a small application enclave with the CPU as the root of trust, excluding the operating system from the trust boundary entirely; this gives the smallest possible attack surface but requires re-architecting applications into trusted and untrusted components. Confidential VMs, built on AMD SEV-SNP or Intel TDX, instead extend hardware-based memory encryption and integrity protection to an entire guest virtual machine, so unmodified operating systems and applications run inside the protected boundary with no code changes. The trade-off is a somewhat larger trusted computing base (it now includes the guest OS) in exchange for dramatically lower adoption friction, which is why SEV-SNP and TDX now dominate mainstream enterprise deployments over SGX.
Attestation is what turns hardware isolation into something you can build policy around. Each of the three major TEE technologies generates a signed report, an attestation document for AWS Nitro, an SEV-SNP attestation report chaining to an AMD root of trust, or a TDX quote chaining to Intel’s Provisioning Certification Service, that a relying party (commonly a key management service) verifies before releasing a secret. The architectural detail that matters for regulated workloads is where the root of trust sits. Intel TDX and AMD SEV-SNP both chain to a hardware key burned into the CPU at manufacture and independently verifiable against the chip vendor’s public infrastructure, so the cloud operator is cryptographically excluded from the attestation chain. AWS Nitro Enclaves instead chains to the AWS Nitro Attestation PKI, a certificate authority operated by AWS itself. AWS’s position, backed by an independent third-party affirmation of the Nitro System’s confidential computing capabilities, is that operational controls prevent AWS staff from accessing this infrastructure regardless of who issues the certificate. Whether a software-attested, operator-issued root of trust is acceptable depends on your specific regulatory posture and threat model, and it is worth resolving explicitly during due diligence rather than assuming equivalence with a hardware-rooted alternative. This is the kind of distinction that belongs in the same conversation as the zero-trust networking patterns most enterprise architectures already assume.
AWS: Nitro System and Nitro Enclaves
AWS takes the position that confidential computing should be the default rather than an opt-in product. Every EC2 instance built on AWS Graviton2 or later, AMD EPYC (Milan) or later, and Intel Xeon Scalable (Ice Lake) or later processors gets always-on memory encryption at no additional cost and with no code changes, enforced by the Nitro System’s dedicated hardware components (Nitro Cards, the Nitro Security Chip, and the Nitro Hypervisor) rather than by a guest-visible confidential VM mode. On top of that baseline, Nitro Enclaves let you carve an additional isolated compute environment out of an existing EC2 instance: a fully separate virtual machine with its own vCPUs and memory, no persistent storage, no interactive access, and no external networking. Communication with the parent instance happens exclusively over a local vsock channel, and even a root user on the parent cannot inspect or SSH into the enclave. Attestation documents generated by the Nitro Hypervisor integrate natively with AWS KMS, so you can scope a KMS key to decrypt only for an enclave whose measured code hash (a Platform Configuration Register value) matches an exact, approved build.
This architecture is deliberately narrow and it shows in the constraints: enclaves have no PCI device access, which rules out GPU acceleration entirely, and communication overhead through the vsock proxy limits throughput for network- or storage-heavy workloads. It is also, less widely appreciated, not the only route to VM-level confidentiality on AWS. Select EC2 instance families (m6a, c6a, and r6a) support AMD SEV-SNP directly, giving you a full-VM attestation report covering initial guest memory and vCPU state, comparable in shape to what Azure and GCP offer, currently available in US East (Ohio) and Europe (Ireland) and carrying a 10 percent hourly surcharge over the standard on-demand rate. This is a materially different capability from Nitro Enclaves and is frequently missed in comparison pieces that describe AWS as having “no confidential VM equivalent.”
Azure: Confidential VMs, Confidential Containers, and MAA
Azure ships the broadest published TEE portfolio of the three clouds, spanning AMD SEV-SNP, Intel TDX, and Intel SGX under a single Confidential Computing umbrella. The DCasv5 and ECasv5 series (general purpose and memory-optimised respectively) run on AMD SEV-SNP and have been generally available since 2021. The newer fourth-generation EPYC DCasv6 and ECasv6 series carry conflicting status in Microsoft’s own materials: several official Azure Confidential Computing blog posts describe a general-availability regional rollout beginning in September 2025, while Microsoft’s current Confidential Computing products overview page continues to list DCasv6 and ECasv6 as gated preview, so this should be verified against the live products page immediately before publishing rather than treated as settled. Intel TDX-based confidential VMs (DCesv6, DCedsv6, ECesv6, and ECedsv6) are generally available, with availability varying by region and SKU, built on Azure’s open-source OpenHCL paravisor and supporting local NVMe storage for the first time in Azure’s confidential VM lineup. Both technology families boot only after successful platform attestation and expose a dedicated virtual TPM for storing keys and measurements outside the reach of the running VM itself, with Microsoft Azure Attestation (MAA) validating the platform state before Key Vault releases customer-managed disk-encryption keys.
Beyond raw VMs, Azure extends confidentiality down to the container and application layer through Confidential Containers on Azure Container Instances and confidential node pools on AKS, letting teams run containerised workloads inside SEV-SNP or Intel SGX enclaves without redesigning application deployment pipelines, a pattern worth evaluating alongside the broader AKS production architecture decisions most Azure-based platform teams have already made. Azure also supports confidential GPU workloads through NVIDIA H100-equipped confidential VMs, and application-specific services such as Always Encrypted with secure enclaves for SQL Server and Azure Confidential Ledger extend the same TEE foundation to specific managed-service patterns. The practical limitation architects hit most often is regional and family availability: DCasv5 (AMD) has meaningfully broader regional coverage than the newer DCesv6 (Intel TDX) family, and confidential VMs cannot be resized to or from a non-confidential SKU, which has real implications for capacity planning and disaster recovery design.
GCP: Confidential VM, Confidential GKE Nodes, and Confidential Space
Google Cloud’s confidential portfolio covers AMD SEV and SEV-SNP on the N2D, C2D, C3D, and C4D machine series, and Intel TDX on the C3 series, all generally available, with confidential GPU support now spanning NVIDIA H100 (A3 machine series, GA) and RTX PRO 6000 Blackwell (G4 machine series, preview). Two details distinguish GCP’s implementation from its competitors technically. First, GCP’s official documentation confirms live migration is supported specifically for AMD SEV (not SEV-SNP, and not Intel TDX) on the N2D and C3D machine series, a capability neither Azure’s current confidential VM lineup nor AWS’s SEV-SNP EC2 option supports for any of their configurations today. Second, Confidential GKE Nodes bring the same hardware-based memory encryption directly into Kubernetes node pools, generally available with Intel TDX on both GKE Standard and GKE Autopilot, provisionable through the standard CLI, API, console, or Terraform workflow.
The product that most clearly differentiates GCP for the multi-party collaboration use case is Confidential Space, a purpose-built, generally available offering layered on top of Confidential VM specifically for scenarios where mutually distrusting parties (data collaborators, a workload author, and a workload operator) need to jointly process sensitive data without any party, including Google, gaining access to it. Confidential Space issues OpenID Connect attestation tokens through Google Cloud Attestation (with Intel Trust Authority available as an independent, operator-decoupled alternative verifier), and its trust model is explicitly designed so that the workload operator cannot inspect, modify, or influence the workload at runtime, a stronger guarantee than a standard confidential VM alone provides. Financial services and healthcare federated-learning platforms have adopted this pattern specifically because it removes the workload operator from the trust boundary, not just the underlying cloud infrastructure.
Vendor Comparison: Where the Three Platforms Actually Differ
Every comparative claim in this section has been checked against official documentation and current release notes on both sides, following the traffic-light protocol this site applies to comparison posts (see the Verification Report at the end of this piece). The single most consequential difference is architectural rather than feature-based: AWS treats confidentiality as an always-on property of the Nitro System with Nitro Enclaves as an add-on isolation primitive, while Azure and GCP both sell confidentiality as an explicit VM class you opt into. If your workload needs a genuine lift-and-shift of an existing VM into a hardware-encrypted, fully attestable environment with no application changes, Azure and GCP’s confidential VM model is the more direct fit; AWS can match this through SEV-SNP-enabled EC2 instances, but the instance family and regional footprint is currently narrower than either competitor’s confidential VM lineup.
Attestation architecture is a second real difference, not a marketing one. Azure and GCP both build confidential VMs on Intel TDX and AMD SEV-SNP, chaining attestation to hardware roots of trust operated by the chip vendor rather than the cloud provider. AWS Nitro Enclaves chains attestation to a PKI that AWS itself operates; AWS’s separate SEV-SNP EC2 option should be treated differently, since its attestation report chains to AMD’s own root of trust in the same way Azure and GCP’s SEV-SNP paths do. For workloads where the compliance requirement is specifically “prove the cloud operator cannot access this data, verified independently of the operator,” that distinction, Nitro Enclaves specifically versus AWS’s SEV-SNP path, is worth resolving with your compliance team rather than treating “AWS confidential computing” as a single attestation model.
Live migration support diverges sharply, though the picture is shifting. GCP’s official documentation confirms live migration for confidential VMs is generally available specifically for AMD SEV (not SEV-SNP or Intel TDX) on N2D and C3D machine types. Azure’s public documentation describes resizing and migration constraints tied to the VMGS (Virtual Machine Guest State) disk for its current confidential VM lineup, but Microsoft announced Confidential Live Migration for Intel TDX confidential VMs at Build 2026, currently in private preview and rolling out gradually to the DCesv6, DCedsv6, ECesv6, and ECedsv6 families, so this is a capability to watch rather than a settled gap. AWS’s SEV-SNP-enabled EC2 instances explicitly disallow hibernation and require manual intervention to move to a new host during scheduled maintenance, with no live migration path announced. If continuous availability during host maintenance is a hard requirement today, GCP’s AMD SEV support is the only generally available answer among the three; Azure’s private-preview TDX capability is worth tracking for anyone locked into that platform.
Multi-party data collaboration is where genuine product-level differentiation exists, but the framing matters. GCP’s Confidential Space is the only discretely branded, purpose-built product among the three specifically engineered around a three-party trust model (data collaborators, workload author, workload operator) with the operator explicitly excluded from the trust boundary. AWS achieves comparable outcomes, demonstrated in production by Fireblocks’ and Coinbase’s MPC wallet architectures on Nitro Enclaves, but as a pattern built from primitives (Nitro Enclaves plus KMS attestation policies) rather than a named, discrete product. Azure supports the same use case through confidential computing plus confidential VMs, evidenced by data clean room vendors such as Habu and Decentriq building on the platform, again without a single named product wrapping the pattern. This is a genuine GCP product-packaging advantage for teams that want a managed multi-party framework rather than an architecture they assemble themselves; it is not evidence that AWS or Azure cannot support multi-party collaboration.
GPU-accelerated confidential AI shows a clean capability split rather than a close call. Nitro Enclaves has no path to GPU passthrough, a hard architectural constraint given enclaves’ lack of PCI device access, which rules AWS out for confidential GPU training or inference workloads specifically (standard EC2 GPU instances remain covered by Nitro System memory encryption, but not enclave-level isolation). Azure and GCP both support confidential GPU workloads in general availability today: Azure through NVIDIA H100-equipped confidential VMs, GCP through NVIDIA H100 (A3 series, GA) and RTX PRO 6000 Blackwell (G4 series, preview). Teams building confidential AI inference or training pipelines should treat this as a hard filter rather than a nuance.
| Dimension | AWS | Azure | GCP |
|---|---|---|---|
| Primary TEE model | Always-on Nitro System encryption + Nitro Enclaves; SEV-SNP on select EC2 families | Confidential VMs on AMD SEV-SNP and Intel TDX | Confidential VMs on AMD SEV/SEV-SNP and Intel TDX |
| Attestation root | AWS Nitro Attestation PKI (operator-issued); NitroTPM for full-instance attestation | Hardware root (AMD/Intel) via Microsoft Azure Attestation | Hardware root (AMD/Intel) via Google Cloud Attestation, plus Intel Trust Authority option |
| Confidential GPU | Not supported (no PCI passthrough in enclaves) | GA (NVIDIA H100) | GA (NVIDIA H100); preview (RTX PRO 6000 Blackwell) |
| Live migration | Not supported for SEV-SNP instances | Not supported for GA families; TDX live migration in private preview | GA for AMD SEV only on N2D and C3D (not SEV-SNP or TDX) |
| Kubernetes integration | No native confidential EKS node type | Confidential Containers on AKS (SEV-SNP, Intel SGX) | Confidential GKE Nodes (Intel TDX), Standard and Autopilot |
| Multi-party collaboration | Pattern via Nitro Enclaves + KMS (no named product) | Pattern via confidential VMs (no named product) | Confidential Space (named, GA product) |
| Pricing model | Nitro Enclaves free; SEV-SNP EC2 instances carry a published 10% hourly surcharge | Confidential VM premium over standard equivalent (varies by SKU and region; no single published percentage) | Itemised flat per-vCPU and per-GiB surcharge for AMD SEV, SEV-SNP, and Intel TDX; additional charges for GPU-attached and confidential Hyperdisk configurations |
| Vendor lock-in risk | Moderate (Nitro architecture is AWS-specific; SEV-SNP path is more portable) | Low to moderate (SEV-SNP/TDX portable in principle; MAA integration is Azure-specific) | Low to moderate (SEV-SNP/TDX portable in principle; Confidential Space trust model is GCP-specific) |
| Ecosystem and open source | Nitro Enclaves SDK, Anjuna, open-source attestation verifiers | Gramine, Open Enclave SDK, OpenHCL paravisor (open source) | Gramine, Confidential Computing Consortium projects, Duality federated learning integrations |
Real-World Case Studies
Company Name and Industry: Portal, Inc., Web3 and blockchain payments infrastructure
Scale Context: Embedded wallet infrastructure serving customers ranging from seed-stage startups to large fintech corporations, processing millions of daily transactions Challenge: Portal’s multi-party computation wallet architecture required generating large prime numbers for cryptographic key operations, a computationally intensive process that created latency bottlenecks at scale while still requiring the strict isolation guarantees the financial industry demands.
Solution Implemented: AWS Nitro Enclaves combined with Anjuna Seaglass to accelerate deployment without custom enclave development, running on Amazon EKS for automatic scaling.
Measurable Outcomes:
- Accelerated cryptographic key processing by 10 times
- Implemented the full Nitro Enclaves deployment in 2.5 weeks
- Reduced time to market by an estimated 90 percent, removing the need to hire specialist enclave engineers
Source: https://aws.amazon.com/solutions/case-studies/portal-anjuna-nitro-enclaves-case-study/
Company Name and Industry: Auros, Digital asset algorithmic trading and market making
Scale Context: Cryptocurrency and digital asset trade execution operations spanning Hong Kong and New York
Challenge: Auros needed to protect sensitive data during on-chain (blockchain-based) trades without introducing latency or additional cost that would erode trading returns, a constraint that rules out many conventional confidential computing approaches.
Solution Implemented: AWS Nitro Enclaves to isolate compute environments for sensitive trade-execution data within existing EC2-based trading infrastructure, with direct support from the AWS Nitro Enclaves engineering team during optimisation.
Measurable Outcomes:
- Reduced processing cost by approximately 80 percent following AWS-assisted performance optimisation
- Maintained trade execution latency requirements throughout the migration
- Significantly reduced attack surface area for sensitive data processing without compromising performance
Source: https://aws.amazon.com/solutions/case-studies/auros/
Company Name and Industry: BeeKeeperAI, Healthcare AI development
Scale Context: Zero Trust platform connecting healthcare AI algorithm developers with HIPAA-compliant data stewards across the US health system
Challenge: Generalisable clinical AI development requires validating models against datasets from multiple health systems, but contracting and Institutional Review Board approval to access a single dataset can take six to eighteen months, with the full multi-site process often exceeding two years, before accounting for the risk that de-identified data introduces variation the AI never encounters in clinical deployment.
Solution Implemented: Azure confidential computing with Intel SGX-based secure enclaves, letting encrypted AI algorithms compute against encrypted healthcare datasets inside the data steward’s HIPAA-compliant Azure environment without exposing either the data or the algorithm’s intellectual property to the other party. Measurable Outcomes:
- Reduced a typical two-year data access and contracting process to three to four months
- Enabled one data steward organisation to waive its Institutional Review Board process entirely for platform-based projects, removing a three-to-nine-month step
- Cut overall healthcare AI go-to-market timelines by at least twelve months, and by up to eighteen months in some cases
A note on sourcing: this section deliberately covers two AWS deployments and one Azure deployment rather than one per cloud. Extensive searching of Google Cloud’s official customer-story domains did not surface a GCP-specific confidential computing case study meeting this site’s verification bar of a live, official case-study page with specific quantified outcomes. GCP has named production users of Confidential Space and Confidential VM, including Duality Technologies, TransUnion, and Fireblocks, but the available official material for these deployments lives on Google-hosted marketing assets outside the approved case-study domain pattern and does not publish the kind of quantified metrics this format requires. Rather than pad the section with an unverified or purely qualitative example, this gap is flagged here rather than papered over.
Cost Analysis and Total Cost of Ownership
Pricing structures differ enough across the three clouds that a single blended TCO figure would be misleading, so treat each in its own terms. AWS Nitro Enclaves carry no additional charge beyond the underlying EC2 instance and any other AWS services consumed, making them the cheapest entry point of the three for enclave-based workloads; the trade-off is that you pay in engineering time, since enclave applications need explicit vsock-based communication and a split trusted and untrusted architecture. AWS’s SEV-SNP-enabled EC2 instances (m6a, c6a, r6a families) carry an explicit, published 10 percent hourly surcharge over the equivalent standard on-demand rate, unaffected by Reserved Instances or Savings Plans.
Azure confidential VM pricing varies by SKU, region, and disk-encryption configuration. Microsoft’s documentation directs customers to VM pricing pages, the Azure Pricing Calculator, and the Retail Prices API rather than publishing a single universal confidential-VM percentage premium, so any business case should compare the exact confidential and non-confidential SKUs in the target region rather than relying on a rule-of-thumb percentage. From March 2026, encrypted OS disks for confidential VMs also carry a separately itemised cost increase, which is easy to miss if you’re estimating from older documentation. Premium (HSM-backed) Key Vault is required for customer-managed disk encryption keys, adding further cost relative to a standard VM deployment.
GCP itemises its confidential computing surcharge explicitly rather than folding it into the base rate: current published pricing lists flat additional per-vCPU and per-gibibyte-hour charges on top of standard Compute Engine pricing for AMD SEV, AMD SEV-SNP, and Intel TDX confidential VM instances, with the AMD SEV-SNP rate running at roughly half the AMD SEV surcharge and the Intel TDX rate falling between the two, per the current pricing page. NVIDIA H100 confidential GPU workloads on the A3 series carry their own separately itemised additional cost on top of the accelerator-optimised base pricing, and confidential mode for Hyperdisk Balanced adds a further itemised charge. Confidential Space itself carries no additional fee beyond the Confidential VM and other resources it runs on, and G4 (RTX PRO 6000 Blackwell) confidential compute fees are currently waived during preview, though base G4 compute, GPU, and storage charges still apply.
Analyst estimates of the overall confidential computing market vary enormously depending on methodology and scope, with published 2026 figures ranging from roughly $17 billion to well over $40 billion depending on the research house and what counts as “confidential computing” hardware versus software revenue. Rather than lean on a single disputed market-size figure, the more defensible planning anchor is Gartner’s operational prediction that more than 75 percent of operations on untrusted infrastructure will be secured in-use by confidential computing by 2029: that is a statement about where regulated workloads are heading structurally, not a revenue forecast, and it is a more useful input to a three-to-five-year infrastructure roadmap than any single market-size number currently in circulation.
Decision Framework
Start with the workload’s trust boundary, not the cloud you already run on, in the same way the security pillar in AWS’s own Well-Architected guidance starts from data classification rather than service selection. If the requirement is “protect this workload from our own privileged administrators and from the cloud operator, with minimal application change,” Azure or GCP confidential VMs are the more direct architectural fit, since both extend hardware encryption to an entire unmodified guest OS with a single deployment-time flag. If the requirement is narrower, “isolate one specific high-sensitivity function such as key management or tokenisation from the rest of an otherwise standard application,” AWS Nitro Enclaves is purpose-built for exactly that pattern and costs nothing beyond the parent EC2 instance, at the price of the re-architecture work vsock communication demands.
Weigh the attestation root explicitly rather than assuming any TEE satisfies any compliance requirement. Where the specific control objective is independent, operator-excluded verification of platform integrity, Azure and GCP’s hardware-rooted TDX and SEV-SNP attestation chains are the stronger fit out of the box; AWS’s Nitro Enclaves model can reach comparable assurance but relies on trusting AWS’s own attestation PKI and its independently affirmed operational controls rather than a chip vendor’s separately verifiable root.
For multi-party data collaboration specifically, evaluate whether you want a managed framework or are prepared to build one from primitives. GCP’s Confidential Space is the only purpose-built, generally available product among the three explicitly designed around mutually distrusting parties with the workload operator excluded from the trust boundary; if that framework fits your use case, it will be materially faster to stand up than assembling the equivalent from Nitro Enclaves and KMS policies on AWS or from confidential VMs on Azure. For confidential AI and GPU-accelerated workloads, the decision narrows quickly: Azure and GCP both support confidential GPU compute in general availability today, and AWS currently does not, which for this specific workload class is not a trade-off to weigh but a hard filter.
Implementation Roadmap
Phase 1, Foundation (Months 1 to 3): Identify the specific data flows and workloads that actually require data-in-use protection, distinct from data-at-rest and in-transit controls you likely already have covered through patterns like managed identity for credential elimination. Resist the instinct to confidential-enable everything; the operational overhead (constrained debugging, resizing restrictions, and in Azure and AWS’s case, no live migration) is real and should be reserved for workloads where the regulatory or contractual requirement justifies it. Run a scoped proof of concept on one workload per candidate cloud, budgeting for the SEV-SNP or Nitro Enclaves engineering time rather than assuming a checkbox toggle. Expect a small platform engineering team (two to three engineers) and initial cloud spend limited to the proof-of-concept instances themselves.
Phase 2, Expansion (Months 4 to 9): Extend confidential computing from the pilot workload to the broader class it represents, standardising on Infrastructure as Code templates for confidential VM or Nitro Enclaves deployment so the pattern is repeatable rather than bespoke per team. Integrate attestation verification into CI/CD so a code change that alters the measured hash triggers a deliberate re-approval step rather than a silent KMS access failure in production. If your use case involves confidential AI or GPU workloads, this is the phase to commit to Azure or GCP rather than AWS, given the current GPU support gap. Establish the governance model for who can approve new attestation policies, since this becomes a security control surface in its own right.
Phase 3, Maturity (Months 10 to 18): Extend confidential computing into Kubernetes-based workloads through Confidential Containers on AKS or Confidential GKE Nodes if your platform strategy is container-first, building on whatever container orchestration architecture your organisation has already standardised on. Revisit the multi-party collaboration question at this stage if it wasn’t in scope for the initial pilot: by month ten, GCP’s Confidential Space, Azure’s confidential VM-based clean room patterns, or AWS’s Nitro Enclaves and KMS approach will each have accumulated enough production experience internally to make an informed build-versus-adopt decision rather than a first-principles one.
Future Trends and Innovation
Confidential AI is the clearest near-term growth vector, and the technology is moving from CPU-only protection to full-stack confidentiality spanning CPU, GPU, and the interconnect between them. NVIDIA’s confidential computing mode for H100 and newer GPUs, now generally available on both Azure and GCP, encrypts the PCIe channel between CPU and GPU specifically to prevent bus-level snooping of model weights and training data, a gap that CPU-only TEEs never addressed. Expect confidential inference APIs, where a provider serves model outputs from inside an attested TEE so customers can verify their prompts and the model’s outputs never left a protected boundary, to move from research demonstrations to mainstream commercial offerings over the next twelve to eighteen months.
ARM’s Confidential Compute Architecture (CCA), standardising Realm attestation around the PSA Certified token format, is the technology most likely to reshape this comparison within two to three years, particularly as AWS Graviton continues gaining share for general-purpose compute. Early CCA Realm previews on Graviton4 suggest AWS may eventually offer a more portable, hardware-rooted attestation model that addresses the operator-trust question this piece raises about Nitro’s current PKI-based approach, though nothing here is generally available yet and should be treated as a roadmap signal rather than a current capability. Separately, post-quantum considerations are starting to surface in attestation design discussions, since a long-lived signed attestation certificate is exactly the kind of asset that needs to remain trustworthy well beyond the useful life of current public-key cryptography, though concrete vendor commitments in this area remain early.
Strategic Recommendations
Treat confidential computing as a targeted control for specific high-sensitivity workloads, not a platform-wide default. The operational cost, in constrained debugging, migration restrictions, and in AWS’s case a genuine application re-architecture for Nitro Enclaves, is real enough that blanket adoption is the most common and most expensive mistake teams make in year one. Match the architecture to the workload rather than the cloud: choose Azure or GCP confidential VMs for lift-and-shift protection of existing workloads with minimal code change, choose AWS Nitro Enclaves for narrowly scoped, highest-sensitivity functions like key management, and choose GCP specifically when multi-party collaboration with mutually distrusting parties is the core requirement rather than a nice-to-have. For any workload touching GPU-accelerated AI, the current lack of GPU support in AWS Nitro Enclaves should end the platform debate for that specific workload rather than prompt a lengthy comparison. Whichever platform you choose, resolve the attestation root of trust question with your compliance and security teams explicitly and in writing before committing, because it is the one architectural difference in this comparison that a later platform migration cannot easily undo.
Useful Links
- AWS Nitro Enclaves attestation documentation
- AWS Confidential Computing overview
- AMD SEV-SNP for Amazon EC2 instances
- Portal and Anjuna Nitro Enclaves case study
- Auros Nitro Enclaves case study
- Azure Confidential Computing products overview
- BeeKeeperAI Microsoft customer story
- Google Cloud Confidential VM overview
- Google Cloud Confidential Space overview
- Gartner top strategic technology trends for 2026
