Key Management in Multi-Cloud: HashiCorp Vault vs. AWS KMS vs. Azure Key Vault

A multi-cloud strategy means a fragmented key management problem. The encryption key protecting an S3 bucket lives in one HSM fleet under one access model; the key wrapping an Azure SQL database lives in another, with different audit semantics, different rotation primitives, and different IAM glue. Pick the wrong control plane and you inherit three separate compliance surfaces, three separate break-glass procedures, and three separate places where a misconfigured policy can lock you out of production data permanently.

The three platforms most teams evaluate — HashiCorp Vault, AWS Key Management Service (KMS), and Azure Key Vault — solve overlapping but materially different problems. Vault is a cross-cloud secrets and key broker built to span environments. AWS KMS is a deeply integrated cryptographic root of trust for AWS workloads. Azure Key Vault is the equivalent layer for Azure, with a separate Managed HSM tier for higher-assurance keys. Choosing among them — or, more often, choosing how to combine them — shapes the security posture of every encrypted resource you own.

What Each Service Actually Is

AWS KMS is a fully managed service that creates, stores, and uses cryptographic keys inside AWS-operated hardware security modules. The HSM fleet is now validated under FIPS 140-3 Security Level 3, with key material that never leaves the HSM unencrypted and is not written to disk. KMS is the encryption substrate underneath nearly every AWS service that supports encryption at rest — S3, EBS, RDS, DynamoDB, Lambda — using envelope encryption, where a per-resource data key is itself encrypted by a KMS key.

Azure Key Vault is Microsoft’s equivalent, but split across more tiers. The Standard tier protects keys with FIPS 140 Level 1 software cryptographic modules. The Premium tier introduces HSM-protected keys on shared, multi-tenant Marvell LiquidSecurity HSMs, now running FIPS 140-3 Level 3 validated firmware after a fleet upgrade. Azure Key Vault Managed HSM is a separate, single-tenant FIPS 140-3 Level 3 service for high-value keys — billed at a fixed hourly rate rather than per operation — where the customer controls the security domain and Microsoft provably cannot access key material.

HashiCorp Vault is a different category of tool. It does store and manage encryption keys, but its core value is identity-based brokerage of secrets across heterogeneous environments. Vault generates dynamic, short-lived database credentials, issues PKI certificates, signs SSH keys, performs encryption-as-a-service through its Transit engine, and authenticates workloads using each cloud’s native identity primitives — IAM in AWS, Managed Identity in Azure, service accounts in GCP. Vault 2.0, released in April 2026 under IBM’s versioning model after the $6.4B acquisition closed in February 2025, added Workload Identity Federation and SCIM 2.0 provisioning while continuing under the Business Source License (BSL 1.1) HashiCorp adopted in August 2023.

The category distinction matters: AWS KMS and Azure Key Vault are cryptographic infrastructure for their respective clouds. Vault is a policy and identity broker that can sit on top of either, or beside both.

The Multi-Cloud Architecture Question

In a single-cloud environment, KMS or Key Vault alone is usually sufficient. The cloud-native services are deeply integrated, the IAM model is consistent, and operational overhead is minimal. The interesting decision arrives the moment workloads span clouds.

There are three viable patterns. The first is federated native KMS: keep AWS keys in KMS, Azure keys in Key Vault, accept that there is no unified control plane, and stitch together audit logs from CloudTrail and Azure Monitor at the SIEM layer. This works for organizations whose workloads are cleanly partitioned by cloud and whose compliance teams can tolerate two policy models.

The second is Vault as the unified control plane: deploy Vault (self-hosted, or HCP Vault Dedicated as a managed offering) as the central authority for secrets and dynamic credentials across both clouds. Vault auto-unseals using AWS KMS or Azure Key Vault as the seal mechanism, brokers identity between clouds — a workload running in AWS can use its IAM identity to authenticate to Vault and receive a short-lived Azure credential — and provides a single audit log. The cloud KMS services in this pattern are reduced to providing the unseal key and, optionally, the HSM root of trust under Vault.

