AWS VS Azure KMS

AWS Key Management Service (KMS) and Azure Key Vault are the native key management services for AWS and Microsoft Azure, and the right choice depends on your IAM model, HSM requirements, and rotation needs. Most two-cloud teams should default to each provider’s native service for workloads that stay in that cloud, and reach for a third-party or multi-cloud key manager only when they need one control plane across both.

Published: October 2018. Updated: August 2026. Written by Aryan Kumar, reviewed by Encryption Consulting’s cloud security team.

This comparison focuses on AWS and Azure because that is the most common two-cloud pairing we see in the field. If Google Cloud is also in scope, read our companion post, AWS KMS vs. Azure Key Vault vs. GCP KMS, which uses this same framework across all three providers.

What Are AWS KMS and Azure Key Vault?

AWS Key Management Service (KMS) is AWS’s managed service for creating, storing, and controlling access to encryption keys, called KMS keys, that protect data across AWS services such as S3, EBS, and RDS. Azure Key Vault is Microsoft’s managed service for keys, secrets, and certificates, and it doubles as Azure’s native key management layer for services like Storage, SQL Database, and Disk Encryption. Both are control planes for cryptographic keys, not general-purpose secrets managers competing with something like HashiCorp Vault, though both also happen to store application secrets. The rest of this post treats “key management” as the shared job both services do, and calls out where their approaches diverge.

How Do AWS KMS and Azure Key Vault Store Keys Natively?

AWS KMS gives every customer managed key HSM-level protection by default; Azure Key Vault splits that guarantee across pricing tiers, so the tier you pick determines the hardware backing your keys.

Control	AWS KMS	Azure Key Vault
Default key protection	FIPS 140-3 Level 3 validated HSMs for every customer managed key	Standard tier: software-protected keys, FIPS 140-2 Level 2
Dedicated single-tenant HSM option	AWS CloudHSM (separate service) for full single-tenant control	Managed HSM: single-tenant FIPS 140-3 Level 3 HSM pool with its own RBAC model
HSM-backed Key Vault tier	N/A (KMS itself is already HSM-backed)	Premium tier: HSM-protected keys, FIPS 140-3 Level 3, shared multi-tenant HSM pool
Key types supported	Symmetric (AES-256), RSA, elliptic curve (NIST and SEC curves), HMAC	RSA and elliptic curve only; no native symmetric encryption key type
Key portability	KMS keys cannot be exported; External Key Store (XKS) can keep key material outside AWS entirely	Keys can be imported (BYOK); External Key Management (preview) can proxy operations to an external HSM

Two terminology notes worth flagging: AWS retired the term “Customer Master Key (CMK)” years ago in favor of “KMS key,” so any documentation or blog post still using CMK is describing an outdated naming convention, not a different feature. And Azure’s software-protected Standard tier is still backed by shared HSMs behind the scenes; “software-protected” describes how Azure exposes the key operation, not that your key material sits in plain memory.

Should You Use Native Keys, BYOK, or HYOK on AWS and Azure?

Use native keys unless a specific compliance or contractual requirement forces external control; use BYOK when you need to bring existing key material into the cloud provider’s HSM; reserve HYOK for the narrow case where your keys must never be generated by, or persisted inside, the cloud provider at all.

Model	AWS	Azure
Native	AWS managed or customer managed KMS keys, generated and held inside KMS	Vault-generated keys in Standard, Premium, or Managed HSM
BYOK	Import external key material into a customer managed KMS key (key material still lives in AWS once imported)	Import key material via a secure transfer blob into Key Vault or Managed HSM
HYOK (key stays outside the cloud)	External Key Store (XKS): AWS proxies every cryptographic operation to your external key manager over a VPC endpoint; production-ready, but adds a hard external dependency for every KMS call	External Key Management (EKM): preview only, wrap and unwrap operations proxied to an external HSM, explicitly excluded from Azure’s SLA

The trade-off is the same shape on both clouds: HYOK gives you the strongest contractual story (“the cloud provider never held our keys”), but it also means every encrypt or decrypt call now depends on the availability of your external key manager. Most teams we work with land on customer managed native keys, plus BYOK for keys that already exist elsewhere, and reserve true HYOK for regulatory mandates that specifically require it.

How Does the IAM Model Differ Between AWS KMS and Azure Key Vault?

