Key Management Services: AWS KMS, Azure Key Vault, GCP KMS

Introduction

A single exposed encryption key can invalidate every security control you have built. When researchers analyzed data breach disclosures, they found that improperly managed cryptographic keys were a root cause in a significant proportion of cloud storage incidents. You can encrypt every database, every file, and every API call — but if the keys protecting that data are stored next to the data itself, the encryption provides almost no protection.

This is the problem that cloud Key Management Services (KMS) solve. AWS, Microsoft Azure, and Google Cloud each offer a managed KMS that stores your keys in hardware-backed security modules, enforces access policies, and provides a complete audit trail of every key operation.

Choosing between them is a real decision with compliance and cost implications. In this article, you will learn exactly how each service works, how they compare across the features that matter most, and which use cases each is best suited for.

What Is a Key Management Service?

A Key Management Service (KMS) is a cloud-managed platform responsible for creating, storing, rotating, and auditing the cryptographic keys used to encrypt your data. Think of it as a centralized vault for your keys — one that logs every single access attempt and can automatically invalidate or rotate keys when a security event occurs.

At the heart of every KMS is a Hardware Security Module (HSM), a tamper-resistant physical device that generates and stores key material. The key never leaves the HSM in plaintext. When your application needs to decrypt data, it sends the ciphertext to the KMS, which performs the decryption inside the HSM and returns only the plaintext result.

This architecture is called envelope encryption. Instead of encrypting your data directly with a master key, the KMS generates a unique Data Encryption Key (DEK) for each object. The DEK is then encrypted by a Key Encryption Key (KEK) stored in the KMS. This limits the blast radius of any single key compromise.

How Key Management Services Work

Each of the three major providers implements this architecture differently, but the fundamental flow is consistent:

1. Key Creation: You create a Customer Managed Key (CMK) or Customer Managed Encryption Key (CMEK) in the KMS. The key material is generated inside the HSM and never exported in plaintext.
2. Policy Assignment: You attach an access policy defining which identities (users, roles, service accounts) can use the key and for which operations (encrypt, decrypt, sign, verify).
3. Encryption: When a service writes data, it requests a DEK from the KMS. The KMS generates the DEK, encrypts it with your CMK, and returns both the plaintext DEK (used briefly to encrypt the data) and the encrypted DEK (stored alongside the ciphertext).
4. Decryption: To read the data, the authorized service sends the encrypted DEK to the KMS. The KMS checks the access policy, decrypts the DEK inside the HSM, and returns it so the service can decrypt the data.
5. Audit Logging: Every encrypt and decrypt call is logged with a timestamp, calling identity, and result — giving you a complete, immutable record for compliance audits.

VIDEO · READY 16:9

PLAY

AWS KMS Tutorial for Beginners | Encryption, Keys, & Secrets Explained

AWS KMS vs Azure Key Vault vs GCP Cloud KMS

All three services are enterprise-grade and FIPS 140-2 compliant, but they differ significantly in their integration models, pricing, and control granularity.

AWS KMS is the most tightly integrated with AWS services. Nearly every AWS service — S3, RDS, EBS, Lambda — can use a CMK from KMS transparently. Access control is managed entirely through IAM policies and KMS key policies, which are powerful but have a steep learning curve. The pricing model charges per API call, which can add up in high-throughput workloads.

Azure Key Vault goes beyond keys to store secrets (connection strings, passwords) and TLS certificates in the same vault. Access control uses Azure Active Directory (AAD) roles and vault access policies. This makes it extremely convenient for teams already embedded in the Microsoft ecosystem. The Premium tier adds dedicated HSM backing. For organizations seeking an international management standard, ISO 27001 provides a certifiable framework that complements SOC 2 attestation.

GCP Cloud KMS offers the most granular geographic control through its key ring and key location model. You can pin a key to a specific region, a multi-region, or mark it as global. This is critical for data residency compliance. GCP also offers Cloud EKM (External Key Manager), allowing you to store key material outside of Google’s infrastructure entirely.

Real-World Use Cases

A financial services company running on AWS encrypts every S3 bucket and RDS database with customer-managed KMS keys. They use a separate CMK per data classification tier — one for public data, one for internal data, and one for regulated financial records. When a breach is suspected in one tier, they can immediately revoke only that CMK without affecting the other tiers.

A healthcare provider using Azure encrypts patient records in Azure SQL using Key Vault. They use Azure AD Managed Identities so that application servers automatically receive the permissions they need — no static credentials or API keys stored in application code. The audit logs in Key Vault feed directly into their SIEM for HIPAA compliance reporting.

A multinational e-commerce platform on GCP uses Cloud KMS with data residency requirements for EU customers. They create key rings in europe-west3 (Frankfurt) and restrict all encryption of EU customer records to those regionally pinned keys, satisfying GDPR Article 46 data transfer requirements without any custom infrastructure.

Common Mistakes to Avoid

The most dangerous mistake is using Google-managed default encryption (or its AWS/Azure equivalent) without creating customer-managed keys. Default encryption protects against physical storage theft, but the provider holds the key. If a misconfigured IAM policy grants excessive access, the provider’s key gives no additional protection.

A second common error is granting decrypt permissions too broadly. In AWS KMS, it is tempting to attach a single key policy that allows an entire AWS account to use a CMK. This means every compromised IAM credential in that account can decrypt your most sensitive data. Always restrict key usage to the specific role or service that needs it.

Finally, organizations often skip key rotation configuration. All three providers can auto-rotate annual key versions. Failing to enable this means that a key compromised today could still be valid years from now. Enable automatic rotation for every symmetric CMK at creation time, not as an afterthought.

Getting Started

Begin by auditing what you currently encrypt and with what keys. Log into your cloud console and identify which resources use provider-managed default keys versus customer-managed keys. Any database, object store, or queue holding sensitive data should be using a CMK you control.

Next, create a separate CMK for each data classification level — do not use one key for everything. Assign the narrowest possible decrypt policy to each key, limited to the specific service account or role that needs access. Enable automatic annual rotation and connect your KMS audit logs to your centralized logging system.

For deeper understanding of the encryption algorithms these keys protect, read our overview of AES-256-GCM Authenticated Encryption. To understand the hardware behind the HSMs powering these services, see our guide on Hardware Security Modules. For workloads where you cannot trust the cloud provider with plaintext data even during processing, see What Is Confidential Computing — the technology that protects data in use using hardware-isolated TEEs.