AWS Secrets Manager vs HashiCorp Vault: NHI cost and governance

At a glance

What this is: This comparison contrasts AWS Secrets Manager and HashiCorp Vault on cost, operating model, and NHI lifecycle control, concluding that the trade-off is managed simplicity versus dynamic credential governance.

Why it matters: It matters because IAM, IGA, and PAM teams need to decide whether secrets should be stored, rotated, or issued on demand, and that choice changes ownership, auditability, and blast radius.

By the numbers:

• AWS Secrets Manager is billed at $0.40 per secret each month, which makes cost rise linearly with secret count.
• HashiCorp Vault's break-even with AWS Secrets Manager typically lands between roughly 3,000 and 8,000 secrets.

👉 Read Akeyless's analysis of AWS Secrets Manager vs HashiCorp Vault for NHI cost and governance

Context

AWS Secrets Manager and HashiCorp Vault solve the same basic problem, but they do not govern non-human identities in the same way. One stores static secrets inside AWS with minimal operational burden, while the other issues dynamic credentials and shifts lifecycle responsibility to the team that runs it.

The governance question is not just cost. It is whether NHI programmes need managed storage for AWS-native workloads or a control plane that can issue, expire, and revoke credentials across clouds and runtimes without locking identity policy to one provider.

That distinction becomes material as secret count grows and as estates spread across more than one cloud. In that environment, lifecycle control and operational ownership matter as much as storage location.

Key questions

Q: What breaks when teams store reusable secrets outside a governed lifecycle?

A: What breaks is not only confidentiality but also revocation, auditability, and ownership. Secrets that live in files, CI/CD tools, or unmanaged vaults can outlast the workload, the team, or the cloud they were created for. That makes response slower and turns every leak into a long tail problem instead of a contained event.

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.

Q: What are the signs that a secrets platform is becoming too expensive to run?

A: The warning signs are rising engineer time, repeated unseal or upgrade work, expanding monitoring effort, and growing exception handling across clouds or environments. If the operating team spends more time keeping the platform available than using it to reduce risk, the platform is no longer behaving like a control.

Q: How should security teams replace shared secrets for workloads that span multiple clouds?

A: Use federated workload identity so the workload proves who it is with a signed token or attestation instead of a shared static secret. Then scope the resulting credential tightly to the request and make the trust relationship revocable when the workload, supplier, or environment changes.

Technical breakdown

Static secret storage versus dynamic credential issuance

AWS Secrets Manager stores credentials and can rotate them on a schedule, which shortens exposure but does not change the underlying model: the secret remains a reusable value until the next rotation. Vault works differently. It can mint credentials on demand, bind them to a lease, and revoke them automatically when the lease expires. That is a material shift for NHI governance because the credential no longer has to be treated as a durable artifact. Instead, access becomes a time-bound event tied to the requesting workload and its policy context. The operational consequence is that the control point moves from periodic rotation to issuance and revocation.

Practical implication: Treat rotation and issuance as different controls, and choose the model that matches whether your NHI risk is credential persistence or lifecycle governance.

Why the secret zero problem changes the operating model

A managed service such as Secrets Manager can rely on AWS IAM roles that workloads already have, so the bootstrap path is relatively simple. Vault must solve secret zero itself through its own authentication methods and, in many deployments, through an unseal workflow. That difference matters because the operational burden is not just maintenance overhead. It also defines who owns trust establishment at startup, which is central to NHI governance. The more the environment depends on cross-cloud or on-prem workloads, the more that bootstrap question becomes part of the access model rather than an implementation detail.

Practical implication: Map how each workload proves identity at startup before choosing a secrets platform, because bootstrap design is part of the security boundary.

Why multi-cloud estates push teams toward governed lifecycle control

Vault's cloud-agnostic model is built for estates that do not want separate secrets silos in each provider. AWS Secrets Manager can extend beyond AWS, but it is still fundamentally an AWS service, not a cross-cloud control plane. That architectural difference becomes important when a programme is trying to avoid secret sprawl. If each cloud gets its own native store, governance fragments. If one platform can issue and revoke across environments, policy is easier to standardise, but only if the team can run the platform properly. The issue is therefore not portability alone, but whether portability is being achieved through consistent governance or through distributed exception handling.