The third is hybrid with HYOK or BYOK: customer-generated keys are imported into the cloud KMS, or kept in an external HSM and reached through AWS KMS External Key Store (XKS), where every encryption operation is mediated by a customer-controlled proxy. This is the pattern for organizations whose compliance regime requires the encryption key to live outside the cloud boundary entirely.

Cryptographic Assurance and Compliance Floor

Compliance is often the constraint that narrows the options. Modern certifications matter:

AWS KMS HSMs are FIPS 140-3 Security Level 3 validated, with all cryptographic operations and key material strictly contained within that boundary. Azure Key Vault Premium and Managed HSM both now run FIPS 140-3 Level 3 validated firmware on Marvell LiquidSecurity HSMs after Microsoft’s fleet upgrade — earlier documentation referencing FIPS 140-2 Level 2 or Level 3 reflects the older platform. Standard tier Azure Key Vault remains at FIPS 140 Level 1, software-only.

HashiCorp Vault itself does not provide FIPS-validated cryptography in the open-source binary. Vault Enterprise can run in FIPS 140-2 mode using validated cryptographic libraries, and the underlying HSMs come from whichever backend Vault is configured against — typically AWS KMS, Azure Key Vault, a CloudHSM cluster, or a PKCS#11-compliant on-premises HSM. The compliance assurance for a Vault deployment is inherited from those substrates, not provided by Vault.

For workloads under PCI DSS, FedRAMP High, or banking regulations that mandate single-tenant HSMs, the practical paths narrow to Azure Managed HSM, AWS CloudHSM (often fronted by KMS via a custom key store), or a customer-owned HSM reached through AWS KMS External Key Store. The XKS specification was developed with input from Atos, Entrust, Fortanix, HashiCorp, Salesforce, Thales, and T-Systems, and supports a “kill switch” model where turning off the proxy halts new encrypt/decrypt operations.

Pricing — What You Actually Pay

The pricing models are not directly comparable because the services bill on different axes.

AWS KMS charges $1 per customer-managed key per month, with the same rate for symmetric, asymmetric, HMAC, multi-Region (each replica counts), imported, CloudHSM-backed, and XKS-backed keys. The first and second key rotations each add another $1/month; subsequent rotations are free. API requests are $0.03 per 10,000 for symmetric operations, with 20,000 free requests per month across regions. AWS-managed and AWS-owned keys are free to store but billed for API calls. CloudHSM clusters are separate, billed roughly $1.60 per HSM per hour — with two HSMs recommended for HA, that runs around $2,300/month before key charges.

Azure Key Vault Standard and Premium bill per operation against keys, secrets, and certificates, plus a monthly per-key charge for HSM-protected keys that have been used in the previous 30 days. Multiple key versions count separately if used. Azure Managed HSM breaks this model entirely — it bills at a fixed hourly rate per pool regardless of operation count, because each pool is three dedicated HSM partitions acting as one logical appliance.

HashiCorp Vault Community Edition is free as software, but the operational cost is real: production deployments need 3+ nodes, persistent storage, monitoring, and operator expertise to handle unsealing, upgrades, and Raft cluster recovery. HCP Vault Dedicated, the IBM-managed offering, was restructured after the acquisition. The Starter tier was discontinued in August 2025, HCP Vault Secrets was sunsetted with end-of-life on July 1, 2026, and the remaining tiers — Development, Essentials, Standard — bill hourly per cluster, with Essentials and Standard adding $72.92/month per authenticating client.

A multi-cloud team running Vault as a broker on top of cloud KMS unseal therefore pays for both layers: the Vault cluster (or HCP subscription) plus the underlying KMS keys used for unseal and any envelope encryption.

Feature Reference

Operational Pitfalls That Bite In Production

Vault unseal recovery. A self-hosted Vault cluster starts in a sealed state. Without auto-unseal configured against AWS KMS, GCP KMS, or Azure Key Vault, every restart requires a quorum of unseal key holders to enter Shamir secret shares. Teams skip auto-unseal during initial deployment and inherit a dependency on individuals being reachable at 3 a.m. Always configure auto-unseal in production.

