Is Azure Key Vault cheaper than self-hosted OpenBao for your secret volume?
The short answer is that it depends on operation volume, your key and HSM choices, how many certificates you renew, and who would run OpenBao. Azure Key Vault charges scale with use, so a low-volume vault with a handful of secrets can be inexpensive, while a high-volume estate with frequent reads, HSM-protected keys and many certificate renewals can cost materially more. OpenBao reverses that shape: its costs are mostly fixed, made up of servers, storage, backups, optional HSM hardware, setup work and the on-call effort to keep the service healthy. The break-even point sits where your Key Vault bill, driven by your own operation counts, grows past the fixed cost of running OpenBao at the reliability you need. No break-even figure is stated here because it can only be calculated from your own numbers.
Start with your own Azure price sheet. Key Vault rates are set by Azure's published pricing and vary by region and tier (Standard or Premium for keys, and separate rates for Managed HSM pools and certificate renewals), so take the figures from the region where your vaults actually run. Pull a month of operation counts from Azure Monitor or your billing export, split by secret reads, key operations, certificate requests and renewals, and identify which applications generate most of the traffic. Then list what OpenBao would cost to run: the number of nodes for high availability, the storage backend you choose, backup storage, whether you need an HSM for auto-unseal or key protection, and the staff hours for upgrades and incident response. Ask any implementation partner for a quote built from a written scope, and ask them to show each cost component separately so you can compare it line by line with the Azure bill.
Which cost components matter on each side
This table sets each Azure Key Vault cost component against its self-hosted OpenBao counterpart and marks whether it is one-time or recurring. Check the Azure column against the current Azure price sheet and the OpenBao column against your own infrastructure and staffing figures. The main takeaway is that Key Vault charges follow usage, while OpenBao costs follow the capacity and people you commit to, so the break-even point depends on your volume.
| Cost component | Azure Key Vault (billed by Azure) | Self-hosted OpenBao (who pays and for what) | One-time or recurring |
|---|---|---|---|
| Key Vault operations | Billed per operation on the Azure price sheet, so cost follows reads, writes and key uses | No per-call fee; you pay for the nodes and the staff who run them, so cost follows capacity | Recurring, scales with request volume on the Azure side |
| HSM-protected keys | Billed per key, with a higher tier needed for HSM-backed keys; confirm current rates on the price sheet | Software-protected keys carry no license fee; HSM protection needs a hardware or cloud HSM you pay for | Recurring |
| Certificate renewals | Billed per renewal request, so cost grows with certificate count and renewal frequency | The PKI secrets engine issues certificates on your servers; cost is the effort to automate issuance and renewal | Recurring, mostly internal effort |
| Managed HSM pools | Billed for each provisioned pool on the price sheet, whether or not the pool is busy | No pool fee; the equivalent is the HSM capacity you buy or rent for your own cluster | Recurring |
| OpenBao servers and storage | None; Azure operates the service and its underlying infrastructure | Compute for the nodes your HA design needs, plus Raft or PostgreSQL storage, backups and networking | Recurring, grows with node count and data size |
| Optional HSM for unseal or key protection | Covered by the Key Vault HSM tier pricing already listed on the price sheet | Hardware or cloud HSM you choose, bought outright or rented; check the vendor quote for each model | One-time or recurring, depending on the purchase model |
| Setup and migration | Vault setup is configuration work; exporting secrets and re-creating keys is a separate project | Design, installation, auth method mapping and cutover; DeployOpen engagements are usually fixed-scope and quoted from written scope | One-time |
| On-call, upgrades and patching | Azure handles platform patching; your team still owns application-side changes | Your team or a retainer covers paging, OpenBao upgrades, backup and restore tests, and certificate rotation | Recurring |
| Internal skills | Fewer specialist skills needed for the service itself | Staff or contractors who know Raft or PostgreSQL, unseal procedures, auth methods and incident response | Recurring, usually the largest hidden cost |
What moves the Key Vault and OpenBao comparison
Azure Key Vault bills by operation, key and renewal, while OpenBao costs follow the servers, storage and people you run. The drivers below decide which side is cheaper, and each one pushes cost in a different direction on each side.
Operation volume and read patterns
Key Vault charges per operation, so every application that reads a secret on each request adds to the bill. Caching secrets in applications or sidecars, and batching reads where the client allows it, lowers Key Vault volume. On OpenBao, extra reads mostly add load to your servers rather than a metered charge, so high read volume favors self-hosting only if the cluster has spare capacity. Ask your Azure account team for the current per-10,000 operation rate and measure your real read count over a month before comparing.
HSM tier choice
Keys protected by a hardware security module cost more in Key Vault than software-protected keys, and Managed HSM is billed as a dedicated pool. On OpenBao, HSM protection is optional and comes from a supported HSM integration, which adds hardware and support cost you must buy and run. Decide which keys truly require HSM protection, because that choice moves the cost more than any other single setting. Confirm the compliance requirement in writing before you pick a tier.
Number of vaults and subscriptions
Key Vault is provisioned per vault, and teams often create one per application, environment or subscription, each with its own operation and key charges. A single OpenBao cluster can serve many teams through namespaces and policies, so its fixed cost does not grow with each new vault. The opposite risk is one shared cluster with weak tenant separation, which raises the blast radius. Count your vaults and subscriptions today and list which ones could consolidate.
Certificate renewal frequency
Key Vault certificate renewals carry their own charge per renewal request, so short-lived certificates that renew often multiply that cost. OpenBao's PKI secrets engine issues short-lived certificates from your own internal CA, which removes the per-renewal fee but moves issuance, root key handling and revocation work to your team. Public certificates still come from a public CA regardless of platform. Ask which certificates are public, which are internal and how often each one renews.
Availability and multi-region design
Key Vault gives you a managed availability design with Microsoft operating the service. An OpenBao high availability setup needs several nodes, a supported storage backend and a plan for failover between regions, all of which you pay for in compute, storage, network and engineering time. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and the choice between them changes operating effort. Price the second and third node and the cross-region link before concluding self-hosting is cheaper.
Skills already on the platform team
The largest OpenBao cost is often people, not infrastructure. A team that already runs Kubernetes, Vault or PostgreSQL in production spends less time on setup, unseal procedures, upgrades and on-call than a team that starts from zero. Teams with Entra ID and Key Vault skills but little secrets platform experience should budget for training or an implementation partner. Estimate on-call hours per month honestly, including upgrade and incident time, and compare them with the Key Vault support plan you would drop.
How to build the Key Vault versus OpenBao cost model
This sequence turns your current Key Vault bill and usage into a side-by-side model of Azure charges and self-hosted OpenBao costs, so you can see the volume at which each option is cheaper for your environment. The output is a worksheet your finance and platform teams can check against the same inputs.
Export twelve months of Key Vault billing and metrics
Pull the last 12 months of invoice lines for every Key Vault, Managed HSM pool and certificate order from Cost Management, grouped by resource and meter. Export the matching Azure Monitor metrics for each vault so you can see operation counts by month, not just the average. Confirm that the invoice totals reconcile with the meter-level detail before you rely on any figure. The output is a monthly table per vault that separates operations, HSM-protected key charges, certificate renewals and Managed HSM pool charges.
Count secrets, keys, certificates and HSM pools
Inventory every vault in your subscriptions and record how many secrets, keys and certificates each holds, including disabled items and items in soft-delete retention. Count the certificate renewals in the same period and note which keys are HSM-protected and which are software-protected, because Azure bills them differently. Record every Managed HSM pool and its region. Ask the platform team to confirm the inventory against the vault list so that nothing is missed. The output is a count sheet that becomes the quantity column in the Azure model.
Estimate read volume per application from logs
Use Key Vault diagnostic logs or Azure Monitor to group read operations by calling application, identity and vault. Identify applications that read on every request, because those drive most operation charges, and applications that read only at startup. Estimate the expected growth from the last twelve months if your release plans or scaling policies point to it. The check is that the per-application totals add up to the monthly operation count from step one. The output is a read profile that tells you where caching or fewer reads would change the Azure bill.
Price the Azure lines from the published calculator
Enter your counts and operation volumes into the Azure Pricing Calculator for the regions and tiers you use, and record the rate each line item uses. Price Managed HSM pools separately, since they are a different service with different billing. Keep the calculator output with its date and currency so the model can be rerun later. Check the result against your twelve-month invoices and explain any difference, such as credits, reservations or discounts that do not appear in the calculator. The output is a priced Azure column per year.
List OpenBao infrastructure, storage and backup costs
Describe the OpenBao topology you expect, including the number of nodes for high availability, the storage backend (integrated Raft storage or PostgreSQL, as documented in the OpenBao storage and HA references), load balancing, backup storage, and whether you need an external HSM or auto-unseal service. For each item, record who pays (your cloud account, your data center, or a managed database service you already run) and whether it is a recurring cost or a one-time purchase. Ask your infrastructure team for their own unit rates. The output is a bill of materials with a recurring and a one-time column.
Add setup, migration and on-call hours at your rates
Estimate the hours for the initial deployment, the application migration from managed identity to OpenBao auth methods, testing, documentation, and the recurring operation work such as upgrades, backups and incident response. Multiply each estimate by your own loaded hourly rates, which you must supply, and separate one-time effort from recurring effort. If you buy implementation or support from an outside firm, use the written scope and quote for that line. The output is a labor column that you can compare with the Azure column year by year.
Find the volume where the totals cross
Build a simple model with operations per month on the horizontal axis and yearly total cost for Azure and for OpenBao on the vertical axis, holding the other inputs constant. Find the point where the two lines cross, and repeat the calculation for certificate renewals and HSM-protected keys, since those drive cost differently. Test the crossover against your read profile and against the scenario where read volume grows. Have finance and the platform owner review the worksheet. The output is a documented break-even point with its assumptions, which is the basis for a decision.
How the answer changes by operating model
Illustrative example: a small engineering team with one or two vaults, a handful of applications and secrets read mainly at deployment time. Key Vault charges are tied to operations, so light reads keep that line item modest. The OpenBao side is dominated by fixed costs: a host or two, storage, backups, monitoring and the time someone spends on upgrades and unseal procedures. At this scale the managed service often costs less, unless the team already has spare capacity to host OpenBao.
- Fixed platform cost: A single OpenBao node still needs a host, backups and monitoring, and those costs do not fall with a light workload.
- Operations time: Upgrades, unseal key handling and certificate renewal usually fall to whoever is on call, often a developer with other duties.
- Low read volume: Infrequent reads keep per-operation charges small, which makes the managed service hard to beat on price.
- Where the balance can shift: Adding dynamic database credentials or a growing number of non-Azure workloads can change the comparison.
Ask what share of an engineer's time would go to operating the service and whether existing servers could host it without new purchases.
Illustrative example: a platform team runs many Azure subscriptions, each with its own vault, and services that read secrets at startup, on every pod restart and during token renewal. Per-operation billing grows with that read volume, and HSM-protected keys or Managed HSM pools add capacity charges per vault or pool. A self-hosted OpenBao service can consolidate many vaults into one, so read cost becomes mostly the hardware and storage it runs on. The main recurring costs then shift to high availability design and staffing.
- Read volume: Per-operation charges grow with every restart and renewal, while a self-hosted cluster absorbs reads within fixed capacity.
- Consolidation: One OpenBao service using namespaces can replace many vaults, reducing duplicated pricing and the number of access policies to maintain.
- HSM choice: If keys need hardware protection, an HSM for OpenBao is an extra purchase or lease that must be compared with Managed HSM pool charges.
- High availability and staffing: Running Raft or PostgreSQL in high availability, plus on-call coverage, becomes the largest recurring cost.
Before comparing quotes, pull daily read counts from Azure monitoring, count the vaults in scope and ask each vendor or partner to price the HSM option separately.
Illustrative example: a regulated organization keeps payment workloads on customer-managed keys in Managed HSM because Azure services require them, while other application secrets could move out. Here the costlier side is often the split estate itself: OpenBao runs alongside retained Key Vault, so the organization operates two control planes, two audit trails and two sets of access reviews. Migrating only the portion that does not depend on Azure-bound keys may still reduce operation charges, but it adds integration and evidence work.
- Retained keys: Services that require customer-managed keys stay billed in Key Vault or Managed HSM, so savings apply only to the migrated share.
- Two control planes: Access reviews, logging and rotation runbooks must cover both services, which adds recurring labor.
- Evidence: Auditors will ask how key custody and access are controlled in each system. DeployOpen prepares that evidence, but independent auditors issue the assessment.
- Hardware decisions: If policy requires HSM custody for OpenBao keys, that hardware cost must be included as either a one-time purchase or a recurring lease.
Confirm with the compliance owner which key types must stay in Key Vault and which controls the auditor expects for each system.
What a migration adds to the first-year cost
A move from Key Vault to OpenBao adds one-time work on top of the recurring run costs, and that work is usually the largest single item in year one. Budget it as separate lines: secret export through the API, re-creation of keys, application changes to authentication, and a period of parallel running. Key Vault backups only restore inside Azure, so the practical route for secret values is reading them through the Key Vault API and writing them into OpenBao, which means someone must write, run and verify that export tooling. Ask any implementation partner to price this as a fixed scope with named deliverables, and confirm the size of the secret inventory before agreeing a number.
Keys are the costly exception. Key material in Key Vault that is marked as non-exportable cannot be copied, so each such key must be re-created in OpenBao or in a separate HSM, and every system that encrypts or signs with it must be re-pointed and re-tested. Ask which keys in your vault are exportable, which are backed by Managed HSM, and which hold data that must be re-encrypted. Each of these decisions changes the effort, and none of them can be settled by looking at the monthly Azure bill.
Switching applications is the next line item. Workloads that authenticate to Key Vault with managed identities need OpenBao auth methods instead, such as Kubernetes, JWT/OIDC, AppRole or TLS certificates, and each service needs its own role and policy. The OpenBao migration guide describes an in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, and it was tested only against that version. A Key Vault migration is a different path, so confirm with the OpenBao project and your implementer which steps apply to you, and scope them separately. Plan parallel running for a defined period so both systems serve the same applications during cutover, and cost that period as recurring infrastructure and staff time.
Questions buyers ask before comparing costs
How much does it cost to run OpenBao compared with Azure Key Vault?
OpenBao has no license fee, so its cost is the infrastructure and people that run it: servers or nodes, storage, backups, load balancing, optional HSM hardware or service, and the engineering time for setup and on-call operations. Key Vault instead bills per operation, per protected key, per certificate renewal and per Managed HSM pool. The comparison depends on your own volumes and on what your team already runs. Build a model with your current Key Vault usage reports, the number of secrets read per day, the number of HSM-protected keys and the certificate renewal count, then price the OpenBao side with your own cloud or data center rates. Confirm current Azure rates on the Azure pricing pages before you rely on them.
Can our team run OpenBao without outside help?
Often yes, if you have engineers comfortable with Kubernetes or Linux services, TLS, backups and incident response, because OpenBao is an open-source platform you operate yourself. The harder parts are high availability design, unseal and key custody procedures, auth method configuration for Azure workloads, and tested restore procedures. The OpenBao high availability documentation describes the officially supported HA backends, integrated storage (Raft) and PostgreSQL, and that choice affects how much operational work you take on. Ask your team to list who would be on call, which skills are missing and how many hours a month operations would take, then decide where outside help fits. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your infrastructure under a written, fixed scope.
How long does a migration from Key Vault to OpenBao take?
The duration depends mostly on how many vaults, secrets, keys and certificates you have, how many applications read them, and how many of those applications use Azure managed identity directly. Keys usually have to be re-created rather than copied, so the work for keys is larger than for plain secret values. Secret values are readable through the API, which makes bulk export possible, but each consumer must then be switched to OpenBao auth methods and tested. Plan the cutover in waves, starting with low-risk workloads, and keep Key Vault running until each wave is verified. OpenBao's migration guide covers an in-place upgrade from Vault Community 1.14.1, which is a different path from moving out of Key Vault. Ask any provider for a timeline tied to a written inventory of your vaults and consumers.
Which Key Vault costs are hardest to predict?
The costs that move most are the ones that scale with application behavior rather than with the number of secrets. Operation charges grow with every read, which means caching, retry storms, deployment pipelines and polling jobs can multiply the bill without any new feature. Certificate renewals depend on how many certificates you issue and how often they expire or are replaced, including short-lived certificates. HSM-protected keys and Managed HSM pools carry fixed or per-key charges that can persist after a project ends. Review Key Vault metrics and cost exports for the last several months, then group operations by application and environment. The same grouping shows which consumers would dominate OpenBao load and which could be moved first.
What should a quote for self-hosted OpenBao include?
A useful quote lists each component separately so you can compare it with your own Azure figures. Ask for the scope of design, installation, integration with your identity provider and Azure workloads, hardening, backup and restore testing, documentation, and handover. Ask which items are one-time, such as design and migration, and which recur, such as upgrades, support and continuous testing. Ask what infrastructure you would pay for directly, including compute, storage, load balancers, backup targets, monitoring and any HSM. Ask what assumptions the quote makes about secret volume, HA layout and on-call hours, and what changes the price. Engagements at DeployOpen are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
When is Azure Key Vault the better choice?
Key Vault is often the better choice when your workloads are mostly inside Azure, when services need customer-managed keys that Azure resources can use directly, or when your team has little appetite for operating a stateful secrets platform. Its per-operation billing is also simple for low volumes. OpenBao becomes more attractive when operation volumes are high, when you need dynamic secrets, encryption as a service or auth methods beyond Entra ID, when you run workloads across several clouds or on premises, or when licensing and data residency rules matter. Many organizations keep Key Vault for Azure services that require it and use OpenBao for everything else. Confirm which Azure services in your estate depend on Key Vault before deciding.
What to ask for in a fixed-scope quote
A fixed-scope quote for an OpenBao replacement of Key Vault should name each architecture decision explicitly, because each one changes the recurring cost. Ask for the high availability design in writing: which nodes run, where they sit across availability zones or regions, and how the active node and standbys are load balanced. Ask for the storage backend choice between integrated storage (Raft) and PostgreSQL, since the OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft, and that choice determines whether you pay for a database service or for additional cluster nodes and their disks. State whether an HSM is in scope for auto-unseal or key protection, and if it is, which device or cloud service carries the recurring fee. Name the auth method mapping too, for example which Entra ID workloads move to JWT/OIDC, Kubernetes or AppRole, since that mapping sets the size of the identity work.
Migration and operations items drive the one-time effort. Ask for migration waves with a named set of vaults or secrets in each wave, a backup and restore test before any cutover, and a rollback step for each wave. Require that the restore test be a real restore into the OpenBao cluster, not a file check. Ask for handover and documentation covering runbooks, unseal and recovery procedures, and who holds the recovery material. Confirm the OpenBao version the design targets. OpenBao v2.7.1 was released on October 1, 2026 as the current release, so the quote should name that version and state how future minor and patch upgrades are handled. Whether an optional retainer for upgrades, security patches and on-call support is included, or priced separately, should be a line item in the quote rather than an assumption.
Confirm also what the quote excludes. Key material that cannot be exported from Key Vault has to be re-created, and the quote should say who performs that work and whose application changes it covers. Ask the provider to separate one-time costs (design, build, migration, testing, handover) from recurring costs (infrastructure, storage, licenses if any, support), so you can compare them with Key Vault's per-operation billing over the same period. DeployOpen issues quotes only after the written scope is agreed, so compare every proposal against the same list of items.
How DeployOpen scopes a fixed-price OpenBao implementation
DeployOpen plans and implements self-hosted OpenBao inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, so the cost components discussed on this page are written into an agreed scope before any work starts.
How we scope
- Inventory every Key Vault in use, with secret, key, certificate and operation volumes taken from your own logs and billing data
- Agree in writing which workloads move to OpenBao, which stay in Key Vault and which need customer-managed keys
- Define the HSM requirement, storage backend and HA design, which drive the server and operations line items
- Confirm the Azure prices that apply to your agreement and region before comparing totals
How we build
- Deploy OpenBao in your environment with the storage backend and unseal method agreed in the scope
- Configure auth methods for your workloads, replacing managed identity access where the scope requires it
- Test failover, backup restore and secret retrieval paths against the agreed acceptance criteria
- Model the cost by component at your measured volume so the comparison reflects your own usage
How we hand over
- Document the architecture, unseal procedure, backup and restore steps and upgrade path
- Provide a runbook for on-call staff covering routine operations and incident response
- Train your operations team on policies, auth configuration and lease management
- Hand over cost tracking so your team can see recurring server, storage and operations spend
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan OpenBao upgrades against the release notes and migration guidance published by the project
- Schedule periodic restore tests and access reviews as part of the retainer scope if you choose
- Ask for the retainer terms, response expectations and included testing in your written quote
