Encryption for Cloud Environments: AWS, Azure, and GCP Approaches
Cloud encryption spans a complex service landscape where hyperscaler-native controls, customer-managed key architectures, and regulatory mandates intersect. This page maps the encryption mechanisms available across Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), including how those mechanisms compare, where they satisfy US compliance frameworks, and where they leave gaps that require supplemental controls. The scope covers data at rest, data in transit, and key management boundaries across all three major US-dominant cloud providers. For a broader orientation to the encryption service sector, see the .
Definition and scope
Cloud encryption refers to the cryptographic protection of data stored in or transmitted through infrastructure operated by a third-party cloud provider. Unlike on-premises deployments where physical control resides with the data owner, cloud environments introduce a shared-responsibility model — codified by the National Institute of Standards and Technology (NIST) in NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing — in which the provider secures the underlying platform while the customer bears responsibility for workload-level encryption and key custody.
The scope of cloud encryption governance in the US is shaped by three primary regulatory frameworks:
- HIPAA — 45 CFR §164.312(a)(2)(iv) identifies encryption as an addressable implementation specification for electronic protected health information (ePHI), with the HHS Office for Civil Rights responsible for enforcement.
- FedRAMP — the Federal Risk and Authorization Management Program requires cloud services hosting federal data to satisfy NIST SP 800-53 Rev 5 controls, including SC-28 (Protection of Information at Rest) and SC-8 (Transmission Confidentiality and Integrity).
- PCI DSS — version 4.0, published by the PCI Security Standards Council, mandates encryption of cardholder data in transit across open public networks (Requirement 4.2.1) and at rest where compensating controls are insufficient.
Key management is the central differentiator across providers. Each hyperscaler offers a spectrum of custody options: provider-managed keys, customer-managed keys (CMK) stored in the provider's key management service, and customer-supplied keys (CSK) where the key material never enters provider infrastructure.
How it works
All three major cloud platforms apply AES-256 as the default symmetric cipher for data at rest, consistent with FIPS 197 and NIST recommendations. Data in transit is protected through TLS 1.2 or TLS 1.3 across all three, with TLS 1.3 enforced by default on newer service endpoints. The structural differences lie in key hierarchy, hardware security module (HSM) integration, and envelope encryption architecture.
AWS Key Management Service (KMS) operates a three-tier key hierarchy: AWS-managed keys, customer-managed keys (CMK), and data keys generated per-object through envelope encryption. AWS CloudHSM provides dedicated FIPS 140-2 Level 3–validated HSM clusters for customers requiring hardware-isolated key storage. AWS KMS integrates natively with over 100 AWS services, including S3, RDS, and EBS, allowing encryption-at-creation enforcement through service control policies.
Microsoft Azure Key Vault delivers a comparable envelope encryption model, with Azure-managed keys, customer-managed keys stored in Key Vault, and an HSM-backed tier (Azure Dedicated HSM and Azure Managed HSM) validated to FIPS 140-2 Level 3. Azure Storage Service Encryption (SSE) applies AES-256 automatically to all stored objects. Azure Confidential Computing extends encryption to data in use through hardware-based trusted execution environments (TEEs), relevant to workloads where NIST SP 800-188 data-in-use protections are under evaluation.
Google Cloud Key Management Service (Cloud KMS) implements the same envelope encryption pattern: a Cloud KMS master key wraps per-resource data encryption keys. Google Cloud also offers Cloud HSM (FIPS 140-2 Level 3) and Cloud External Key Manager (EKM), which keeps key material hosted outside Google infrastructure entirely — a distinction relevant to sovereignty-sensitive workloads. Google's default encryption applies AES-256 with keys managed by Google, rotated automatically.
The operational sequence across all three platforms follows a consistent pattern:
Common scenarios
Regulated healthcare data on AWS — organizations subject to HIPAA execute a Business Associate Agreement (BAA) with AWS and enforce CMK-based encryption on S3 buckets and RDS instances. AWS KMS key policies restrict decryption to specific IAM roles, satisfying the minimum-necessary access principle under 45 CFR §164.514(d).
Federal workloads on Azure — FedRAMP High–authorized Azure Government regions host DoD and civilian agency workloads. Azure Blueprint policies enforce SSE with customer-managed keys in Azure Government Key Vault, mapping directly to NIST SP 800-53 Rev 5 SC-28 and SC-12 controls. The Encryption Providers section of this provider network covers service providers operating in this space.
Multi-cloud key sovereignty on GCP — enterprises operating across jurisdictions use Cloud EKM to retain key material in a third-party HSM outside Google's data centers. This architecture addresses data residency requirements under frameworks such as the EU-US Data Privacy Framework, though GCP's EKM introduces latency at decryption events and requires availability SLA planning for the external key host.
PCI DSS cardholder data environments — all three providers publish PCI DSS responsibility matrices. Under PCI DSS 4.0 Requirement 3.5.1, strong cryptography must protect stored PANs; AWS, Azure, and GCP each satisfy the cryptographic algorithm requirement when CMK rotation is configured at intervals not exceeding 12 months, per PCI DSS guidance.
Decision boundaries
Selecting among provider-managed, customer-managed, and customer-supplied key architectures involves a defined set of tradeoffs that compliance posture, operational capacity, and threat model determine.
| Key Custody Model | Provider Access to Keys | FIPS 140-2 Boundary | Operational Overhead | Relevant When |
|---|---|---|---|---|
| Provider-managed (default) | Yes | Provider HSM | Minimal | Low-sensitivity workloads, development environments |
| Customer-managed (CMK/KMS) | No (customer controls policy) | Provider KMS/HSM | Moderate | HIPAA, FedRAMP Moderate, PCI DSS |
| Customer-supplied (CSK/EKM) | No | Customer HSM | High | FedRAMP High, data sovereignty mandates, classified-adjacent |
Three boundary conditions determine which model applies:
Regulatory mandate vs. operational feasibility — FedRAMP High control baseline SC-12(1) requires key establishment using NIST-approved key establishment schemes, effectively requiring CMK or CSK architectures for federal data. HIPAA does not mandate CMK but the HHS Guidance on HIPAA and Cloud Computing identifies key management practices as a significant factor in breach risk assessment.
AWS CMK vs. Azure CMK vs. GCP CMEK — functional equivalence exists at the envelope encryption layer, but integration depth varies. AWS KMS supports automatic key rotation on a 365-day cycle for symmetric CMKs. Azure Key Vault supports configurable rotation policies with expiration enforcement. GCP CMEK requires manual rotation unless Cloud KMS automated rotation is explicitly configured; the default rotation period is 90 days when enabled, per Google Cloud KMS documentation.
HSM-backed vs. software-backed KMS — AWS KMS standard tier uses HSM clusters internally but does not expose dedicated hardware to the customer; CloudHSM and Azure Dedicated HSM provide single-tenant hardware. The distinction matters for FIPS 140-2 Level 3 attestation requirements in DoD IL4/IL5 environments and for financial services firms subject to OCC guidance on third-party risk.
For organizations evaluating provider capabilities against specific compliance requirements, the How to Use This Encryption Resource page describes how this provider network structures provider and service-category coverage.