Vault or your cloud's secret manager

The two failures look nothing alike and cost about the same. The first is a five-person platform team running a three-node Vault cluster, with Raft storage, auto-unseal, a Consul cluster nobody remembers why they deployed, and an upgrade backlog eleven minor versions deep — to hold ninety static secrets that never change. The second is a company that went all-in on AWS Secrets Manager, then acquired a business running on Azure and a factory floor of on-premise services, and now has three secret stores, three access models and no single audit trail.

Both teams asked "which product is better". That question has no answer. There are four questions that do.

The four questions that decide it

Are you genuinely multi-cloud, or do you just say you are? Genuinely means production workloads in two or more clouds that need the same secret, or an acquisition roadmap that will produce that within a year. If everything runs in one cloud and will keep doing so, the managed secret manager wins on operational cost alone and it is not close.

Do you need dynamic, short-lived credentials? Not "would they be nice". Do you have databases where a compromised long-lived password is a serious incident, and can your applications tolerate a credential that expires? This is the single strongest argument for Vault and we come back to it below.

Do you have workloads outside any cloud? Bare metal, factory equipment, developer laptops, a colocation rack, CI runners you host. Cloud secret managers can serve these, but the authentication story gets awkward fast: you end up with a long-lived cloud credential on the box to fetch the secrets, which is the problem you were trying to solve. Vault's auth methods (Kubernetes, JWT, TLS certificates, AppRole) were designed for exactly this.

Who runs it at 3am? Vault is a stateful distributed system holding the keys to everything. That is a real on-call surface. If your platform team is three people who also own the Kubernetes clusters and the CI, adding Vault is a decision about their next two years, not about a product comparison.

What running Vault actually costs you

The install is an afternoon. The operation is permanent.

Sealing and unsealing. A restarted Vault comes up sealed and serves nothing until it is unsealed. Shamir key shares held by five humans is a lovely security model and a terrible availability model at 3am. In practice everyone uses auto-unseal backed by a cloud KMS, which is correct — and which means your "cloud-independent" secret store now has a hard dependency on a cloud KMS key. Guard that key with a deletion protection policy and replicate it if your provider allows, because losing it loses the vault.

High availability and storage. Integrated Raft storage removed the Consul dependency, which was the biggest operational improvement Vault has had. You still run an odd number of nodes across availability zones, you still take and test backups of the Raft snapshot, and you still need to know how to recover a lost quorum before you need to know it.

Upgrades. Vault ships frequently and the version skew between your cluster and your client libraries matters. Teams that fall behind stay behind, because the upgrade becomes scary in proportion to how long it has been.

Policy sprawl. Vault's policy language is powerful and ungoverned by default. Without a review process, you get a * path in a policy within six months.

Budget one engineer at somewhere between a fifth and half of their time to run this properly, plus the enterprise licence if you need namespaces, replication or HSM support. That number is the honest comparison point, not the software cost.

What managed costs you, and where it surprises people

The managed services all price on roughly two axes: a monthly charge per stored secret, and a charge per API call. Both are small numbers. Neither is small at scale.

The per-secret charge catches teams who generate secrets programmatically: one credential per tenant, per environment, per short-lived preview deployment. Ten thousand secrets at a per-secret monthly rate is a line item somebody will ask about. The per-call charge catches teams whose applications fetch secrets on every request rather than caching them, and whose Kubernetes CSI driver re-reads on a tight interval. Check the current pricing pages before you model this, because the rates and the free tiers change, but do model it — the failure mode is that nobody notices until the bill arrives.

The other cost is portability. Secrets themselves move easily; what does not move is everything wired around them. IAM policies granting access, resource policies, the automatic rotation Lambda or Function, the KMS key that encrypts them, the CSI driver configuration, the references embedded in a hundred task definitions. Migrating out is a quarter of work, not a weekend.

Dynamic database credentials are the real argument

Everything above is a trade. This is the capability with no managed equivalent that works the same way.

Vault's database secrets engine holds one privileged credential, and when an application authenticates, Vault creates a brand new database user with a defined TTL, hands it over, and drops it when the lease expires. Every application instance gets a distinct credential. Nothing long-lived exists to steal, nothing needs rotating, and the audit log tells you which identity requested which credential at which time. Revoking access to a compromised workload is a lease revocation, not a password change and a coordinated restart.

The same pattern exists for cloud credentials, SSH, PKI certificates and messaging systems. The PKI engine in particular is how a lot of organisations end up with short-lived internal TLS certificates without buying a separate product.

The catch is that your application must be able to reconnect with a new credential when the lease rotates, and your database must tolerate the user churn. Connection-pool libraries that read the password once at startup will break, and finding out which of your services do that is the actual migration work.

What people forget

• The secret manager is not the boundary; IAM is. A perfectly encrypted secret readable by a role that half the estate can assume is not protected. Scope read access per workload and check what actually reads it.
• Audit logs need a destination. Vault refuses to serve requests if it cannot write its audit log, which is correct behaviour and a surprising outage the first time the disk fills. Ship them off the box.
• Break-glass access. Write down, and test, how you get a secret out when the identity provider or the cluster is down. If the answer is "we cannot", that is your next incident.
• Applications fetching secrets need an identity first. Solve that with OIDC federation in CI and workload identity in the cluster, not with a bootstrap password in an environment variable.
• A secret store does not rotate anything by itself. That is a separate programme of work and it is where most of the value is; see rotation that actually works.

The answer we deploy most often

For a single-cloud estate with mostly static secrets: the managed service, with per-workload IAM, CMK encryption and replication configured. Do not build a platform to avoid a problem you do not have.

For a multi-cloud or hybrid estate, or one where database credential compromise is a top risk: Vault, run properly, with the managed services still used as the trust anchor for auto-unseal. We size the operational commitment honestly during the security engagement before anyone installs anything.

What to do this week

Count your secrets and classify each one as static, rotatable or dynamic-capable. Export the list from whatever store you use today, tag each entry, and total the dynamic-capable column. If it is near zero, Vault's strongest argument does not apply to you and the decision just got easy.