AWS KMS layers a resource-level key policy underneath standard IAM policies, so two separate documents have to agree before a call succeeds; Azure Key Vault applies access at the vault or key level through either legacy access policies or Azure RBAC, so permissions in Azure are usually easier to audit but coarser to scope.

• AWS KMS: every KMS key has its own resource-based key policy, which is the root of trust for that key, and IAM identity policies can grant additional permissions only within what the key policy allows. Grants add temporary, revocable permissions for specific principals, commonly used for cross-account access.
• Azure Key Vault: vault access policies (legacy) or Azure RBAC role assignments (recommended) control who can manage or use keys. Managed HSM uses its own local RBAC model, separate from the rest of Azure RBAC, which teams migrating from Key Vault Premium to Managed HSM should plan for explicitly.

A practical least-privilege rollout looks similar on both clouds:

1. Inventory every principal (user, role, service) that currently touches key material, on either cloud.
2. Replace any wildcard key or vault permissions with scoped grants tied to a specific KMS key ARN or Key Vault resource ID.
3. Separate key administration (create, rotate, delete) from key usage (encrypt, decrypt, sign) so no single role can do both.
4. Enable cross-account or cross-tenant access only through explicit grants (AWS) or role assignments scoped to the calling identity (Azure), never through broad account trust.
5. Review key policies and RBAC assignments on a fixed cadence, not just at provisioning time, since permissions drift is the most common audit finding we see in cloud key management reviews.

How Does Key Rotation Work in AWS KMS vs Azure Key Vault?

AWS KMS automates rotation for you once you turn it on; Azure Key Vault gives you more granular control over the rotation interval, but you have to design and monitor the policy yourself.

• AWS KMS: automatic rotation is available for customer managed symmetric encryption keys with AWS_KMS origin, on a configurable cycle from 90 to 2,560 days (365 days by default). Asymmetric and HMAC KMS keys cannot rotate automatically and must be rotated manually by creating a new key and updating references. Keys with imported key material (EXTERNAL origin) support on-demand rotation instead of automatic rotation.
• Azure Key Vault: rotation policies can be set as short as 7 days from key creation or from the key’s expiration time, and can trigger either on a fixed schedule or a percentage of the key’s lifetime remaining. Both the old and new key versions stay enabled through rotation so data encrypted under the previous version keeps decrypting, and Azure does not automatically prune old versions, so version growth needs to be managed as part of the rotation policy.

What Should You Log and Monitor in AWS KMS and Azure Key Vault?

Every KMS API call is logged in AWS CloudTrail by default as a management event; every Key Vault operation is only logged in Azure Monitor once you explicitly turn on diagnostic settings, which is the single most common logging gap we find in Azure key management audits.

• AWS: CloudTrail records every KMS API call (Encrypt, Decrypt, GenerateDataKey, and so on) with the calling principal, source IP, and key ARN, on by default for management events. Route these logs to CloudWatch or a SIEM and alert on unexpected Decrypt calls, key deletions, or policy changes.
• Azure: Key Vault emits an AuditEvent log category through Azure Monitor diagnostic settings, which is not enabled by default and must be configured per vault. Once enabled, route logs to a Log Analytics workspace or SIEM and alert on the same categories: unexpected key use, key or vault deletion, and access policy or RBAC changes.

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

AWS KMS pricing is simple and flat per key; Azure Key Vault pricing depends heavily on which tier you choose, and Managed HSM in particular uses a different, pool-based billing model rather than per-key pricing.

Service	Approximate pricing model
AWS KMS	$1 per customer managed key per month (prorated), plus $0.03 per 10,000 API requests beyond the 20,000 free requests per month
Azure Key Vault Standard	No per-key fee; approximately $0.03 per 10,000 operations on software-protected keys and secrets
Azure Key Vault Premium	Approximately $1 per HSM-protected RSA 2048 key per month plus per-operation charges, with higher per-key pricing for RSA 3072/4096 and ECC keys
Azure Managed HSM	Billed per HSM pool per hour rather than per key, commonly cited around $3 to $3.20 per hour for the standard tier regardless of usage volume

Treat the Azure figures above as directional. Azure’s official pricing page loads region- and currency-specific rates dynamically, so confirm current pricing for your region before budgeting, especially for Managed HSM, where the flat hourly pool fee can make it more expensive than Premium for teams managing only a handful of keys.

