AWS vs. Azure vs. GCP: A Privacy-Focused Comparison

When Snowden leaked NSA documents in 2013, all three major US cloud providers scrambled to encrypt inter-datacenter traffic. Before that disclosure, data moving between Google’s datacenters — including between its cloud customers’ workloads — traversed private fiber links in plaintext. The encryption that users now take for granted was a reactive measure, not a design principle. Thirteen years later, the fundamental question persists: how much privacy can a US-headquartered hyperscaler structurally deliver?

The answer varies meaningfully across AWS, Azure, and GCP. While all three operate under identical US legal constraints, their engineering architectures, default configurations, and privacy postures diverge in ways that matter for organizations evaluating sensitive workload placement.

The Comparison Framework

Evaluating cloud provider privacy requires examining six dimensions:

1. Encryption architecture — How data is encrypted at rest, in transit, and in use
2. Key management — Who controls encryption keys and under what conditions
3. Data residency — Where data is stored and processed, including control plane traffic
4. Government access — Transparency reporting and legal process response
5. Metadata exposure — What operational data the provider retains
6. Confidential computing — Hardware-level data protection during processing

Each dimension reveals different strengths and weaknesses across the three providers.

Encryption Architecture

AWS

AWS encrypts data at rest by default for most services as of 2023. S3 buckets created after January 2023 are automatically encrypted with SSE-S3 (server-side encryption with Amazon-managed keys). EBS volumes, RDS databases, and most managed services support encryption at rest, though not all enable it by default.

In-transit encryption uses TLS 1.2 or 1.3 for all API endpoints. Inter-region and inter-AZ traffic is encrypted automatically. The Nitro System architecture isolates the hypervisor from customer workloads, with a hardware-based root of trust that prevents Amazon employees from accessing customer data on running instances.

AWS’s encryption implementation is mature, but its default posture has historically been permissive. Until 2023, S3 buckets were created without encryption by default — a design choice that contributed to hundreds of publicized data exposures.

Azure

Azure encrypts all data at rest using 256-bit AES encryption by default, managed through Azure Storage Service Encryption. Azure SQL Database, Cosmos DB, and Blob Storage all encrypt by default without requiring customer configuration.

Azure’s in-transit encryption is comprehensive: TLS 1.2 is the minimum for all Azure services, with TLS 1.3 supported across most endpoints. Azure also encrypts traffic between datacenters using MACsec (IEEE 802.1AE) at the physical layer — a hardware-level protection that operates below the software stack.

Azure’s encryption-by-default posture has been more aggressive than AWS’s. However, Azure’s complexity — with over 200 services, many acquired through acquisition — means encryption implementation quality varies across the portfolio.

GCP

Google encrypts all data at rest by default using AES-256 or AES-128, with a multi-layered key hierarchy: Data Encryption Keys (DEKs) encrypt the data, Key Encryption Keys (KEKs) encrypt the DEKs, and a master key stored in Google’s KMS encrypts the KEKs.

In-transit encryption is automatic for all inter-service communication within Google’s infrastructure using ALTS (Application Layer Transport Security), Google’s proprietary mutual TLS replacement. External traffic uses TLS 1.2+.

Google’s encryption architecture is the most deeply integrated of the three providers — a consequence of Google having built its infrastructure from scratch rather than assembling it through acquisitions. The trade-off is transparency: Google’s proprietary protocols (ALTS, Tink) are well-documented but not independently auditable in the same way that standards-based implementations are.

Privacy Comparison Table

Key Management: The Critical Differentiator

Encryption is only as strong as key management. The question is not whether data is encrypted, but who holds the keys — and under what circumstances those keys can be accessed.

All three providers offer tiered key management:

Provider-managed keys: The provider generates, stores, and manages encryption keys. The customer has no direct access to or control over key material. This is the default for all three providers and provides protection against physical theft of storage media, but no protection against provider access or legal process.