Practical implication: Use one governance model for all clouds only when the platform can actually enforce it across environments, not when it merely copies secrets between them.

Threat narrative

Attacker objective: The attacker aims to reuse durable credentials long enough to access workloads or cloud resources beyond the intended request window.

1. Entry occurs when a workload or service consumes a reusable secret that has been stored for later use rather than issued just in time.
2. Escalation happens when that secret is valid across multiple calls or environments until the next rotation cycle or manual change.
3. Impact follows when the same credential can be reused long enough to support unauthorised access, lateral movement, or secret reuse across cloud boundaries.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static secret sprawl is a governance problem, not just a storage problem: The comparison only looks like a billing debate until teams account for how many secrets sit outside governed systems. When credentials live in files, pipelines, or ad hoc stores, the real cost is fragmented lifecycle control and unclear ownership. The practical conclusion is that storage location matters less than whether the credential estate can be governed end to end.

Ephemeral credential issuance changes the security unit from secret to session: Vault's model is materially different because the value being governed is no longer a long-lived secret but a lease with expiry and revocation. That changes how teams think about exposure, audit, and blast radius. The practitioner implication is that controls must focus on issuance policy and revocation semantics, not only on vaulting.

Secret zero is the hidden design decision in every cross-cloud programme: A managed AWS service can rely on native IAM trust, while a self-operated platform has to establish and maintain its own bootstrap trust. That assumption breaks the moment workloads span clouds, runtimes, or ownership domains. The implication is that identity governance must include startup trust, not just steady-state access.

Cross-cloud governance creates an identity blast radius problem: Once secrets are replicated across AWS, Azure, GCP, and on-prem systems, the estate stops behaving like a single control domain. That makes audit evidence, revocation speed, and exception handling the deciding factors. Practitioners should treat secret distribution as a blast-radius decision, not a convenience feature.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Buyer's Guide

What this signals

Secret sprawl becomes expensive when it is treated as an implementation detail: Governance teams should assume that every additional vault, region, or cloud copy creates another revocation surface and another audit boundary. The operating question is not whether a secret can be stored, but whether it can be governed consistently after it is copied.

Lifecycle control, not storage density, is the better control objective: Dynamic issuance reduces the time a credential remains usable, while static storage only shortens that window if rotation is reliably enforced. In practice, teams should move the control discussion to issuance time and revocation semantics rather than continue to optimise around where the secret sits.

67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey. That is a useful warning for NHI programmes as well, because the same long-lived credential pattern weakens cloud governance long before any AI-specific use case appears.

For practitioners

• Define the credential lifecycle by workload type Separate static application secrets from dynamically issued workload credentials, because each requires a different ownership model, rotation policy, and audit trail.
• Measure the real cost of operating Vault Include engineer time, infrastructure, monitoring, and unseal operations when comparing Vault against managed storage, not just license cost.
• Map bootstrap trust for every non-human identity Document how each workload authenticates before it can retrieve or mint a secret, especially where AWS IAM, Kubernetes service accounts, or certificates are involved.
• Treat multi-cloud replication as a governance decision Review whether copying secrets across regions or clouds reduces risk, or simply multiplies the places where a compromise must be contained and revoked.

Key takeaways

• AWS Secrets Manager and Vault solve the same problem through different governance models, not just different price points.
• The decisive trade-off is whether the organisation wants managed AWS storage or dynamic, cross-cloud credential control.
• At scale, the real cost comparison includes engineering time, revocation speed, and the blast radius created by replicated secrets.

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.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• A side-by-side cost model with assumptions for secret count, engineer time, and infrastructure overhead
• The full comparison table covering deployment, authentication, secret zero, and rotation mechanics
• Discussion of Vault 2.0 and the IBM ownership shift as it affects product direction and support
• Worked examples showing where the cost crossover lands in real environments

👉 The full Akeyless article includes the cost crossover analysis, deployment trade-offs, and Vault 2.0 context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.