What If You Add Google Cloud Later? A Note on Multi-Cloud Key Management

If a third cloud joins the stack, the AWS-versus-Azure comparison in this post becomes one input into a larger decision, not a decision you have to redo from scratch.

Teams that expect to add GCP Cloud KMS, or already run all three clouds, should read our pillar comparison, AWS KMS vs. Azure Key Vault vs. GCP KMS, which extends every comparison in this post (native storage, BYOK/HYOK, IAM, rotation, logging, cost) across all three providers. For architecture patterns that centralize key management across clouds rather than running three separate native services side by side, see our multi-cloud PKI-as-a-Service architecture guide and the Education Center’s overview of multi-cloud key management.

What Are the Limitations of AWS KMS and Azure Key Vault?

• AWS KMS: no automatic rotation for asymmetric or HMAC keys; External Key Store adds a hard dependency on external infrastructure for every cryptographic call; KMS keys can never be exported once created inside AWS (only XKS keeps material outside AWS).
• Azure Key Vault: no native symmetric encryption key type; Managed HSM’s local RBAC model is separate from standard Azure RBAC, adding a second permissions model to maintain; External Key Management is preview only, with no SLA, and diagnostic logging is opt-in rather than on by default.

Decision Checklist: AWS KMS or Azure Key Vault?

1. Identify which cloud already holds the workload; default to that cloud’s native service unless a specific requirement says otherwise.
2. Confirm your compliance requirement’s actual HSM validation level (FIPS 140-2 Level 2, FIPS 140-3 Level 3, or Common Criteria) and match it to the right Azure tier or confirm AWS KMS already meets it by default.
3. Decide whether you need symmetric encryption keys (only AWS KMS supports these natively) or can work entirely with RSA/ECC.
4. Map out who administers keys versus who uses them, and design the IAM policy or RBAC role split before provisioning, not after.
5. If a true HYOK requirement exists, confirm whether your compliance mandate can accept AWS External Key Store’s production status or genuinely requires Azure’s preview-stage External Key Management, since the SLA gap is not cosmetic.

What Would Encryption Consulting Recommend?

For most two-cloud teams, we recommend starting with each provider’s native key management service, customer managed KMS keys on AWS and RBAC-governed Key Vault (Premium, if HSM backing is required) on Azure, rather than introducing a third-party key manager on day one. The complexity that actually causes incidents is usually inconsistent IAM design and unmonitored logging, not the choice of native service itself. Where we do see teams benefit from centralizing control is once key volume, audit scope, or a genuine HYOK requirement makes managing two separate native consoles impractical; at that point, a managed layer like HSM-as-a-Service or a broader cloud data protection engagement can give you one control plane, one rotation policy, and one audit trail across both clouds instead of two of everything.

Frequently Asked Questions

Is a “Customer Master Key (CMK)” the same thing as a KMS key?

Yes. AWS renamed Customer Master Key to “KMS key” in its documentation and console; any reference to a CMK today describes the same resource type under its older name, not a deprecated feature.

Can Azure Key Vault store symmetric encryption keys like AWS KMS?

No. Azure Key Vault natively supports RSA and elliptic curve keys only. Teams that need symmetric key management on Azure typically generate and wrap symmetric data keys in application code using an RSA or EC key held in Key Vault, rather than storing the symmetric key type directly.

Is HYOK actually available on Azure today?

Only in preview. Azure’s External Key Management feature proxies wrap and unwrap operations to an external HSM, but Microsoft explicitly excludes it from Azure’s standard SLA while it remains in preview, so it is not yet a production-grade substitute for AWS External Key Store.

Can we migrate keys directly between AWS KMS and Azure Key Vault?

Not directly, and not at all for AWS KMS keys created inside AWS, since KMS keys can never be exported. Key material you originally generated yourself and imported into one cloud (BYOK) can, in principle, also be imported into the other, but this requires you to retain and manage that original key material outside both clouds, which is exactly the operational burden most teams use native keys to avoid.

Is Azure Key Vault activity logged by default the way AWS CloudTrail logs KMS calls?

No. AWS CloudTrail logs KMS API calls automatically as management events. Azure Key Vault’s AuditEvent logs require you to explicitly configure a diagnostic setting on each vault; until you do, key and secret operations against that vault are not being captured.

Have a specific AWS-to-Azure key management migration or IAM design question? Reach our team at [email protected].