KMS key deletion windows. AWS KMS schedules deletion with a configurable waiting period of 7 to 30 days. The default is 30; teams running tight cleanup automation sometimes shorten this without realizing that any data still encrypted under that key becomes permanently unrecoverable when deletion completes. Same risk in Azure Key Vault if soft-delete and purge protection aren’t enforced organization-wide.

Azure Managed HSM security domain loss. The customer owns the security domain, which is the root of trust. Lose the security domain file and the recovery quorum keys, and every key in the HSM pool is permanently irrecoverable — Microsoft cannot restore them. This is the design point, but it requires real custodial discipline.

XKS latency and availability. AWS KMS External Key Store routes every cryptographic operation through a customer-managed proxy to a customer-managed HSM. Latency above roughly 250ms causes KMS operations to fail. Because services like EBS, S3, Lambda, and RDS depend on KMS for normal operation, an XKS proxy outage can cascade into a full-cloud outage for the workloads that depend on those keys.

Vault license uncertainty. The August 2023 BSL switch and IBM’s February 2025 acquisition have shifted the calculus for organizations that adopted Vault under MPL 2.0. The license permits commercial internal use; it restricts building competing managed Vault services. The product roadmap is now driven by IBM’s hybrid cloud strategy, with HCP Vault Secrets sunsetted and the Starter tier discontinued. Teams committing to Vault today should commit knowing the steward has changed.

FAQ

Can you use Vault and cloud KMS together? Yes — this is the most common multi-cloud production pattern. Vault uses cloud KMS for auto-unseal and optionally as the seal mechanism for its own storage encryption, while serving as the policy and identity broker layer above. The cloud KMS provides the FIPS-validated HSM root; Vault provides dynamic secrets, PKI, and cross-cloud identity translation.

Is AWS KMS sufficient for FedRAMP High workloads? For workloads requiring FedRAMP High, AWS KMS in GovCloud regions is authorized, and the FIPS 140-3 Level 3 HSM validation meets the cryptographic floor. Single-tenant requirements typically push toward AWS CloudHSM via a custom key store rather than the default multi-tenant KMS HSM fleet.

What happens to existing HashiCorp Vault deployments under IBM? The Vault binary continues to ship under BSL 1.1. Vault 2.0 marked the move to IBM’s versioning and support model, with new features including Workload Identity Federation and SCIM 2.0. Existing deployments are unaffected technically; the strategic question is whether the IBM roadmap aligns with your organization’s direction.

How do you handle key rotation across all three? AWS KMS supports automatic annual rotation for symmetric keys with no application changes required — older versions stay available to decrypt prior ciphertext. Azure Key Vault supports auto-rotation with configurable policies. Vault’s Transit engine supports rotation as a first-class operation. The harder problem is rotating dynamic credentials and database passwords, which is where Vault’s dynamic secrets engines materially outperform static-credential rotation in either cloud KMS.

The Decision

The choice is rarely “one platform across all clouds.” For organizations whose workloads are genuinely multi-cloud and whose secrets management needs include dynamic database credentials, internal PKI, or identity brokering across cloud boundaries, Vault remains the only realistic unified control plane — typically deployed as HCP Vault Dedicated to avoid the operational tax, with AWS KMS or Azure Key Vault as the unseal mechanism and the FIPS-validated root of trust.

For AWS-native workloads with no multi-cloud ambition, AWS KMS is the right answer, with CloudHSM or XKS reserved for the narrow set of workloads whose compliance regime demands single-tenancy or external key custody. For Azure-native workloads, the equivalent is Azure Key Vault Premium for general use and Managed HSM for high-assurance keys — the FIPS 140-3 Level 3 firmware fleet upgrade closed the historical assurance gap with AWS KMS.

The pattern that fails consistently is treating multi-cloud key management as a tooling decision instead of an architecture decision. Pick the broker layer first, decide what you want centralized versus federated, and let that choice determine which combinations of KMS, Key Vault, and Vault you operate. The keys themselves are easy. The control plane is the hard part.