AWS KMS Vs Azure Key Vault Vs GCP KMS

AWS KMS, Azure Key Vault, and GCP Cloud KMS are the three major cloud providers’ managed services for generating, storing, and using encryption keys. The choice matters because each enforces a different security and access model under the hood, and switching later means re-architecting your encryption strategy. The recommended action: match the service to your dominant cloud for native workloads, and decide your key-control model (native, BYOK, or HYOK) explicitly before you scale past a handful of keys.

Published: July 2021. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Key Management Advisory Team.

If you run AWS and Azure only, with no plans to add GCP, our narrower AWS vs Azure KMS comparison goes deeper on that specific two-cloud decision. This article covers all three providers for teams evaluating the full field.

What Are AWS KMS, Azure Key Vault, and GCP Cloud KMS?

AWS Key Management Service (KMS), Azure Key Vault, and Google Cloud Key Management Service (Cloud KMS) are each cloud provider’s managed offering for creating, storing, and using cryptographic keys without operating your own hardware security modules (HSMs). All three follow the same conceptual pattern: a key-encryption key (KEK) held by the service protects data-encryption keys (DEKs), which in turn protect your actual data, and the KEK itself is never returned to you in the clear. Where they diverge is key management terminology, IAM integration, rotation defaults, and how far you can push control of the key material outside the provider.

AWS renamed its original “Customer Master Key (CMK)” terminology to KMS key years ago; current AWS documentation distinguishes customer managed keys, AWS managed keys, and AWS owned keys. Azure Key Vault issues keys from a Standard (software-protected, multi-tenant) or Premium (shared HSM pool) tier, plus a separate Managed HSM product for single-tenant, dedicated hardware. GCP Cloud KMS prices SOFTWARE, HSM, and EXTERNAL keys as three distinct protection levels within one service.

How Do Native Key Storage Models Compare?

Each provider defaults to a different hardware validation level and key-type support, which determines what you can do without stepping up to a premium tier.

Feature	AWS KMS	Azure Key Vault	GCP Cloud KMS
Default key protection	FIPS 140-2 validated HSM (all keys)	Software (Standard) or shared HSM pool (Premium)	Software, HSM, or external, chosen per key
Dedicated single-tenant HSM option	Via CloudHSM integration	Managed HSM (FIPS 140-3 Level 3, Marvell LiquidSecurity)	Single-tenant Cloud HSM
Key types supported	Symmetric, asymmetric (RSA, ECC), HMAC	RSA and Elliptic Curve (asymmetric); no native symmetric key type	Symmetric (AES-256) and asymmetric (RSA, ECC)
Key portability	Never leaves the AWS Region it was created in	Never leaves the vault boundary; Microsoft states it cannot see key material	Never leaves the key ring’s location

Should You Use Native Keys, BYOK, or HYOK Across These Clouds?

Use each provider’s native keys by default, move to BYOK when you need to prove where a key originated, and reserve HYOK for the specific keys a regulator or contract says must never touch the cloud provider’s infrastructure. All three clouds support all three models, but the HYOK mechanics differ enough to change your architecture.

Model	AWS KMS	Azure Key Vault	GCP Cloud KMS
Native	KMS-generated key, never exportable	Vault- or Managed-HSM-generated key	Cloud KMS-generated key
BYOK	Import key material wrapped with RSA; AWS holds a usable copy	Import HSM-protected key material into Managed HSM from an on-premises HSM	Import key material (AES-256 wrapped by RSA 3072-bit)
HYOK	External Key Store (XKS): double encryption, key never leaves your external key manager	External Key Management (preview): wrap/unwrap delegated to a customer-run EKM proxy; not covered by the Managed HSM SLA	Cloud External Key Manager (EKM): dual-layer encryption via Fortanix, Futurex, or Thales; a request fails if the external key is unreachable

Every HYOK implementation shares the same trade-off: you gain provable control over the key, and you take on the operational risk of your external key manager’s uptime. Google is explicit about the downside — for Cloud Spanner specifically, an EKM key unreachable for more than 30 days causes permanent data loss, since Google states it cannot recover data protected by a key it never held. See our Hybrid KMS explainer for the BYOK-vs-HYOK trade-off in more depth, and Dedicated vs. Shared HSMs for how key custody isolation choices carry over into HSM procurement.

How Does the IAM Model Differ Across AWS, Azure, and GCP?

All three use their platform’s general-purpose identity system for key access, layered with a KMS-specific permission or policy model — none of them invented a separate identity system just for keys.

