Switched from Vault to Azure Key Vault - here's why the team revolted

I'm a vendor management lead at a mid-size financial services company with about 1,200 employees, where I handle all our SaaS and cloud service contracts; my team directly manages both HashiCorp Vault Enterprise and Azure Key Vault for different workloads across our hybrid Azure and AWS environment.

* **Policy and Secret Model Granularity:** Vault's path-based, dynamic secret leasing, and identity-based access policies are fundamentally different from AKV's flat, static secret and key objects with attached Azure RBAC. We can replicate about 60-70% of our policies in AKV, but the remaining 30% for complex, multi-tier applications required significant architectural changes. AKV's access policies apply to an entire key, secret, or certificate object, not to versions or specific operations within a path hierarchy.
* **Real Cost Beyond Base SKU:** The operational cost shift is significant. With Vault, our major costs are the annual Enterprise license and the compute for self-managed clusters. With AKV, the base storage and transaction fees are predictable, but the real cost emerges from integration: every authenticated request from an Azure service (like a Function App or Logic App) is a transaction, and at scale in a microservices architecture, we saw our estimated monthly cost double from the initial projection after full migration due to request volume.
* **Deployment and Management Burden:** The burden shifts rather than disappears. AKV eliminates infrastructure patching and clustering logic, true. However, the management burden moves to Azure Policy, ARM/Bicep/ Terraform module sprawl, and meticulous Azure RBAC assignment at the subscription and resource group level. For a team of 5 platform engineers, we spent roughly 80 fewer hours a year on vault server upkeep but added about 60 hours a year on RBAC audit and cleanup cycles.
* **Enterprise Readiness and Audit:** Vault Enterprise's detailed audit logs, including every request and response payload (which we could ship to a segregated SIEM), were a compliance requirement for us. Azure Key Vault's diagnostic logs only provide metadata about the operation and identity, not the secret material itself. This meant we had to get a specific exception from our internal audit team, which required a compensating control review that took three months.

Given your team's revolt over policy granularity, I'd stick with Vault for any complex, multi-cloud, or on-prem secret management where you need dynamic secrets or extremely fine-grained control. I'd only recommend a full switch to Azure Key Vault if your use case is purely Azure-native, your policy needs are simple (think "this app can read this secret"), and your compliance team accepts its logging limitations. To make a clean call, tell us your peak transactions-per-second and whether your auditors require full request/response audit logging.

You've nailed the core issue on policy granularity. The shift from Vault's path-based model to AKV's object-level RBAC isn't just a syntax change; it's a fundamental constraint on secret organization. It forces a proliferation of key vaults to achieve any semblance of separation, which then multiplies your management overhead and cost.

We hit this exact wall. A single application with secrets for its API, database, and caching layer went from one Vault path with three distinct policies to requiring three separate Azure Key Vaults. The Azure AD integration is great until you're managing hundreds of key vault resource IDs in your IaC because you can't segment cleanly within a single instance.

The billing might be one line item, but the operational tax of managing the sprawl to compensate for the policy model is real.

The policy model divergence you encountered is a well-documented trade-off in cloud vendor benchmarks. The granularity loss isn't just about syntax; it fundamentally changes your security boundaries and forces a different cost structure. For a team used to Vault's model, moving to AKV often means redesigning secret lifecycles, not just migrating them.

Your example with staging and prod paths is instructive. In AKV, you'd need separate vaults or a much flatter naming convention like `prod-app-db-connection` and `staging-app-db-connection`, then manage RBAC on each individual secret object. The operational overhead for policy updates scales linearly with the number of distinct access patterns, whereas in Vault a single policy update on a path can cover hundreds of secrets.

We quantified this in a transition last year: our policy management time increased by roughly 40% because we were managing permissions on individual secret objects instead of paths. The "simplified billing" line item also obfuscates the real cost, which is the engineering time spent working around the flat model.

Exactly. The real metric is operational velocity, not the Azure bill.

That 40% increase in policy management time is a direct hit to team productivity. Leadership sees the consolidated billing but misses the engineering tax. You're now paying for developer hours to manage secret sprawl instead of building features.

This is why cloud vendor benchmarks are useless. They measure features, not outcomes. The cost isn't the line item, it's the slowdown.