Customer-managed keys (CMK): The customer generates keys in the provider’s key management service and controls access policies. The key material resides within the provider’s infrastructure. This provides audit trails and access control but does not prevent the provider from accessing keys under legal compulsion.

External key management: The customer holds keys in infrastructure outside the cloud provider’s control. AWS External Key Store (XKS), Azure External Key Vault, and GCP Cloud External Key Manager (EKM) all support this model. The provider cannot access plaintext data without the customer’s external key service being available and willing to provide keys.

External key management is the strongest privacy option within the public cloud model. If properly implemented, it means a CLOUD Act subpoena served on the cloud provider yields only ciphertext — the provider genuinely cannot decrypt the data without the customer’s cooperation.

The practical limitations are significant. External key management introduces latency (every encryption/decryption operation requires a round trip to the external key service), complexity (the customer must operate a highly available key service), and service restrictions (not all cloud services support external keys). GCP’s EKM integration is the most mature, supporting Compute Engine, BigQuery, Cloud Storage, and GKE. AWS’s XKS, launched in 2022, supports a narrower set of services. Azure’s external key support remains the most limited.

For organizations requiring architectural key control, external key management is necessary but not sufficient. The metadata, access patterns, and operational telemetry generated by the cloud provider remain unencrypted and accessible regardless of key management strategy. Zero-persistence architecture addresses this gap by eliminating the data — including metadata — after processing is complete.

Government Access: Transparency and Process

All three providers are headquartered in the United States and subject to the CLOUD Act, FISA Section 702, National Security Letters, and other US legal instruments for compelled data disclosure. This is the non-negotiable privacy limitation of all US cloud providers.

Within this constraint, the providers’ transparency reporting reveals quantitative differences:

AWS disclosed approximately 3,200 government requests in 2024, of which approximately 40% were subpoenas, 35% were court orders, and 25% were search warrants. AWS challenged or narrowed approximately 20% of requests and produced no content in response to approximately 25%.

Microsoft (Azure) disclosed approximately 4,100 government requests in 2024 across all Microsoft services (Azure-specific data is not broken out). Microsoft’s Transparency Report shows a higher challenge rate — approximately 25% of requests were challenged or narrowed.

Google (GCP) disclosed approximately 2,800 government requests in 2024 for enterprise cloud services specifically. Google’s transparency reporting is the most granular of the three, providing country-level breakdowns and distinguishing between content and non-content requests.

These numbers represent disclosed requests. National Security Letters and FISA orders carry gag provisions that prevent disclosure of individual requests, though aggregate ranges are reported. The actual volume of government access may exceed disclosed figures.

The critical question is not how many requests are made, but what data is available in response. With provider-managed encryption, the full plaintext of customer data is available. With customer-managed keys, plaintext is available because the provider can access the KMS. With external key management, only ciphertext and metadata are available — though metadata alone may be sufficient for many investigative purposes.

Confidential Computing Posture

Confidential computing represents the most promising technical approach to protecting data during processing — the one phase of the data lifecycle where encryption has historically been impossible.

AWS offers Nitro Enclaves, which create isolated compute environments within EC2 instances. Nitro Enclaves use the Nitro hypervisor’s isolation capabilities rather than CPU-level trusted execution environments. AWS also supports AMD SEV-enabled instances (providing memory encryption) but has been slower than Azure and GCP to adopt Intel TDX.

Azure has the most comprehensive confidential computing portfolio. Azure Confidential VMs support both AMD SEV-SNP and Intel TDX. Azure Confidential Containers run containerized workloads in hardware-attested TEEs. Azure Confidential Ledger provides tamper-proof data storage. Azure’s investment in confidential computing has been the most aggressive of the three providers, driven partly by enterprise demand for GDPR-compliant AI processing.

