Secrets management seems like it should be simple: store sensitive values securely, retrieve them when needed. In practice, organizations tie themselves in knots choosing between tools, over-engineering solutions, or—worse—keeping secrets in places that aren’t secure at all.
We’ve implemented all three of these tools across different organizations. Here’s when each makes sense and what you’re actually signing up for.
The Contenders
HashiCorp Vault is a full-featured secrets management platform. It handles static secrets, generates dynamic credentials, encrypts data, manages PKI infrastructure, and integrates with basically everything. It’s powerful and complex.
AWS Secrets Manager is AWS’s managed secrets service. It stores secrets, handles rotation for supported services, and integrates tightly with AWS IAM and other AWS services. It’s simpler than Vault and fully managed.
SOPS (Secrets OPerationS) is Mozilla’s tool for encrypting files. It encrypts secrets in config files that can live in version control alongside your code. It’s lightweight and developer-friendly.
These aren’t direct competitors—they solve related but different problems and sit at different points on the complexity spectrum.
HashiCorp Vault
Vault is the Swiss Army knife of secrets management. It can do almost anything you need, which is both its strength and its challenge.
What Vault does well:
- Dynamic secrets: Instead of storing database passwords, Vault can generate short-lived credentials on demand. Applications request access, Vault creates a temporary credential, and it’s automatically revoked after use.
- Secrets engines: Vault has engines for AWS credentials, database credentials, SSH certificates, PKI, and more. It becomes a central platform for all credential management.
- Encryption as a service: Applications can use Vault to encrypt data without handling encryption keys directly.
- Multi-cloud and on-prem: Vault doesn’t care about your infrastructure provider. It works everywhere.
- Audit logging: Comprehensive audit trails for who accessed what and when.
The operational reality:
Vault requires significant operational investment. You’re running a critical piece of infrastructure that, if it goes down, can block applications from starting. This means:
- High-availability clusters with multiple nodes
- Secure storage backend (Consul, Raft, or cloud storage)
- Unsealing procedures after restarts (or auto-unseal configuration)
- Backup and disaster recovery planning
- Monitoring and alerting
- Ongoing upgrades and security patches
We’ve seen organizations adopt Vault, underestimate the operational burden, and end up with an unreliable secrets infrastructure that’s worse than what they had before. Vault done well requires dedicated attention.
When Vault makes sense:
- You need dynamic secrets and automated credential rotation at scale
- You’re multi-cloud or on-prem and need a vendor-neutral solution
- You have complex secrets requirements (PKI, SSH certificates, etc.)
- You have the team capacity to operate Vault reliably
- You’re already using other HashiCorp tools (Terraform, Consul) and want ecosystem coherence
When Vault is overkill:
- You’re primarily on AWS and could use Secrets Manager
- Your secrets needs are straightforward (static API keys and passwords)
- You don’t have the operational capacity to run Vault well
- The complexity isn’t justified by your threat model
AWS Secrets Manager
Secrets Manager is AWS’s answer to “we just need to store secrets and not have them in environment variables or config files.” It’s simple, managed, and good at what it does.
What Secrets Manager does well:
- Fully managed: AWS handles availability, durability, and encryption. No infrastructure for you to operate.
- IAM integration: Access control through IAM policies you’re already using.
- Automatic rotation: Built-in rotation for RDS databases, Redshift, DocumentDB, and extensible to other secrets via Lambda functions.
- SDK integration: Easy to retrieve secrets from application code.
- Cross-account access: Secrets can be shared across AWS accounts with proper IAM configuration.
The operational reality:
Secrets Manager is operationally straightforward. Secrets are stored, encrypted with KMS, and available through the API. The main considerations are:
- Cost: $0.40 per secret per month plus API call charges. This adds up with many secrets.
- Latency: Retrieving secrets adds API calls. Cache secrets in your application to avoid latency and cost.
- AWS dependency: You’re fully in the AWS ecosystem.
- Rotation complexity: Built-in rotation works for supported databases. Custom rotation requires Lambda functions that can be fiddly to get right.
When Secrets Manager makes sense:
- You’re primarily on AWS and want to stay in the AWS ecosystem
- Your secrets needs are straightforward
- You want managed infrastructure without operational burden
- You’re already using IAM extensively and want to leverage that for secrets access
- Rotation for RDS databases is important to you
When Secrets Manager falls short:
- You’re multi-cloud and need consistent secrets management across providers
- You need dynamic secrets beyond what rotation provides
- You have on-prem workloads that need secrets
- Cost becomes prohibitive with thousands of secrets
SOPS
SOPS takes a different approach: instead of a centralized secrets service, it encrypts secrets within files that live in your repository alongside code and configuration.
What SOPS does well:
- GitOps-friendly: Encrypted secrets live in version control. Changes are tracked, reviewed, and deployed through normal git workflows.
- No additional infrastructure: SOPS is a CLI tool. Decryption happens using existing key management (AWS KMS, GCP KMS, Azure Key Vault, PGP).
- Partial encryption: SOPS encrypts values but leaves keys in plaintext, so you can see the structure of your secrets files without decrypting.
- Editor integration: You can edit encrypted files directly with
sops filename.yaml. - Simple mental model: Secrets are files. Decrypt them when you need them.
The operational reality:
SOPS is lightweight by design. The main considerations are:
- Key management: SOPS encrypts with keys stored elsewhere (KMS, PGP). You still need to manage those keys.
- Decryption at runtime: Applications need a way to decrypt secrets. This might mean SOPS in CI/CD, sidecar containers, or init scripts.
- Rotation: SOPS doesn’t rotate secrets for you. You’re back to manual processes or custom tooling.
- Git history: Encrypted secrets in git means rotating the encryption key doesn’t remove old encrypted values from history.
When SOPS makes sense:
- You want secrets in version control with GitOps workflows
- You have a small number of secrets that don’t change frequently
- You’re already using cloud KMS and want to leverage it
- You want minimal operational overhead
- You value the auditability of git history for secrets changes
When SOPS falls short:
- You need dynamic secrets or automated rotation
- You have hundreds of secrets across many services
- You need centralized access control and audit logging beyond git
- Your applications need runtime secrets management beyond “decrypt at startup”
Combining Approaches
These tools aren’t mutually exclusive. Common combinations:
SOPS + AWS Secrets Manager: Use SOPS for configuration secrets in GitOps workflows, Secrets Manager for database credentials with rotation. Each tool does what it’s good at.
Vault + AWS Secrets Manager: Vault for dynamic secrets and complex use cases, Secrets Manager for simpler AWS-native workloads. Reduces Vault’s scope and operational burden.
SOPS for development, Secrets Manager for production: Developers use SOPS for local and staging environments where rotation isn’t critical. Production uses Secrets Manager for managed rotation and availability.
Don’t feel you need one tool for everything. Use the right tool for each context.
The Decision Framework
Start with your requirements:
Do you need dynamic secrets (credentials generated on demand, automatically revoked)?
- Yes → Vault is probably necessary
- No → Simpler options may suffice
Are you primarily on AWS?
- Yes → Secrets Manager should be your default; add complexity only if needed
- No → Consider Vault or SOPS depending on complexity needs
Do you want secrets in version control with GitOps workflows?
- Yes → SOPS is worth considering, possibly alongside another tool
Do you have operational capacity for running infrastructure?
- Yes → Vault is an option
- No → Prefer managed services or lightweight tools
How many secrets are you managing?
- Dozens → Any tool works; simplicity wins
- Hundreds or thousands → Consider cost, management overhead, and organizational structure
The honest take:
Most organizations don’t need Vault’s complexity. They need to stop putting secrets in environment variables and plaintext config files. For that, AWS Secrets Manager (if you’re on AWS) or SOPS (if you want GitOps) gets you 80% of the value with 20% of the complexity.
Vault becomes compelling when you need its advanced capabilities—dynamic secrets, sophisticated access control, multi-cloud consistency—and you have the operational capacity to run it well. Running Vault poorly is worse than not running it at all.
A Practical Starting Point
If you’re starting from scratch or cleaning up an existing mess:
Get secrets out of code and config files. This is the baseline. Any of these tools accomplishes it.
Start with the simplest tool that meets your needs. SOPS if you want git-based management. Secrets Manager if you’re AWS-native.
Add complexity when requirements demand it. Vault is there when you need it. You’ll know when that is.
Plan for rotation. Whatever tool you choose, have an answer for how secrets get rotated. The hardest breaches to contain are the ones where compromised credentials were never rotated.
Secrets management doesn’t have to be complicated. Match the tool to your actual needs, not the most sophisticated thing you could theoretically use.