Secrets Management: Vault vs AWS Secrets Manager vs Azure Key Vault

Beyond simply storing a value encrypted at rest, a secrets management platform earns its place in the architecture by handling the parts that are hard to get right by hand: fine-grained access control tied to workload identity (not a shared static credential to reach the secrets manager itself), automatic rotation so a leaked credential has a limited useful lifetime, audit logging of every access, and — ideally — dynamic secret generation, where the platform issues a short-lived credential to a downstream system (a database, a cloud provider) on demand rather than storing one long-lived value.

Vault is the most capable and most operationally involved of the three. It's self-hosted (or available as a managed HCP Vault offering) and cloud-agnostic by design, with secrets engines that go well beyond static key-value storage — dynamic database credentials generated per-request and automatically revoked, short-lived cloud provider credentials (AWS/Azure/GCP), a built-in PKI engine for issuing TLS certificates, and Transit encryption-as-a-service for applications that need encryption without managing their own keys.

Vault's authentication model is also broader: it supports Kubernetes service account tokens, cloud IAM identity, LDAP, and other auth methods as ways for a workload to prove its identity before receiving a secret, rather than requiring a static Vault token be distributed out-of-band. The trade-off is operational: Vault is infrastructure you run (unseal process, storage backend, high availability configuration, upgrade cadence) unless using the managed HCP offering, and its policy language (HCL-based Vault policies) has a learning curve.

AWS Secrets Manager is a fully managed service tightly integrated with the rest of AWS: access is controlled through standard IAM policies, secrets are encrypted with KMS, and it has native rotation integration for RDS, DocumentDB, and Redshift where AWS provides pre-built Lambda rotation functions. For other secret types, rotation requires writing a custom Lambda function following AWS's rotation Lambda contract.

It's the natural default for a workload that's entirely on AWS and doesn't need Vault's dynamic-secrets or multi-cloud capability — there's no infrastructure to run, and IAM is already the access-control system the team knows. The trade-off is that it's AWS-only: a multi-cloud or hybrid environment needs either a per-cloud secrets manager (adding operational surface) or a cross-cloud platform like Vault.

Azure Key Vault occupies a similar position to AWS Secrets Manager within the Azure ecosystem, with one structural difference worth knowing: Key Vault is a combined service for secrets, encryption keys, and certificates, whereas AWS splits these across Secrets Manager, KMS, and ACM as separate services. Access is controlled through Azure RBAC or Key Vault access policies, and Managed Identities let Azure workloads (VMs, App Service, AKS pods via workload identity) authenticate to Key Vault without a stored credential.

Key Vault supports scheduled rotation policies for secrets it manages directly, and integrates with Azure services for certificate lifecycle management. Like AWS Secrets Manager, it does not offer Vault's breadth of dynamic secret engines for third-party systems out of the box.

The three platforms overlap heavily on core storage and access control but diverge most on dynamic secret issuance and multi-cloud reach.

The decision usually comes down to cloud footprint and appetite for operating infrastructure rather than any single missing feature. A single-cloud team with straightforward secret storage and rotation needs is generally well served by that cloud's native service — less to build, less to patch, and IAM/RBAC integration comes for free. A multi-cloud or hybrid environment, or one that specifically needs dynamic, short-lived credentials issued per-request (particularly for databases or for reducing the blast radius of long-lived cloud credentials), is where Vault's additional capability and operational cost start to pay for themselves.

These aren't mutually exclusive in practice — it's common to see Vault used for dynamic database and cross-cloud credentials while application configuration secrets sit in the native cloud service for simplicity. Whichever combination is chosen, the same fundamentals matter everywhere: no static long-lived credentials in source control or environment files, workload identity (not shared static credentials) used to authenticate to the secrets manager itself, and every access logged and monitored.

Moving from hardcoded or environment-variable secrets to a managed secrets store is usually incremental: introduce the secrets manager alongside existing practice, migrate the highest-risk credentials first (database passwords, third-party API keys, anything with broad access), and use the transition to also implement rotation rather than migrating static secrets as-is and rotating later.

• •Inventory existing secrets and where they currently live before migrating — config files, CI/CD variables, environment variables, and hardcoded values in code
• •Prioritise migrating secrets with the broadest blast radius first (production database credentials, cloud provider keys)
• •Use workload identity federation (IAM roles for service accounts, Managed Identity, Vault's Kubernetes auth method) so applications never hold a static credential to reach the secrets manager
• •Alert on secrets manager access patterns that deviate from baseline — a sudden bulk read of many secrets by one identity is a common exfiltration signature