AWS Secrets Manager vs HashiCorp Vault: NHI cost and governance

At a glance

What this is: This is a comparison of AWS Secrets Manager and HashiCorp Vault that finds cost and operating model diverge sharply as secret volume and cloud scope increase.

Why it matters: It matters because IAM, NHI, and platform teams must decide whether they are buying managed storage, dynamic credential issuance, or a broader lifecycle control plane.

By the numbers:

• At $0.40 per secret each month, AWS Secrets Manager costs $4.80 per secret per year before API calls.
• Akeyless says the break-even between AWS Secrets Manager and Vault typically lands between roughly 3,000 and 8,000 secrets.
• Vault’s comparison cost model includes 10% to 20% of one senior engineer’s time in many deployments.

👉 Read Akeyless's comparison of AWS Secrets Manager and HashiCorp Vault

Context

AWS Secrets Manager and HashiCorp Vault solve the same broad problem, but they govern secrets in very different ways. One is a managed service with tight AWS integration and per-secret pricing. The other is a platform you operate to issue short-lived credentials and support multi-cloud identity patterns.

For NHI practitioners, that difference affects far more than tooling preference. It changes whether the organisation is optimising for low operational burden, dynamic credentialing, or cross-cloud lifecycle control across service accounts, API keys, and workload identities.

The comparison is also a useful reminder that secret management is not the same as secrets governance. A tool can store or rotate credentials without giving you lifecycle visibility, offboarding discipline, or a single policy model across environments.

Key questions

Q: What should teams do first when AWS Secrets Manager and Vault seem to overlap?

A: Start by deciding whether the problem is secret storage, secret rotation, or short-lived credential issuance. If the requirement is dynamic access across clouds, compare against a lifecycle control plane. If the requirement is mainly AWS-native storage with minimal overhead, the managed service is usually the cleaner fit.

Q: Why do static secrets and lease-based credentials create different risk profiles?

A: Static secrets remain usable until they are rotated or revoked, which leaves a longer replay window if they leak. Lease-based credentials expire automatically, so the attacker’s usable window is narrower. That makes them better for task-scoped access, but only if the workload can tolerate ephemeral authentication.

Q: What are the signs that a secret-management model is failing at scale?

A: Common signals include duplicated secrets across clouds, secret copies in code or CI systems, unclear ownership of rotation, and a growing mismatch between how long a credential exists and how long the task actually needs it. When those appear together, the model is drifting from governance into storage only.

Q: Should organisations prioritise dynamic secrets over managed storage?

A: Prioritise dynamic secrets when credential lifetime is the main risk and the workload can authenticate without a permanent shared secret. Prioritise managed storage when the estate is mostly single-cloud and the operating burden of self-managed platforms would create more risk than the credential lifetime you are trying to reduce.

Technical breakdown

Managed secrets storage versus operated credential infrastructure

AWS Secrets Manager is a regional managed service. It stores secrets encrypted with KMS, applies IAM for access control, and can rotate supported database credentials through Lambda. Vault is different in kind: it is a system you deploy, unseal, scale, and observe, with its own storage backend and control plane. That distinction matters because the operational burden is part of the security model, not separate from it. Managed services reduce toil, but they also narrow architectural flexibility. Operated platforms expand control, but they demand governance maturity and staff capacity.

Practical implication: Treat deployment model as an identity-governance decision, not just an infrastructure choice.

Dynamic secrets and lease-based expiry

Vault’s defining capability is that it issues credentials on demand with a lease and time to live, then revokes them when the lease ends. That is materially different from rotating a static secret on a schedule, because the credential’s useful life is measured in minutes or hours rather than weeks or months. AWS Secrets Manager can shorten exposure windows through rotation, but the underlying secret still exists between cycles. This is why dynamic secrets change the trust model: the credential is tied to the session or task, not merely to a storage location.

Practical implication: Use lease-based credentials where the workload can tolerate ephemeral access and the blast radius matters.

Cross-cloud identity scope and secret zero

Vault is cloud-agnostic by design and can authenticate workloads across AWS, Azure, GCP, Kubernetes, and on-prem. AWS Secrets Manager can extend beyond AWS through IAM Roles Anywhere, but that is not the same as operating a cross-cloud secrets governance plane. Vault also has to solve secret zero and unsealing, which are governance and bootstrap problems in their own right. In practice, the architecture choice determines whether the team is managing one cloud-native secret store or a federated access pattern across multiple platforms.

Practical implication: Map the credential source of truth before standardising on a single secret-management model.

Threat narrative

Attacker objective: The attacker wants durable access through a credential that outlives the task or workload it was meant to protect.

