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.

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 is shaped by three primary US regulatory frameworks:

  1. HIPAA (45 CFR §164.312(a)(2)(iv)) — addressable encryption requirement for electronic protected health information (ePHI) at rest and in transit
  2. PCI DSS v4.0 — Requirement 3.5 mandates encryption of stored primary account numbers (PANs); Requirement 6.2.4 addresses transmission security
  3. FedRAMP — enforces FIPS 140-2/140-3 validated cryptographic modules for all cloud services handling federal data (FedRAMP Authorization documentation)

The three hyperscalers — AWS, Azure, and GCP — each hold FedRAMP High authorizations for core service lines, but coverage varies by region and service tier. Encryption configuration that satisfies FedRAMP High does not automatically satisfy the more prescriptive key management requirements under HIPAA encryption requirements or PCI DSS encryption requirements.

How it works

Each provider structures its encryption offering across two control planes: provider-managed keys and customer-managed keys (CMK), with a third variant — customer-supplied keys (CSEK) or Bring Your Own Key (BYOK) — available at the storage layer. The architectural difference between these tiers is consequential for key custody, auditability, and regulatory attestation.

AWS encryption infrastructure is anchored in AWS Key Management Service (KMS), which uses FIPS 140-2 Level 2 validated hardware security modules (HSMs). AWS KMS integrates natively with over 100 AWS services. AWS CloudHSM provides FIPS 140-2 Level 3 validated single-tenant HSMs for workloads requiring dedicated key isolation — relevant to hardware security module requirements under FedRAMP High and certain DoD workloads.

Microsoft Azure routes customer-managed key operations through Azure Key Vault, with a Premium tier backed by FIPS 140-2 Level 3 HSMs. Azure also offers Azure Dedicated HSM and Azure Managed HSM — the latter providing FIPS 140-2 Level 3 validated single-tenant instances. Azure Storage Service Encryption (SSE) applies AES-256 to all data at rest by default (AES encryption standard).

GCP uses Cloud KMS and Cloud HSM, with Cloud HSM providing FIPS 140-2 Level 3 validated hardware. GCP also supports External Key Manager (EKM), which allows encryption keys to be held entirely outside Google's infrastructure — a model that satisfies stricter data sovereignty requirements without requiring workload migration.

The cryptographic key lifecycle — generation, distribution, storage, rotation, revocation, and destruction — operates differently in each environment. AWS KMS supports automatic annual key rotation for symmetric KMS keys; Azure Key Vault supports configurable rotation policies through Key Rotation Policy; GCP Cloud KMS supports manual rotation with next rotation date scheduling.

In-transit encryption across all three providers defaults to TLS 1.2 or TLS 1.3 for API endpoints, aligning with TLS/SSL encryption protocols baseline standards. Connections between internal services within a provider's private backbone may or may not apply in-transit encryption by default — this is service-specific and must be verified per workload.

Common scenarios

Multi-tenant SaaS workloads storing ePHI: AWS, Azure, and GCP all support envelope encryption, where a data encryption key (DEK) encrypts the data and a key encryption key (KEK) stored in a managed KMS encrypts the DEK. This model satisfies the encryption key management separation-of-duties principle required under HIPAA technical safeguards.

Payment processing environments: PCI DSS v4.0 Requirement 3.7 mandates key management procedures covering full lifecycle controls. AWS CloudHSM and Azure Managed HSM both satisfy the tamper-evident, dedicated hardware standard that QSAs (Qualified Security Assessors) commonly require for cardholder data environments.

Regulated federal workloads: FedRAMP High authorization requires FIPS 140-2/140-3 validated encryption at all boundary points. AWS GovCloud (US), Azure Government, and GCP's assured workloads configurations provide isolated regions with verified module validation.

Bring Your Own Key (BYOK) deployments: Organizations retaining root key material outside provider infrastructure — a requirement for some financial regulators — can use AWS XKS (External Key Store), Azure BYOK, or GCP EKM. Tradeoffs include increased latency and operational complexity; key unavailability blocks data access entirely. See bring your own key encryption for qualification criteria.

Decision boundaries

Choosing between provider-managed keys, customer-managed keys, and external key management turns on four operationally distinct criteria:

  1. Regulatory jurisdiction: FedRAMP High requires FIPS 140-2/140-3 validated modules — all three providers meet this for core services, but validation must be confirmed per service at NIST's Cryptographic Module Validation Program (CMVP).
  2. Key custody requirements: Data sovereignty mandates in financial services (OCC guidance) and healthcare may require keys never leave customer-controlled infrastructure, pointing toward Cloud HSM or external key managers over default KMS.
  3. Operational risk tolerance: External key management (BYOK/CSEK) shifts recovery responsibility to the customer. Key loss is irrecoverable — provider support cannot assist in decryption. Default provider-managed keys offer higher availability at the cost of shared key custody.
  4. Audit and compliance posture: CMK configurations in all three providers produce key usage logs (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs) that satisfy the audit trail requirements in NIST SP 800-53 Rev 5, Control SC-28 (Protection of Information at Rest) and AU-9 (Protection of Audit Information). Provider-managed keys produce fewer customer-visible audit events.

The comparison between AWS KMS, Azure Key Vault, and GCP Cloud KMS is not primarily a feature comparison — it is an architectural decision about where the trust boundary sits between the cloud provider and the data owner. That boundary determines which encryption compliance attestations are achievable and which require compensating controls.

References

Explore This Site

Regulations & Safety Regulatory References