GCP offers Confidential VMs using AMD SEV and Intel TDX, Confidential GKE Nodes for Kubernetes workloads, and Confidential Dataflow for data processing pipelines. GCP’s approach emphasizes transparency — Google publishes the UEFI firmware code for its Confidential VMs, enabling independent verification of the trusted computing base.

For privacy-focused workloads, Azure’s confidential computing maturity currently leads the field. GCP’s transparency is strongest. AWS’s Nitro architecture provides a unique isolation model but lags in TEE hardware adoption.

Metadata and Telemetry Exposure

The dimension most often overlooked in cloud privacy comparisons is metadata exposure — the operational data generated by using the cloud platform itself.

AWS CloudTrail logs every API call made to AWS services. Default retention is 90 days in the CloudTrail console; indefinite retention requires configuring a trail to S3. CloudTrail logs include the identity of the caller, the API action, the timestamp, the source IP, and request parameters. These logs are accessible to AWS for operational purposes and are producible under legal process.

Azure Activity Log records control-plane operations for 90 days by default. Azure Monitor extends logging capabilities. Azure AD sign-in logs record every authentication event, including IP addresses, device information, and location data. Microsoft’s operational access to these logs is governed by its Customer Lockbox feature, which requires customer approval for Microsoft engineer access to customer data — one of the stronger metadata access controls among the three providers.

GCP Audit Logs are retained for 400 days by default — significantly longer than AWS or Azure defaults. Admin Activity logs are always on and cannot be disabled. GCP’s Access Transparency feature logs every access by Google personnel to customer data, providing a verifiable record of provider-side access.

The metadata retained by all three providers is sufficient to reconstruct detailed patterns of cloud usage: which services were accessed, when, by whom, from where, and how frequently. This metadata layer is not protected by customer encryption keys and remains fully accessible to the provider and to legal process.

Practical Recommendations by Use Case

Regulated data (GDPR, HIPAA, FINMA): Azure with Confidential VMs and Customer Lockbox, or GCP with External Key Manager and Access Transparency, provide the strongest combination of encryption, access control, and auditability within the hyperscale model. Neither eliminates CLOUD Act exposure.

AI/ML workloads with sensitive training data: GCP Confidential Dataflow or Azure Confidential Containers enable model training on encrypted data without exposing plaintext to the cloud operator. Both carry performance penalties of 5-15% compared to non-confidential processing.

Maximum privacy within public cloud: External key management (GCP EKM preferred for broadest service support) combined with confidential computing VMs, regionalized deployment, and aggressive log minimization. This approach reduces — but does not eliminate — provider access to customer data.

Privacy as a structural requirement: No US hyperscaler can provide architectural guarantees against provider access. For workloads where this is a requirement, the evaluation must extend beyond AWS/Azure/GCP to sovereign cloud providers or Stealth Cloud architectures that eliminate provider access by design.

What the Comparison Reveals

The differences between AWS, Azure, and GCP on privacy are real but bounded. Azure leads on confidential computing breadth and access controls. GCP leads on encryption integration depth and transparency. AWS leads on network isolation and the Nitro hardware security model. All three are improving rapidly — the privacy features available in 2026 would have been unimaginable in 2020.

But the comparison also reveals what is structurally identical across all three: US legal jurisdiction, provider access to metadata, and an architecture where encryption keys — even customer-managed ones — are accessible to the platform under legal compulsion unless externally managed. These are not implementation details that competition between providers will resolve. They are architectural constraints of the public cloud model itself.

The Stealth Cloud Perspective

Choosing between AWS, Azure, and GCP on privacy is choosing between varying degrees of insufficient. Each provider has made genuine, substantial investments in privacy engineering — and each remains structurally unable to guarantee that customer data is inaccessible to the provider or to US legal process. The question is not which hyperscaler is most private. The question is whether the hyperscale model, with its inherent requirement for provider access, is compatible with your privacy requirements at all. For a growing class of workloads, the answer is no — and that answer is the market thesis for Stealth Cloud.