1. Entry occurs when long-lived or stored secrets are reused across workloads, regions, or cloud environments and become the point of compromise.
2. Escalation follows when the same credential is accessible across multiple applications or remains valid long after it should have been revoked.
3. Impact is wider compromise, because a leaked secret can be replayed until rotation or revocation finally breaks the attacker’s access.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud-native secret storage and dynamic credential issuance are not interchangeable controls. AWS Secrets Manager is optimised for managed storage and rotation inside AWS, while Vault is optimised for short-lived credential issuance across environments. The governance distinction is that one controls secret residence and the other controls credential lifetime. Teams that treat them as equivalent often end up with a storage decision when they really need a lifecycle decision.

Static rotation does not solve the same problem as lease-based access. A rotated secret can still be copied, replayed, or shared between applications until the next cycle. Lease-based credentials narrow the window of misuse by tying access to a task and an expiry. For NHI governance, that difference is the line between reducing exposure and actually constraining identity persistence.

Secret zero becomes a governance issue the moment the estate stops being single-cloud. Vault has to solve bootstrap trust, unsealing, and authentication methods explicitly, while AWS can rely on its native identity fabric inside one ecosystem. Once the organisation spans multiple clouds, the question is no longer just where secrets live but which platform owns the policy model across those environments.

Dynamic secrets across clouds still require an operating model, not just a product choice. The comparison exposes a common blind spot: teams often buy a tool to avoid running infrastructure, then rediscover that credential lifecycle, auditability, and workload onboarding still need governance. The practical conclusion is that cross-cloud identity control has to be designed as a programme, not procured as a feature.

Ephemeral credential trust debt: the article shows that teams inherit a new form of risk when they rely on short-lived credentials without lifecycle discipline, because expiry alone does not guarantee revocation, visibility, or accountability. That concept matters for practitioners deciding whether they want short-lived access or a real identity control plane.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams are governing access without complete inventory.
• A practical next step is to pair that visibility gap with the NHI Lifecycle Management Guide so rotation, offboarding, and review are treated as one lifecycle.

What this signals

Ephemeral Credential Trust Debt: when teams adopt dynamic secrets without lifecycle discipline, they reduce one exposure window while creating another: the assumption that expiry alone equals control. The better operating model is to align secret issuance, revocation, and ownership so the credential lifecycle matches the workload lifecycle, not the other way around.

The market is moving toward identity controls that span cloud, workload, and secret lifecycle boundaries rather than isolated vaults. For practitioners, that means secret stores will be judged less on where they keep data and more on whether they support coherent policy, revocation, and audit across the estate.

With 91.6% of secrets still valid five days after notification in our research, the real problem is often not detection but remediation speed. That makes governance over offboarding, revocation, and ownership the control plane that matters most when secret sprawl grows.

For practitioners

• Define the governance goal before choosing the tool Separate managed secret storage, dynamic credential issuance, and cross-cloud policy control into different requirements so the architecture matches the risk. If the real need is short-lived access across clouds, a per-secret storage service is not the right proxy.
• Model total cost against secret count and engineer time Run the numbers using your real secret inventory, not a tidy sample, and include the human cost of operating Vault or any equivalent platform. Compare that with the per-secret and per-replica cost of the managed service before you commit.
• Inventory where static secrets still persist Locate credentials stored in code, config, CI systems, and other non-vault locations, then map which of those workloads could move to lease-based credentials. That is the quickest way to see where rotation is masking a lifecycle problem.
• Standardise the bootstrap identity path Document how each workload authenticates before it ever reaches the secret store, including IAM roles, certificates, or workload identity. If secret zero is different in every environment, governance will fragment as the estate grows.

Key takeaways

• AWS Secrets Manager and Vault solve different governance problems, so a direct feature comparison can hide the real decision.
• The economics turn on secret count, but the security outcome turns on whether you need static storage or short-lived, cross-cloud access.
• Teams that do not govern secret lifecycle, bootstrap identity, and revocation together will keep buying tools to compensate for a missing control plane.

Key terms

• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Lease: A lease is the time window during which a generated credential remains valid. For workload identities, lease design is a security control and an availability control at the same time, because overly long leases extend risk while overly short ones can break automation.
• Multi-Cloud Secrets Governance: The policy model that governs how secrets, tokens, and workload credentials are issued, rotated, revoked, and audited across more than one cloud. It matters because separate stores in separate clouds quickly become separate trust models, which fragments accountability.

What's in the full article

Akeyless's full comparison covers the operational detail this post intentionally leaves for the source:

• Pricing examples across secret counts, regions, and replica scenarios that help you test your own cost model.
• Deployment and maintenance implications for teams choosing between managed storage and self-operated infrastructure.
• Capability-by-capability differences in dynamic secrets, rotation, multi-cloud reach, and operational burden.
• What changes in practice when Vault sits under IBM and how that affects product direction and lifecycle decisions.

👉 Akeyless's full article breaks down pricing, deployment burden, and dynamic secret tradeoffs in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.