Every application needs secrets — database passwords, API keys, encryption keys, certificates. The question is where to store them and how to deliver them to applications securely.
Three solutions dominate: HashiCorp Vault (self-managed, multi-cloud, feature-rich), AWS Secrets Manager (managed, AWS-native, simple), and Azure Key Vault (managed, Azure-native, combines secrets + keys + certs). They solve the same core problem but with fundamentally different architectures and trade-offs.
Architecture Comparison
HashiCorp Vault
Philosophy: Universal secrets management. Works everywhere. You manage it.
┌─────────────────────────────────────────┐
│ HashiCorp Vault (self-managed cluster) │
├─────────────────────────────────────────┤
│ Secrets Engines: │
│ • KV (static secrets) │
│ • Database (dynamic credentials) │
│ • PKI (certificate issuance) │
│ • Transit (encryption as a service) │
│ • SSH (signed keys/OTP) │
│ • AWS/Azure/GCP (dynamic cloud creds) │
├─────────────────────────────────────────┤
│ Auth Methods: │
│ • Kubernetes, AWS IAM, Azure AD │
│ • LDAP, OIDC, AppRole, Tokens │
├─────────────────────────────────────────┤
│ Storage: Consul, Raft, S3, DynamoDB │
└─────────────────────────────────────────┘
↕ API (HTTP)
Any cloud, any platform, any languageAWS Secrets Manager
Philosophy: Managed secrets for AWS workloads. Zero ops. Deep AWS integration.
┌─────────────────────────────────────────┐
│ AWS Secrets Manager (fully managed) │
├─────────────────────────────────────────┤
│ Features: │
│ • Store secrets (key-value, JSON) │
│ • Automatic rotation (Lambda-based) │
│ • Cross-account sharing │
│ • Versioning │
│ • Integration with RDS, Redshift, etc. │
├─────────────────────────────────────────┤
│ Auth: IAM roles and policies │
│ Encryption: AWS KMS (automatic) │
│ Audit: CloudTrail │
└─────────────────────────────────────────┘
↕ AWS SDK / API
AWS services (Lambda, ECS, EC2, EKS)Azure Key Vault
Philosophy: Unified secrets + keys + certificates for Azure. One service for all crypto needs.
┌─────────────────────────────────────────┐
│ Azure Key Vault (fully managed) │
├─────────────────────────────────────────┤
│ Object Types: │
│ • Secrets (passwords, connection strings)│
│ • Keys (RSA, EC — for encryption/signing)│
│ • Certificates (full lifecycle mgmt) │
├─────────────────────────────────────────┤
│ Auth: Azure AD / Managed Identity │
│ Tiers: Standard (software) / Premium (HSM)│
│ Audit: Azure Monitor / Diagnostic Logs │
└─────────────────────────────────────────┘
↕ Azure SDK / REST API
Azure services (App Service, AKS, VMs)Feature Comparison
| Feature | Vault | AWS Secrets Manager | Azure Key Vault |
|---|---|---|---|
| Deployment | Self-managed (or HCP Vault Cloud) | Fully managed | Fully managed |
| Multi-cloud | ✅ (any cloud, on-prem, hybrid) | ❌ (AWS only) | ❌ (Azure only) |
| Dynamic secrets | ✅ (DB creds, cloud creds, PKI) | ⚠️ (rotation via Lambda) | ❌ |
| PKI/Certificate issuance | ✅ (full CA capability) | ❌ (use ACM separately) | ✅ (certificate lifecycle) |
| Encryption as a service | ✅ (Transit engine) | ❌ (use KMS separately) | ✅ (Key operations) |
| SSH secrets | ✅ (signed keys, OTP) | ❌ | ❌ |
| Secret rotation | ✅ (built-in for dynamic secrets) | ✅ (Lambda-based) | ✅ (auto-rotation for some types) |
| Versioning | ✅ (KV v2) | ✅ | ✅ |
| Access control | Policies (HCL) | IAM policies | RBAC + access policies |
| Audit logging | ✅ (built-in audit device) | ✅ (CloudTrail) | ✅ (Diagnostic Logs) |
| Kubernetes integration | ✅ (Vault Agent, CSI driver) | ✅ (ASCP, CSI driver) | ✅ (CSI driver, Pod Identity) |
| Namespaces/multi-tenancy | ✅ (Enterprise) | ❌ (use separate accounts) | ❌ (use separate vaults) |
| Disaster recovery | ✅ (replication, snapshots) | ✅ (managed by AWS) | ✅ (managed by Azure) |
| Open source | ✅ (BSL license since 2023) | ❌ | ❌ |
Pricing Comparison
Scenario: 200 secrets, 500,000 API calls/month
| Component | Vault (self-managed) | AWS Secrets Manager | Azure Key Vault |
|---|---|---|---|
| Secret storage | $0 (self-hosted) | $80/mo (200 × $0.40) | $0 (no per-secret charge) |
| API calls | $0 (self-hosted) | $2.50/mo (500K × $0.05/10K) | $1.50/mo (500K × $0.03/10K) |
| Infrastructure | ~$200-500/mo (3-node cluster on EC2/GKE) | $0 | $0 |
| Operations (staff time) | ~$2,000-5,000/mo (partial FTE) | $0 | $0 |
| Monthly total | $200-5,500 | $82.50 | $1.50 |
Scenario: HCP Vault Cloud (managed Vault)
| Component | HCP Vault (Starter) | HCP Vault (Standard) | HCP Vault (Plus) |
|---|---|---|---|
| Monthly cost | $0.03/hr (~$22/mo) | $0.50/hr (~$365/mo) | $1.58/hr (~$1,150/mo) |
| Includes | 25 clients | Unlimited clients | HA, DR, namespaces |
Key insight: If you’re single-cloud (AWS or Azure only), the native service is dramatically cheaper and simpler. Vault’s value is multi-cloud, dynamic secrets, and PKI — features the native services don’t have.
Dynamic Secrets: Vault’s Killer Feature
Vault’s most powerful capability is dynamic secrets — credentials generated on-demand with automatic expiry:
# Request database credentials (Vault generates unique user/pass with 1-hour TTL)
vault read database/creds/readonly
# Key Value
# lease_id database/creds/readonly/abc123
# lease_duration 1h
# username v-app-readonly-xK7s2
# password A1b2C3d4E5f6G7h8
# After 1 hour: Vault automatically revokes the credentials (deletes the DB user)
# No rotation needed — credentials are born, used, and die automaticallyWhy this matters:
- No long-lived credentials to steal
- No rotation procedures to maintain
- Each application instance gets unique credentials (audit trail)
- Compromised credentials expire automatically (limited blast radius)
- Works for: PostgreSQL, MySQL, MongoDB, AWS IAM, Azure AD, GCP, SSH, and more
AWS Secrets Manager can rotate secrets (via Lambda functions), but it’s not the same — rotation replaces one long-lived secret with another. Vault’s dynamic secrets are ephemeral by design.
Decision Framework
Are you single-cloud (AWS only)?
├── Yes → AWS Secrets Manager (simplest, cheapest, deepest integration)
└── No →
Are you single-cloud (Azure only)?
├── Yes → Azure Key Vault (secrets + keys + certs in one service)
└── No →
Do you need dynamic secrets, PKI, or multi-cloud?
├── Yes → HashiCorp Vault (most capable, most complex)
└── No →
Use the native service of your primary cloud
+ consider Vault later as complexity growsChoose AWS Secrets Manager When:
- You’re all-in on AWS
- You need simple secret storage and retrieval
- You want zero operational overhead
- RDS/Redshift credential rotation is your primary use case
- Budget is a concern (cheapest for AWS workloads)
Choose Azure Key Vault When:
- You’re all-in on Azure
- You want secrets + keys + certificates in one service
- You need HSM-backed keys (Premium tier)
- Microsoft 365 / Entra ID integration matters
- You want the cheapest option overall ($0 per secret)
Choose HashiCorp Vault When:
- You’re multi-cloud or hybrid (AWS + Azure + GCP + on-prem)
- You need dynamic secrets (short-lived, auto-expiring credentials)
- You need a built-in PKI/CA (Vault PKI secrets engine)
- You need encryption as a service (Transit engine)
- You need SSH credential management
- You want a single secrets platform across all environments
- You have the team to operate it (or use HCP Vault Cloud)
The Hybrid Pattern
Many organizations use both Vault and a cloud-native service:
HashiCorp Vault:
• Dynamic database credentials (PostgreSQL, MySQL)
• PKI certificate issuance (internal mTLS)
• SSH signed keys
• Cross-cloud secrets (shared between AWS and GCP)
• Encryption as a service (Transit engine)
AWS Secrets Manager:
• RDS master passwords (native rotation)
• Lambda function secrets
• ECS task secrets
• Secrets that only AWS services need
Azure Key Vault:
• App Service connection strings
• AKS pod secrets
• Azure-specific API keys
• Certificates for Azure servicesThis gives you Vault’s power for complex use cases and cloud-native simplicity for straightforward ones.
FAQ
Q: Is Vault still open source after the BSL license change? A: Vault’s source code is available under the Business Source License (BSL). You can use it freely for most purposes. The restriction: you can’t offer Vault as a managed service competing with HashiCorp. For internal use, it’s effectively the same as before. OpenBao is a community fork under MPL if you need a fully open-source alternative.
Q: Can I use AWS Secrets Manager from outside AWS? A: Technically yes (via AWS SDK with IAM credentials), but it’s not designed for this. Latency, authentication complexity, and cost make it impractical for non-AWS workloads. Use Vault for multi-cloud.
Q: What about GCP Secret Manager? A: Similar to AWS Secrets Manager — managed, simple, GCP-native. Good for GCP-only workloads. Doesn’t have dynamic secrets, PKI, or multi-cloud support. Choose it if you’re GCP-only and need simple secret storage.
Q: How do I migrate from one to another? A: Secrets are just key-value pairs. Export from source, import to destination. The challenge is updating all applications to use the new API/SDK. Plan for a parallel-run period where both systems are active, then cut over application by application.
Q: Which is most secure? A: All three encrypt secrets at rest (AES-256) and in transit (TLS). The security difference is in access control granularity and audit capabilities. Vault has the most granular policies. Cloud services rely on IAM (which is powerful but different). The biggest security risk with any secrets manager is misconfigured access policies — not the platform itself.