• AWS KMS combines IAM identity-based policies with a mandatory key policy attached to every KMS key, plus temporary grants for cross-account or service access. Least-privilege setup means denying kms:CreateGrant except where an encryption-context condition matches an approved key ARN.
• Azure Key Vault supports both legacy vault access policies and Azure RBAC; Managed HSM uses a separate, local RBAC system that Azure subscription administrators cannot override, which is the point — it is designed so even Microsoft support staff cannot grant themselves key access.
• GCP Cloud KMS is governed entirely by Cloud IAM roles, such as roles/cloudkms.cryptoKeyEncrypterDecrypter for use-only access and roles/cloudkms.admin for management, with Google explicitly recommending separation of duties between the two.

A least-privilege setup that works across all three follows the same five steps regardless of provider:

1. Separate production and non-production keys into different accounts, subscriptions, or projects so a compromised test identity can never reach a production key.
2. Grant encrypt/decrypt (use) permissions and key administration permissions to different roles — never the same role.
3. Scope every grant to a specific key resource, never a wildcard, using resource ARNs (AWS), scoped RBAC assignments (Azure), or IAM conditions (GCP).
4. Require MFA or a privileged-access workflow for any action that can delete or schedule deletion of a key or vault.
5. Review access on a quarterly cadence using each provider’s native tooling — IAM Access Analyzer (AWS), Azure AD access reviews (Azure), or IAM Recommender (GCP).

How Does Key Rotation Work in Each Service?

Rotation is automatic in all three services for symmetric keys, but the configurable range and hard limits differ enough to affect your compliance documentation.

• AWS KMS: automatic rotation for symmetric keys is configurable from 90 days to 2,560 days (about seven years); asymmetric and HMAC keys are not eligible and must be rotated by creating a new key. Imported key material supports on-demand rotation, up to ten times over the key’s lifetime. The first two rotations of a key add $1/month each to its cost; the price increase caps after that.
• Azure Key Vault Managed HSM: autorotation policies are creation-based or expiration-based, with a minimum interval of 28 days; Microsoft recommends rotating at least every two years per NIST SP 800-57. Each key is capped at 100 versions total, and rotations count against that limit. Standard and Premium Key Vault (non-Managed-HSM) do not offer built-in autorotation in the same way and typically rely on Azure Automation or Event Grid-triggered rotation.
• GCP Cloud KMS: automatic rotation for symmetric keys is configurable from 1 day to 100 years; asymmetric signing and encryption keys are not eligible for automatic rotation. Rotating a key does not disable or re-encrypt data protected by older key versions — those versions must be manually disabled or destroyed once retired.

What Should You Log and Monitor in Each Cloud?

Enable logging before you create your first key in any of the three services, not after an incident forces the question.

• AWS: CloudTrail captures every KMS management call (create, rotate, disable, policy edit) and every cryptographic call (encrypt, decrypt, generate-data-key), including the calling identity and source IP.
• Azure: Key Vault emits an AuditEvent diagnostic log category through Azure Monitor diagnostic settings, routable to Log Analytics, an Event Hub, or storage for long-term retention.
• GCP: Cloud Audit Logs records both Admin Activity (management operations, always on, cannot be disabled) and Data Access logs (key use, must be explicitly enabled) for every Cloud KMS key.

Whichever cloud you standardize on, feed these logs into a SIEM and alert specifically on key deletion, policy changes, and export or wrap/unwrap events against HYOK keys — these are the actions that turn a routine key operation into an incident.

How Do AWS KMS, Azure Key Vault, and GCP Cloud KMS Compare on Cost?

None of the three pricing models line up cleanly against each other — AWS charges per key, GCP charges per key version per protection level, and Azure charges per operation plus a separate HSM-key surcharge.

Provider	Base key cost	Operations	HYOK / external option
AWS KMS	$1.00/key/month, flat regardless of key type	$0.03/10,000 requests (20,000 free/month)	External Key Store: same $1/month, plus your own key-manager infrastructure cost
Azure Key Vault	Software keys: no separate storage fee; HSM-protected keys: roughly $1–$5/key/month, tiered down by volume	~$0.03/10,000 operations (software), ~$0.15/10,000 for advanced key operations	External Key Management: preview, no separate published price yet
GCP Cloud KMS	$0.06/key-version/month (software), $1.00/key-version/month (HSM)	$0.03/10,000 operations ($0.15/10,000 for certain HSM operations)	EXTERNAL/EXTERNAL_VPC (EKM): $3.00/key-version/month

Azure’s exact figures vary by region and are not published as fixed global rates on Microsoft’s pricing page at the time of writing; treat the numbers above as directional and confirm current regional pricing before budgeting. A single-tenant Cloud HSM on GCP runs roughly $3,500/month flat and includes 15,000 key versions at no additional charge, which can be cheaper than per-version HSM pricing at real scale.

What Does a Multi-Cloud Key Management Architecture Look Like?

If you run all three clouds, or expect to, the safer design treats each provider’s KMS as a regional enforcement point under a centralized key and certificate governance layer, rather than three independent sources of truth that drift apart over time. That layer tracks which keys exist where, which protection level and rotation policy each one uses, and which team owns it — work that none of AWS KMS, Azure Key Vault, or GCP Cloud KMS does for you across providers.

