When does AWS Secrets Manager cost more than self-hosted OpenBao?
The answer depends on three numbers: how many secrets you store, how many API calls your workloads make, and how much engineering time it takes to run OpenBao highly available. AWS Secrets Manager bills per secret per month and per 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS Secrets Manager pricing page. OpenBao is licensed under MPL 2.0 and carries no license fee, so its costs are the servers, storage, unseal key handling, implementation and the people who operate it. Those costs are largely fixed, while AWS costs scale with each secret and each call.
That structure means managed pricing grows with your estate, and self-hosted cost grows more slowly. Large secret counts, high-frequency reads from fleets of short-lived workloads, or many environments multiplied by many applications tend to favor OpenBao, because the per-secret and per-call charges keep accumulating while the cluster cost stays comparatively flat. Small estates are different. A handful of secrets read occasionally may cost little on AWS, and a three-node cluster with backups, monitoring and upgrade windows can cost more in staff time than the managed bill. Count operating effort honestly before deciding.
Before comparing totals, ask your team to model three scenarios: current secret count, the count in 12 months, and peak call volume during deployments. Confirm the call volume from your CloudTrail or AWS usage reports rather than estimates, and confirm the number of engineers who would be on call for OpenBao. Price each side with the same assumptions, and request written quotes for any implementation or support work so that staff and vendor costs are compared on equal terms.
Which cost components change between the two options?
This table lists each cost component on the AWS Secrets Manager side and the self-hosted OpenBao side, and marks whether it is one-time or recurring. AWS charges are published on its pricing page and must be pulled for your Region, while OpenBao has no license fee, so the comparison turns on infrastructure, people and the work to keep the service running.
| Cost component | AWS Secrets Manager | Self-hosted OpenBao | One-time or recurring |
|---|---|---|---|
| Per-secret fees | Charged per secret per month, per AWS pricing for your Region | No secret fee; storage and compute are the cost base | Recurring |
| Per-call charges | Charged per 10,000 API calls, so polling and sync jobs add cost | No per-call charge; request volume uses your server capacity | Recurring |
| Replicas and cross-Region copies | Replication to other Regions is billed as additional secrets | Replicas are servers you run in your own sites or clouds | Recurring |
| KMS key usage | Customer managed KMS keys add key and request charges | Seal and encryption use your chosen unseal or auto-unseal method | Recurring |
| Rotation Lambda functions | Lambda invocations, code and IAM work to maintain rotation logic | Dynamic database secrets replace most rotation code; some services still need custom work | Recurring for run cost, one-time for build |
| OpenBao servers and storage | None; AWS operates the service | Virtual machines or Kubernetes nodes, plus storage for Raft or PostgreSQL | Recurring |
| Unseal key management | None; AWS manages the underlying keys | Shamir key custody or an external unseal service, with its own cost | One-time setup, recurring custody |
| High availability | Built into the managed service | Minimum multi-node cluster and load balancing you operate | Recurring |
| Implementation and migration | Little or none for new secrets | Design, deployment, export and cutover of existing secrets | One-time |
| Support, upgrades and patching | Included in the AWS service | Vendor or partner support contracts, plus upgrade and patch effort | Recurring |
| Staff time | Limited to IAM policy and secret ownership | Platform operators for backups, audit, access reviews and incidents | Recurring |
What moves the comparison most
AWS Secrets Manager charges scale with how many secrets you hold and how often they are read, while OpenBao costs scale with the cluster you run and the people who run it. The cards below cover the variables that shift the balance, and what to measure before you compare quotes or invoices.
Total secret count
AWS Secrets Manager bills a monthly fee for each secret, so the count sets a floor that exists whether or not anything reads the secret. OpenBao has no per-secret fee, so its cost does not grow with each new secret in the same way. Count active secrets, not just those in use, and separate application secrets from short-lived credentials that OpenBao could issue dynamically. Mark secrets that are scheduled for deletion or that are duplicates across environments.
API call volume
AWS Secrets Manager also bills per 10,000 API calls, so a fleet that re-reads secrets on every deploy, container start or request pushes the variable part of the bill up. Measure calls per day by source, including CI runners and sidecars that poll for changes. Caching inside workloads and longer refresh intervals reduce this cost, while OpenBao call volume is served by your own cluster, so the cost there is capacity, not per-call charges.
Batch retrieval pattern
BatchGetSecretValue returns up to 20 secrets per call, which can cut the number of billable calls when a service needs many values at startup. Check whether your code already batches, and whether it reads secrets one at a time out of habit. Each secret in a batch still produces its own CloudTrail GetSecretValue entry, so audit log volume and any log storage cost do not fall in the same proportion as call charges.
AWS accounts and Regions
Each AWS account and Region holds its own secret store, so a multi-account or multi-Region estate multiplies the per-secret fees and the replication or copy work. A single self-hosted OpenBao cluster can serve several accounts and clouds through its auth methods, which can flatten that cost. Inventory accounts and Regions where secrets live today, and note any cross-Region replicas you pay for. Confirm the network path from each account to the OpenBao cluster, since that path adds transfer and networking costs of its own.
Availability and recovery targets
AWS operates the Secrets Manager control plane for you, with no cluster to size or patch. A self-hosted OpenBao deployment that must survive node loss needs multiple nodes, a supported high availability backend such as integrated storage or PostgreSQL, and a tested recovery procedure for unseal keys. Each extra node, backup target and standby adds infrastructure and operating cost, so write down the recovery time and recovery point your services require before you size the cluster.
Rotation scope and Lambda cost
Rotation in AWS Secrets Manager often runs through Lambda functions that you write, deploy, monitor and pay to invoke, plus the KMS requests they generate. The number of rotated secrets and the rotation frequency therefore drive both fees and maintenance. OpenBao's database secrets engine can issue short-lived credentials instead, which removes some Lambda spend but moves effort into database plugin configuration. Count rotated secrets, Lambda functions and KMS calls separately, and list services that have no OpenBao plugin.
Existing team skills
Staff time is often the largest line in a self-hosted comparison, and it is the one teams most often leave out. If your engineers already run Kubernetes, Raft clusters and IAM policies, the added effort of operating OpenBao is smaller. If not, plan for training, on-call coverage and the upgrades that come with a security product. Ask for a written estimate of hours per month for operation, patching and audits, and compare it with the time your team spends on IAM and Lambda rotation today.
What a self-hosted OpenBao deployment actually costs to run
The cost of self-hosted OpenBao is the cost of the infrastructure and people that keep it available, not a line item from a vendor. Most of it recurs: compute for the OpenBao nodes, storage, load balancing, backups, monitoring, and the engineering time to patch and upgrade. The first decision that drives the bill is the storage backend. OpenBao's documented options are integrated storage (Raft), PostgreSQL, PebbleDB and in-memory, and the storage docs describe PostgreSQL as an easier backend to operate safely than Raft. If your organization already runs a managed or well-supported PostgreSQL service, the storage layer may add little new operating effort. If it does not, Raft keeps the cluster self-contained but puts backup, snapshot and node replacement procedures on your own team.
High availability works through one active node that holds a lock in the data store, while standby nodes forward or redirect requests to it. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL, which allows read traffic to scale horizontally. This affects node count: a three-node cluster is a common shape for high availability, but the number of nodes you pay for depends on your availability target and on how much read traffic your workloads generate. Confirm the exact node sizing with your platform team and with the OpenBao high availability docs before pricing compute.
Unseal keys are the cost item most often missed. Without a cloud KMS, OpenBao is started and unsealed with key shares that must be generated, distributed to custodians and re-entered after restarts or failovers. Someone must own that ceremony, the custodian list and the procedure for rotating keys, and that work recurs. Ask your team what they will use to hold and audit unseal material, and who is on call when a node restarts at night. Finally, pull real figures from your own sources: your cloud provider's current pricing for instances, storage, load balancers and egress; your staff rates; and your expected support contract, if you buy one. None of those numbers appear on this page, and a fair comparison with AWS Secrets Manager depends on them.
How to build the comparison with your own numbers
This sequence turns the cost comparison into a three-year model built from your own secret counts, call volumes, Regions and staffing, so the result reflects your environment rather than a generic example.
Inventory secrets and their rotation needs
Platform owners and application teams list every secret stored in AWS Secrets Manager, grouped by Region, account and owning service. For each secret, record whether it is rotated by AWS-managed rotation, by a Lambda function, or not at all, and whether a consuming application depends on a fixed username. Include secrets that are referenced only by infrastructure code, since they count toward the per-secret charge too. The step is done when you have one count per Region and one row per secret category, with rotation method noted. Illustrative: a team might find that a few hundred secrets split unevenly across accounts, and that only a minority rotate through Lambda.
Count monthly API calls from CloudTrail
Platform engineers pull a month of CloudTrail event history or application metrics and count GetSecretValue and BatchGetSecretValue calls, grouped by caller role. Note that BatchGetSecretValue logs one GetSecretValue entry per secret, so the logged count can differ from the number of billed API calls. Also count calls made by rotation functions and by tooling such as CI jobs and deployment scripts, because these are easy to miss. The step is complete when you have a monthly call total per workload and a note on which volumes are peaks, such as deployments or autoscaling events.
Price AWS for your Regions
Using the AWS Secrets Manager pricing page for each Region in use, the finance or cloud team applies the per-secret monthly rate and the per-10,000 API call rate to your counts from the previous two steps. Add the cost of any KMS keys used for encryption, any Lambda rotation functions and their logs, and cross-Region replicas if you use them. Confirm the rates in your own billing console, because the pricing page is the reference and your enterprise discount agreements may change the result. The step closes with a monthly and annual AWS total per Region, itemized by component.
Size an OpenBao high availability layout
The platform team chooses a topology for OpenBao, typically an active node with standby nodes using integrated storage (Raft) or PostgreSQL, as described in the OpenBao high availability documentation. Decide the number of nodes, the instance size for each, the storage volume and backup target, and the Region or data center placement. Include load balancers, DNS, TLS certificates and a separate backup location. Price each component using your cloud provider's or hardware vendor's current quote. The step is done when you have a diagram and a bill of materials that lists compute, storage, network and backup items with unit costs.
Plan unseal key and KMS handling
Security and platform leads decide how unseal keys are held, whether by Shamir key shares split among custodians or by an auto-unseal mechanism backed by a key management service you already operate. Each choice has a cost: an HSM or cloud KMS key carries its own recurring fee, while manual custodians add operational time. Record who holds each share, how shares are rotated, and how the procedure is tested. Ask your key management vendor for current pricing in writing. The step closes with a documented unseal design and a cost line for each key service.
Estimate staff hours for operations
Platform and security leads estimate the recurring hours for installation, upgrades, backups and restore tests, certificate renewal, monitoring, and on-call response. Base each estimate on your team's own history with similar services, and list the roles that perform the work and their loaded hourly cost. Include time for applying security releases, such as the OpenBao v2.7.1 release that carried security fixes, and for staying on a supported minor line. Ask your implementation partner or vendor for a written scope before accepting any staffing assumption. The step is complete when you have a monthly hour estimate by role and a monthly cost.
Add one-time migration and implementation costs
Project owners add the one-time costs: design, installation, integration with each workload, rebuilding rotation logic, testing, parallel running, and decommissioning AWS resources. Include any fixed-scope implementation fee quoted in writing, internal project hours, and training. Note the AWS recovery window and the time you need to keep the old store available during cutover. Do not assume a duration until your plan is agreed. The step closes with a single list of one-time items, each with an owner and an amount or a quote reference.
Run a three-year comparison of totals
Finance and platform leads build a three-year table with one-time costs in year one and recurring costs for each year, for both the AWS option and the OpenBao option. Run a base case with your current secret count and call volume, then rerun it with a higher count and higher calls to see which option drives the difference. Record the assumptions beside each total. The step is done when the table shows the year-by-year totals, the break-even point if one exists, and the inputs that most change the result, which you can then review with the security and compliance owners.
When the managed service is the cheaper choice
AWS Secrets Manager is often the cheaper option when the secret count is small, the workloads already run inside AWS and nobody on the team is responsible for operating a secrets platform. Its pricing is per secret per month plus per 10,000 API calls, with no upfront costs or long-term contracts, so a few dozen secrets read by a handful of services can cost less in total than a cluster that must be kept running, patched and backed up around the clock. The same holds when access is already governed by IAM roles, because services can read secrets without a new authentication system, KMS keys and CloudTrail logging come with the service, and nothing has to be installed on a network.
The break-even point depends on your own numbers, so count them before deciding. List the secrets, the services that read them, how often each reads them, and whether any of them are rotated by Lambda functions that you would need to rebuild. Then price each cost line as it applies to you: the monthly per-secret charge, the per-call charge, KMS usage, rotation functions and the cross-account reads your architecture requires. Confirm current rates on the AWS pricing page, since those are the figures that apply to your account and Region.
Do not stop at the infrastructure line. For a self-hosted OpenBao deployment, the largest recurring cost is usually the time engineers spend on upgrades, unseal and recovery procedures, high availability, backups, audit log retention and incident response. Estimate that effort in hours per month for your own team, include on-call coverage and the cost of a skilled engineer who is pulled off other work, and compare the total with the managed bill. If your organization has no platform team and no plan to build one, the managed service may remain the right choice even when OpenBao looks cheaper on paper.
Frequently asked questions about AWS Secrets Manager and OpenBao costs
How much time does a self-hosted OpenBao take to run each month?
The monthly effort depends on how many clusters you run, how you store data, and how often you patch and back up. A single production cluster with integrated storage, regular upgrades, monitoring, backup testing and access reviews is ongoing platform work, not a one-off task. Your team's cost is the share of engineering time spent on that work, plus on-call coverage for unseal and availability incidents. Ask the vendor or your own platform team to estimate the hours for your topology, and ask a provider to break its retainer scope down by task so you can compare it with your internal estimate.
Can our team migrate from AWS Secrets Manager to OpenBao without outside help?
Yes, a team with Kubernetes or Linux operations skills and clear ownership can do it, but the work is more than copying values. You need to export secrets with BatchGetSecretValue under suitable IAM and KMS permissions, rebuild rotation Lambdas as OpenBao engines or application logic, move workloads from IAM-based access to OpenBao auth methods, and set a plan for the AWS recovery window before deleting anything. Teams often bring in outside help for the cutover and the unseal and backup design, while keeping application changes in-house. Decide which part you own before you estimate the effort.
What drives the implementation cost of an OpenBao migration?
The main drivers are the number of secrets and applications, how many workloads use AWS-native integrations such as Lambda rotation or IAM policies, the number of environments, and whether you need high availability across sites or air-gapped deployment. Other factors include how many database and cloud engines you configure, how much audit logging and access policy design you need, and how much testing is required before cutover. Ask any provider for a fixed scope listing the systems in scope, the deliverables and the acceptance checks, because those items determine the quote.
How long does an OpenBao migration take, and what does the timeline depend on?
The timeline depends on inventory quality, the number of applications that read secrets, how many rotation paths must be replaced, and how much change control your organization requires. No duration for a typical project is given in this page's sources, so treat any number you see as a claim to verify. A realistic plan separates discovery, a parallel run where both stores serve reads, workload-by-workload cutover and the AWS decommissioning window. Ask for a written plan with milestones and the entry and exit criteria for each stage.
Does OpenBao have a license fee?
OpenBao is licensed under MPL 2.0, and its repository is maintained as an open-source project under the Linux Foundation's OpenSSF. You do not pay a license fee to run the software itself. Your costs are the infrastructure to host it, storage, the staff who operate it, and any external support you choose to buy. Confirm the license terms for any add-on, plugin or distribution you plan to use, and check the release notes for each version you deploy.
How do we get a quote from a fixed written scope?
Start by writing down the scope: the secrets inventory by type and count, the workloads that read them, the AWS accounts and Regions involved, the target platform (Kubernetes or virtual machines), and the high availability and backup requirements. Add the deliverables you expect, such as the deployed cluster, the migrated engines and auth methods, runbooks and acceptance tests. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Send the same scope to each bidder so the comparison is fair.
Do batching calls to AWS Secrets Manager reduce per-call charges?
Batching can reduce the number of API calls, which lowers the per-call portion of your bill. The BatchGetSecretValue API retrieves up to 20 secrets per call, selected by name, ARN or filter, so a service that reads many secrets at startup may need fewer calls. Batching does not change the per-secret monthly fee, and it does not remove CloudTrail logging, which records a GetSecretValue entry for each secret. Check the current pricing page for the per-call rate and confirm with your own usage reports how much of the bill is call volume and how much is secret count.
Why licensing changed the cost conversation for secrets managers
Licensing now belongs in the cost model for any secrets manager, because the terms under which a product is licensed can change after you have built on it. On August 10, 2023, HashiCorp announced that future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1, while its APIs, SDKs and most libraries stayed under MPL 2.0. IBM completed its acquisition of HashiCorp on February 27, 2025. Buyers evaluating Vault-based options should read the current license for the exact edition and version they plan to run, and should ask whether future upgrades would require a commercial agreement. HashiCorp's announcement sets out the scope of the change.
OpenBao is an open-source, community-driven fork of Vault, managed under the Linux Foundation's OpenSSF and licensed under MPL 2.0. Because the license and governance are fixed by the project rather than by a single vendor's product roadmap, the license risk you carry is easier to forecast. The practical check is to confirm the license of each component you deploy, including any plugins, and to record which edition you run so that future upgrades can be costed against a known baseline. Your own legal team should review these terms before you commit to a multi-year plan.
AWS Secrets Manager is a separate question. Its cost is set by AWS pricing, which bills per secret per month and per 10,000 API calls, and its use is governed by AWS service terms rather than by an open-source license. Comparing the two options therefore means comparing a metered service with a self-hosted platform you license freely but operate yourself. Before you build the model, confirm the current AWS rates for your Region and your expected secret and call counts from the AWS Secrets Manager pricing page, and decide who in your organization will own the cost of running OpenBao.
How DeployOpen scopes a fixed-price OpenBao implementation
DeployOpen plans and implements self-hosted OpenBao inside your own cloud accounts or data centers, starting from a written scope. Engagements are fixed-scope, so the cost comparison in this guide becomes a set of agreed deliverables before any work starts.
How we scope
- We inventory secret counts, read and write call volumes and the workloads that fetch them from AWS Secrets Manager.
- We define which secrets move to OpenBao, which stay in AWS and which need rotation logic rebuilt.
- We agree the written scope, deliverables and timeline with you before implementation begins.
How we build
- We plan OpenBao server sizing, storage backend, high availability layout and unseal key handling in your environment.
- We configure auth methods for your workloads, such as AWS, Kubernetes or AppRole, and test access paths.
- We test backup, restore and failover behavior, then harden the deployment against the controls you need to show.
How we hand over
- We document architecture, runbooks, unseal procedures and the rotation design you will operate.
- We prepare compliance-ready evidence of configuration and access controls for your independent auditors.
- We walk your platform and security teams through operations so they can run the system without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can plan OpenBao version upgrades and patch cycles against releases you choose to track.
- We can run periodic security testing of the deployment, scoped in writing like any other engagement.
