AWS Secrets Manager alternative: when OpenBao is the better fit
If your secrets live mostly in AWS, your team is comfortable with IAM, and nobody wants to run secrets servers, AWS Secrets Manager is usually the simpler choice, and a renewal or pricing review alone is not a reason to move. OpenBao becomes the better fit when the same applications run across several clouds and data centers, when you need dynamic database credentials instead of rotated static passwords, or when a policy requires that key material stay outside AWS. AWS Secrets Manager is priced per secret per month plus per 10,000 API calls, so a large number of secrets or a high read volume shifts the economics, and the reader should model both sides before deciding. Confirm with your own architects which workloads are expected to move off AWS within the next few years, since that changes the answer more than the current bill does.
AWS Secrets Manager integrates tightly with IAM, KMS, CloudTrail and managed rotation, and those controls are hard to replicate in a self-hosted tool without careful design. OpenBao, by contrast, documents auth methods that cover AppRole, JWT/OIDC, Kubernetes, LDAP, TLS certificates and others, so one instance can serve workloads in several environments. Its dynamic secrets engines issue short-lived credentials with leasing and revocation, which removes some of the rotation Lambda work that AWS users maintain. Before committing, check that your required auth methods and secrets engines are supported and confirm how unseal keys will be held, because OpenBao does not use AWS KMS auto-unseal by default in the way AWS-native workloads expect.
The decision turns on three questions: where the workloads run, how many secrets and API calls the platform must handle, and who will operate it. If most workloads stay in AWS and the team has no appetite for operating servers, a managed service keeps the operating burden low. If workloads are spread across clouds or on-premises, or the organization needs to control key material, OpenBao's self-hosted model fits, but it adds ongoing work for patching, high availability, backups and unseal procedures. Ask any implementation partner for a written scope that names the storage backend, the number of nodes and the owner of each operational task, and compare that against the staff time your team can actually commit.
Which option fits which scenario
This table maps common team situations to the better fit between AWS Secrets Manager and self-hosted OpenBao. Read each row as a condition: the choice holds while that condition is true, and the last column names what would flip the answer.
| Scenario | Better fit | Why |
|---|---|---|
| AWS-only team using IAM roles and Lambda rotation today | AWS Secrets Manager | Workloads authenticate with IAM roles, rotation is already wired to Lambda, and no service runs outside AWS. The answer flips if you add non-AWS workloads or want to stop paying per secret and per call. |
| Hybrid team with on-premises databases and AWS workloads | OpenBao | AWS Secrets Manager is reached through AWS Region endpoints, so on-premises systems depend on connectivity to AWS. OpenBao can run in your datacenter and issue database credentials there. The answer flips if on-premises systems are few and already reach AWS over a reliable private link. |
| Air-gapped or isolated network | OpenBao | A managed AWS service cannot be used without a path to its endpoints. OpenBao runs inside the isolated network, but you must plan unsealing and patching yourself. Confirm your unseal method and update process before committing. |
| Team that wants short-lived dynamic database credentials | OpenBao | OpenBao's database secrets engine issues per-request credentials with leases and revocation. AWS Secrets Manager relies on rotated passwords driven by rotation functions. The answer flips if a fixed rotated password per account is acceptable and your databases already have working rotation Lambdas. |
| Team with no platform or security operations staff | AWS Secrets Manager | Running OpenBao means owning high availability, storage backups, unseal key handling, upgrades and audit log retention. Managed AWS removes most of that work. The answer flips if you can staff or contract that operating effort through a fixed-scope engagement. |
| Team consolidating several cloud secret stores into one | OpenBao | One OpenBao instance with cloud auth methods can replace per-cloud secret stores and give one audit trail. AWS Secrets Manager still works for AWS-native integrations, so consolidation is partial. The answer flips if all consumers stay inside AWS. |
| Team that needs AWS-native integrations such as ECS, Lambda or RDS secret injection | AWS Secrets Manager | Many AWS services read secrets from Secrets Manager directly. Replacing those integrations means changing deployment code. The answer flips if you are already moving those workloads to Kubernetes or a platform that can read from OpenBao. |
Where the data lives and who controls the keys
The six areas below decide where secret values sit, who operates the service and who can read the keys that protect them. Each card names what the control means for a regulated buyer and what an auditor will ask to see.
Data location and access path
AWS Secrets Manager is reached through AWS Region endpoints, so secret values are stored and served within the AWS Regions you select. OpenBao runs in your own cloud accounts, data centers or offline networks, so you choose the physical location. Confirm which Regions hold replicas if you use cross-Region replication, and document every network path that reaches the secret store.
Hosting and operating model
With AWS Secrets Manager, AWS operates the service and its infrastructure, and you manage secrets, IAM policies and rotation. With OpenBao, your team or DeployOpen operates the servers, storage, upgrades and backups inside your environment. Auditors will ask who holds administrative access to the hosts and who approves changes to the cluster.
Encryption and key custody
AWS Secrets Manager encrypts secret values with AWS KMS keys, either an AWS managed key or a customer managed key you create. OpenBao encrypts secrets before they are written to storage, and the operator chooses how the barrier key is unsealed. Ask who can use or disable each key, how rotation of the key is recorded, and what happens to data if a key is deleted.
Unseal and recovery material
An OpenBao cluster stays sealed after restart until enough unseal material is supplied, so the unseal approach is a design decision you own. Store unseal shares or auto-unseal references in separate custody, and test recovery before go-live. Auditors will ask for the written procedure, the list of key holders and evidence of a recovery exercise.
Identity and access control
AWS Secrets Manager authorizes access through IAM policies, resource policies and KMS key policies. OpenBao authorizes access through its own policies and auth methods, such as AppRole, Kubernetes, JWT/OIDC and TLS certificates. Document which identities can read, write or rotate each secret, and export the policy set so an auditor can compare it against your access review.
Compliance evidence and vendor dependency
AWS services can be covered by AWS compliance programs that you review through your own assessment, and OpenBao evidence comes from your own logs, configuration and change records. Neither option issues a certification for your organization. Ask your assessor which evidence they need, such as access logs, key policies and backup records, and confirm your data processing terms with each vendor or partner.
Capability comparison: AWS Secrets Manager and OpenBao
This table compares how AWS Secrets Manager and self-hosted OpenBao handle the capabilities that matter most when secrets span AWS, other clouds and on-premises systems. Read each row as a question to answer against your own workloads, and treat cells marked for confirmation as items to verify in the OpenBao docs before you commit. The main takeaway is that the two products differ less on basic secret storage than on who operates the control plane, where the encryption keys live and how far the tool reaches beyond AWS.
| Capability | AWS Secrets Manager | OpenBao |
|---|---|---|
| Secret storage | Secrets stored in AWS and encrypted with AWS KMS keys, accessed through Region endpoints | Key/value secrets encrypted before they are written to the chosen storage backend, run in your own infrastructure |
| Rotation | Managed rotation through rotation functions, which teams typically build and maintain as Lambda functions | No managed rotation Lambda model; rotation is handled through dynamic credentials and engine features, so confirm the exact workflow in the OpenBao docs |
| Dynamic secrets | Not a dynamic credential model; values are stored and rotated rather than issued per request | Dynamic secrets for systems such as Kubernetes and SQL databases, issued on demand |
| Encryption as a service | Not a general encryption service; keys are handled through AWS KMS | Encryption as a service is provided, so applications can encrypt and decrypt data without holding keys |
| Auth methods | IAM-based access control for callers inside AWS | AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens and username and password, plus login MFA; confirm AWS auth method details in the docs |
| Lease management and revocation | Not a lease model; access is controlled through IAM policies and secret version states | Leasing with automatic revocation and bulk revocation for issued credentials |
| High availability | Operated by AWS across Regions, with replication options managed by the service | Active node holds a lock in the data store, standby nodes forward or redirect requests; Raft and PostgreSQL are the supported HA backends |
| Storage backends | Not configurable; managed by AWS | Integrated storage (Raft), PostgreSQL, PebbleDB and in-memory; PostgreSQL is described as easier to operate safely than Raft |
| Audit logging | CloudTrail records a GetSecretValue entry for each secret read | Audit devices configured on the server; confirm the audit device options and log destinations in the OpenBao docs |
| Batch retrieval | BatchGetSecretValue returns up to 20 secrets per call, selected by name, ARN or filter | Confirm the bulk read options available for your client and API version in the OpenBao docs |
| Multi-cloud and on-premises reach | Designed for AWS workloads; other clouds and data centers need separate integration | Runs in any environment you control, including cloud accounts, data centers and air-gapped networks |
Rotation in AWS Secrets Manager vs dynamic secrets in OpenBao
The core difference is where freshness comes from. AWS Secrets Manager rotates a stored value: a rotation function, often a Lambda function, changes the secret on a schedule, and applications re-read the value when they need it. OpenBao issues credentials on request: a client asks the database secrets engine for a credential, receives a lease with a time limit, and OpenBao revokes it when the lease ends. Revocation can be done for one lease or in bulk, which matters when a credential or a host is suspected of compromise. If your rotation logic lives in Lambda functions today, plan to rebuild it. You will need to define database roles, connection settings and lease durations in OpenBao, and you must confirm that your database or target system has a plugin in OpenBao before you commit. OpenBao does not cover every service, so check the supported list in the OpenBao documentation for each target.
Short leases help most in two situations. The first is many short-lived consumers, such as autoscaled instances or CI jobs, where each one should hold its own credential rather than share one password that must be rotated everywhere at once. The second is incident response, where bulk revocation can cut off every credential issued from a given role in one operation, instead of waiting for a rotation window. Static roles cover accounts that must keep a fixed username, such as a legacy service that cannot change its login, although those accounts still need a rotation plan.
Short leases add risk when applications cannot re-fetch credentials. A process that reads a database password once at startup and never asks again will fail when its lease expires, and that failure can look like an outage. Before you move a workload, confirm that its client library or framework can renew or re-request credentials at runtime, and test expiry and revocation in a non-production environment. Ask your team to document which applications need static roles and which can use dynamic credentials, because that inventory drives most of the migration effort.
What each option costs to run, and what drives it
AWS Secrets Manager is billed as a metered service. AWS charges a monthly fee for each secret you store and a separate fee for every 10,000 API calls, with no upfront costs and no long-term contracts, according to the AWS Secrets Manager pricing page. Those two lines are the core of the bill, but the total depends on how your workloads use the service.
- Per-secret monthly charge: Each stored secret costs a fixed monthly amount, so the bill grows with the number of secrets, including the duplicates you keep for each environment, region or application.
- Per-API-call charge: Each 10,000 calls is billed separately. Applications that fetch secrets on every request, or CI jobs that read many secrets per run, push this line up quickly.
- Encryption and key costs: Secrets are encrypted with AWS KMS keys. Check which key type your secrets use and what KMS requests your workloads generate in your own account.
- Rotation functions: Scheduled rotation usually runs through Lambda functions and the database or API calls they make. Cost these from your own account, including the engineering time to maintain the rotation code.
- Multi-region replicas: Replicated secrets are billed in each region where they exist, so cross-region designs multiply the per-secret line.
Before comparing, pull a month of your CloudTrail and billing data to count secrets and calls per workload, then model the bill yourself.
OpenBao is open-source software licensed under MPL 2.0, so there is no license fee for the open-source edition. The cost of running it is the infrastructure and people needed to operate it. These costs fall into a one-time setup phase and a recurring operations phase, and both should be quoted separately.
- Compute and storage: You pay for the servers or Kubernetes capacity for OpenBao nodes and for the storage backend, whether that is integrated storage (Raft) or PostgreSQL. A high-availability design needs several nodes, and the PostgreSQL option adds a database to run.
- Load balancing and networking: A load balancer or ingress in front of the nodes, plus the internal certificates and DNS that clients use, are recurring items that teams often underestimate.
- Unseal key handling: Shamir unseal keys or another unseal method must be generated, split among custodians and stored safely. This is largely a process cost, paid in staff time and secure storage.
- Backups, monitoring and upgrades: Snapshots, restore tests, alerting, and planned upgrades each carry recurring effort. Upgrade effort depends on how many releases you skip, and the migration guide documents the path from a tested Vault version.
- Staff time: Platform or security engineers own patching, access policy, audit review and incident response. This is usually the largest recurring line and the one that changes most with team size and skills.
Ask any implementation partner for a quote that lists each component, the one-time and recurring split, and the assumptions behind staff effort.
What running OpenBao asks of your team
Running OpenBao means owning the cluster that serves your secrets. OpenBao runs an active node that holds a lock in the data store, with standby nodes that forward or redirect requests. The officially supported HA backends are integrated storage (Raft) and PostgreSQL. The OpenBao docs describe PostgreSQL as easier to operate safely than Raft, so teams without strong Raft operations experience should weigh that before choosing. Plan for node placement across failure domains, a load balancer or DNS in front of the cluster, and a tested procedure for replacing a failed node. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL, so confirm whether read scaling changes your sizing.
Unsealing and key custody are the decisions AWS Secrets Manager removes most completely. Each OpenBao node starts sealed, and an operator must unseal it with key shares or an auto-unseal mechanism. Decide who holds the recovery material, where it is stored, how unseal is automated after a restart, and how you rehearse an outage at 2 a.m. Patching is continuous work: track the OpenBao releases page, such as the v2.7.1 security release, and plan rolling upgrades. The Helm chart is the recommended Kubernetes install and requires Helm 3.6 or later, so confirm your cluster version and chart pinning before you start.
Backups, audit logs and monitoring also move onto your team. Snapshot the storage backend on a schedule, test restores into a separate environment, and back up the seal material separately from the data. Enable the audit device, decide where its logs go, and set a retention period that meets your own policy and regulator's rules. Monitor seal status, leader changes, lease counts and storage health. AWS Secrets Manager does not remove IAM design, which still governs who may call the API, application changes that switch clients to OpenBao, or rotation logic, which you rebuild with OpenBao's dynamic secrets. Confirm each of these in your own environment before you commit.
What a move from AWS Secrets Manager involves
The sequence below moves secrets, access and rotation from AWS Secrets Manager into a self-hosted OpenBao cluster in controlled stages, with each step closed by a check you can verify before the next one starts.
Inventory secrets and their consumers
List every secret in each AWS account and Region, the workloads, Lambda functions, CI jobs and applications that read each one, and the IAM roles and KMS keys involved. Record which secrets have rotation configured and which Lambda function performs it. Owners of each application sign off on the list. The output is a register that maps each secret to its consumers, access path and rotation method, and it becomes the basis for every later step.
Stand up a non-production OpenBao cluster
Deploy OpenBao in a non-production environment using the storage backend your team can operate safely, either integrated storage (Raft) or PostgreSQL, and initialize it with your chosen unseal approach. For Kubernetes, the OpenBao Helm chart is the recommended installation path and requires Helm 3.6 or later. Test backups, restore and node failover before any production data is loaded. The check is a documented restore test and a failover test that both pass.
Model auth methods to replace IAM access
Map each consumer from its current IAM role or policy to an OpenBao auth method that fits its runtime, such as AppRole for servers, Kubernetes for cluster workloads, JWT/OIDC for CI pipelines and Userpass only for developer machines. Write one policy per consumer that grants the narrowest paths it needs. Have the security team review the policy set against your access register. The output is a reviewed mapping of every consumer to an auth method and policy.
Export values with BatchGetSecretValue
Read secret values out of AWS Secrets Manager with BatchGetSecretValue, which returns up to 20 secrets per call selected by name, ARN or filter. The operating principal needs Secrets Manager read permissions and, for customer-managed keys, decrypt permission on the KMS key. CloudTrail records a GetSecretValue entry for each secret read, so run exports from a controlled role and keep the export job's logs with your change record. Write the values directly into OpenBao paths that match the register, and verify each secret by comparing a hash, never the plain value, against the source.
Move rotation to dynamic or static roles
For database credentials that Lambda rotation functions currently change, decide whether the consumer can take short-lived dynamic credentials from OpenBao's database secrets engine or must keep a fixed username, which calls for a static role. Secrets with no supported plugin stay on a documented manual or application-side process. Test each rotation path in staging by confirming that the consumer reconnects and that revocation removes access. The output is a rotation decision for every secret that previously had rotation enabled.
Cut over workloads in stages
Move consumers in small groups, starting with non-production and low-impact services, and point each one at OpenBao while keeping the AWS secret available as a fallback during the window. Watch error rates, authentication failures and lease renewals after each group. Expand only when the group runs cleanly through a full business cycle. The check is that every consumer in the register reads from OpenBao and no workload still calls AWS for a migrated secret.
Decommission after the recovery window
Once all consumers are confirmed on OpenBao, remove the IAM permissions that allowed reads, disable rotation Lambda functions, and schedule deletion of the AWS secrets. Respect the recovery window that AWS Secrets Manager applies to deleted secrets, and confirm with your AWS documentation how it applies to each secret. Keep the CloudTrail trail and the migration records for your audit period. The output is a signed decommission record listing each secret, its deletion date and the evidence that no consumer still reads it.
Questions buyers ask before choosing or moving
What drives the cost of moving from AWS Secrets Manager to OpenBao?
The cost of a move is mostly the people time needed to inventory secrets, rebuild access paths and test workloads, plus the platform work to run OpenBao itself. The main drivers are the number of secrets, how many applications read them, how many rotation Lambda functions must be replaced with OpenBao engines, and how many AWS accounts and Regions are involved. Costs that recur include the servers or Kubernetes capacity, storage, backups, unseal key handling, patching and monitoring for OpenBao. When you ask for a quote, request a line for each of these components, along with the work needed to test and cut over each workload, and say whether the scope covers only the move or also ongoing operation.
How long does a move from AWS Secrets Manager take?
No fixed duration applies to every estate, so the timeline depends on the factors that set the work: the number of secrets and consuming services, how many rotation Lambda functions exist, how well the owners of each workload are known, and how much change control each production system requires. Teams usually move in waves, starting with low-risk non-production secrets and then moving to services with dynamic credentials. Ask any provider for a written timeline tied to a defined scope and for the milestones that would change it, such as a failed pilot or a database that OpenBao does not have a plugin for.
What does the move need from our own engineering and security teams?
Your team needs to provide access to the AWS accounts and the IAM and KMS permissions that allow secrets to be read, a list of consuming workloads with their owners, and decisions on identity for each workload. Security staff need to approve the authentication methods, policies, audit log destinations and the unseal and backup approach. Application teams must test their code against the new access path and schedule their own cutovers. Confirm these responsibilities in writing before work starts, because most delays come from missing owners rather than from the platform itself.
Can our team migrate to OpenBao without outside help?
A team with experience in Vault-style secrets management, Kubernetes or Linux operations, and AWS IAM can do the migration itself, and OpenBao is open source so there is no license fee to pay. The migration guide covers an in-place upgrade path from Vault Community 1.14.1 on Raft storage with Shamir unseal, but it was tested only against that version, so check your starting version before deciding. Teams without that experience often bring in an implementation partner for a fixed scope, or buy ongoing support as a retainer after cutover.
Will AWS-native integrations keep working with OpenBao?
Some integrations can keep working, but they need to be redesigned rather than simply pointed at a new endpoint. AWS services such as Lambda, ECS, EKS and CodeBuild that read secrets directly from AWS Secrets Manager through IAM will need OpenBao's AWS or Kubernetes auth methods, or a sync step, to supply values. Services that use the Secrets Manager rotation feature need OpenBao dynamic secrets or a custom process instead. Make a list of every AWS integration that reads or rotates a secret, and test each one in the pilot before you retire any AWS secret.
Do AWS per-secret and per-call charges stop after cutover?
The per-secret monthly fee and the per-10,000 API call charge in AWS Secrets Manager stop only for secrets you have fully removed or no longer read. AWS bills each secret per month and charges per 10,000 API calls, with no upfront costs or long-term contracts, so any secret left behind keeps costing money. Plan a period during which both systems run, and set a date to delete or disable AWS secrets after their consumers have moved. Your AWS bill may also include KMS keys, Lambda invocations and CloudTrail logs, which can continue after you stop using Secrets Manager.
How does the OpenBao license differ from HashiCorp Vault for internal use?
OpenBao is licensed under MPL-2.0 and is a community-led fork of Vault managed under the Linux Foundation's OpenSSF. HashiCorp announced on August 10, 2023 that future releases of its products would move to the Business Source License 1.1, which restricts vendors offering competitive services built on those products. Under MPL 2.0, your organization can run OpenBao internally, modify it and use it in its own products without a commercial license from a vendor, while keeping modified source files under MPL 2.0 when you distribute them. Have your legal team review the license terms for your specific use, especially if you distribute software that embeds OpenBao.
What should a pilot confirm before we move production secrets?
A pilot should prove that the target design works for a few representative workloads before any production secret moves. Confirm that each application can authenticate with the chosen OpenBao auth method, that secrets are read with the expected latency and error handling, and that dynamic credentials are revoked when leases expire. Test high availability failover and restore from backup, and check that audit logs reach your monitoring system. Also confirm the rollback path for each workload, and record the results in a form your compliance team can review.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For AWS Secrets Manager vs OpenBao, the work starts with a written scope that compares your secret inventory, rotation needs and network reach before any platform decision is made.
How we scope
- We inventory secrets, consumers, rotation logic and IAM or KMS dependencies in your AWS accounts.
- We map which workloads run outside AWS and which need on-premises or air-gapped secret access.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We deploy OpenBao in your environment with a chosen storage backend, high availability design and unseal approach.
- We configure auth methods for AWS, Kubernetes and human access, then test access paths against existing workloads.
- We run security testing on the deployment, including access control and audit logging checks, before cutover.
How we hand over
- We document architecture, runbooks for unseal, backup, upgrades and incident response, and access policies.
- We support staged migration of secrets and workloads, with a rollback path documented for each stage.
- We prepare configuration and evidence for your compliance assessment, which independent auditors then review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover OpenBao version upgrades, patch review and periodic security testing of the deployment.
- Ask for a quote built from the written scope, listing one-time build effort separately from recurring support.