For the full reference architecture, see our Multi-Cloud PKIaaS Architecture Guide for AWS, Azure, and GCP. For background on why this matters even before you reach three clouds, our Education Center covers multi-cloud key management and the features commercial key management solutions share.

What Are the Limitations of Each Service?

• AWS KMS: a key never leaves the Region it was created in, so a multi-region strategy needs explicit multi-Region keys, not a default; KMS cannot use a data key to encrypt or decrypt on your behalf, so applications must handle that themselves.
• Azure Key Vault: External Key Management is still in preview, is not covered by the Managed HSM SLA, and supports wrap/unwrap only; Managed HSM caps every key at 100 versions, and frequent rotation counts against that ceiling.
• GCP Cloud KMS: Cloud EKM supports only three named external key management partners today (Fortanix, Futurex, Thales); rotating a key never re-encrypts data under old versions automatically, so retired versions must be cleaned up manually to control cost and risk.

Decision Checklist: Choosing Between AWS KMS, Azure Key Vault, and GCP Cloud KMS

1. Start with where your workloads already live. Native integration with your compute, storage, and database services outweighs marginal feature differences between the three KMS offerings.
2. Decide your key-control model per data classification, not once for the whole organization — native for most workloads, BYOK where key provenance must be documented, HYOK only where a regulator or contract requires it.
3. Map your rotation policy to each provider’s actual constraints — Azure Managed HSM’s 28-day minimum and 100-version cap, in particular, needs to be designed around up front, not discovered during an audit.
4. Model cost at your real key and operation volume, not the headline per-key or per-operation number — GCP’s per-protection-level pricing and Azure’s tiered HSM-key fees both change meaningfully at scale.
5. If you run more than one cloud today, or expect to within 18 months, evaluate a centralized key and certificate management layer before you have three independent, drifting KMS configurations to reconcile.

What Would Encryption Consulting Recommend?

For a single-cloud shop, use the native KMS of that cloud and don’t overthink it — all three are mature, FIPS-validated services. The decision gets genuinely hard the moment you run two or more clouds, because none of AWS KMS, Azure Key Vault, or GCP Cloud KMS was built to give you one view across the others. In our engagements, the organizations that struggle are the ones that adopted each cloud’s KMS independently, then tried to bolt on governance after the fact. We recommend deciding your key-custody model (native, BYOK, or HYOK) and your rotation and logging standards once, centrally, through HSM-as-a-Service for FIPS-validated custody that spans providers, before individual teams standardize on whatever their cloud console defaults to. If you need an outside assessment of where your current multi-cloud key posture stands, our Cloud Data Protection assessment benchmarks AWS, Azure, and GCP environments against NIST and CIS controls.

Frequently Asked Questions

Which is more secure: AWS KMS, Azure Key Vault, or GCP Cloud KMS?

All three are FIPS-validated managed services from providers with mature security track records, and none is categorically less secure than the others for default, native-key use. The meaningful security differences show up in the details: hardware validation level per tier, whether HYOK is generally available or still in preview, and how tightly you configure IAM and logging — not in which vendor’s logo is on the service.

Can I use the same encryption key across AWS, Azure, and GCP?

Not directly. Each provider’s native key never leaves that provider’s boundary by design. The closest you get to a shared key across clouds is HYOK: hosting the key material in your own external key manager and having each cloud call out to it (AWS External Key Store, Azure External Key Management, or GCP Cloud EKM), which lets one key material source serve multiple clouds at the cost of making your external key manager a single point of failure for all of them.

Is Azure Key Vault Managed HSM the same as HYOK?

No. Managed HSM is a dedicated, single-tenant hardware option that still runs inside Microsoft’s infrastructure — it is a stronger native-key option, not an external one. Azure’s actual HYOK equivalent is External Key Management, a separate preview feature that delegates wrap/unwrap operations to a key manager you run outside Azure.

Why does GCP charge more for external (EKM) keys than for HSM keys?

Google prices EXTERNAL and EXTERNAL_VPC key versions at $3.00/month, three times the $1.00/month HSM rate, because every cryptographic operation against an EKM key requires a live network round trip to your external key manager rather than a local HSM call. That added latency and dependency is also why Google explicitly warns that losing access to an external key can cause permanent, unrecoverable data loss.

Do I need a multi-cloud key management strategy if I only use one cloud today?

Not immediately, but it is worth deciding your key-control model, rotation policy, and logging standard as if you might add a second cloud, since retrofitting those decisions later is far more disruptive than setting them consistently from the start. If a second cloud is already on your roadmap, start that governance layer now rather than after the migration.

Contact [email protected] if you would like help auditing or architecting key management across AWS, Azure, and GCP.