Secrets Management: Vault vs AWS Secrets Manager vs External Secrets

Hardcoded secrets are the most common serious mistake I find in code reviews. The fix is a real secrets manager, but "which one?" trips teams up. Here's how Vault, AWS Secrets Manager, and the External Secrets Operator actually compare, and how they fit together.

The baseline rule

Secrets never live in: code, env files in Git, container images, or CI logs. They live in a secrets store and are fetched at runtime by an identity that's authorized for exactly those secrets. Whatever tool you pick, that's the goal.

AWS Secrets Manager

AWS's managed secrets store.

• Strengths: zero ops, tight AWS IAM integration, automatic rotation for RDS and others, encryption via KMS, audited through CloudTrail.
• Weaknesses: AWS-only, per-secret cost adds up at scale, less flexible than Vault for dynamic secrets.
• Use when: you're on AWS and want managed simplicity. For most AWS shops, this is the right default.

HashiCorp Vault

The most powerful and flexible option, and the most to operate.

• Strengths: multi-cloud and on-prem, dynamic secrets (generates short-lived DB/cloud creds on demand), encryption-as-a-service, fine-grained policies, many auth methods (K8s, OIDC, etc.).
• Weaknesses: you run it: HA, unsealing, upgrades, backups. Real operational weight.
• Use when: multi-cloud/hybrid, you need dynamic secrets, or you want one secrets plane across everything. (My vault-on-kubernetes repo runs it HA with Raft.)

External Secrets Operator (ESO)

Not a store, a bridge. It syncs secrets from a backend (Secrets Manager, Vault, GCP Secret Manager, etc.) into native Kubernetes Secret objects.

• Strengths: your apps just read normal K8s Secrets; the source of truth stays in your real store; supports many backends; declarative (ExternalSecret CRDs).
• Weaknesses: secrets do land as K8s Secrets (base64, not encrypted at rest unless you enable it), pair with encryption at rest and tight RBAC.
• Use when: you run Kubernetes and want apps to consume secrets natively without each app integrating an SDK.

How they fit together

These aren't mutually exclusive, the common production pattern is:

AWS Secrets Manager (or Vault)  ← source of truth, rotation, audit
        │
External Secrets Operator       ← syncs into the cluster
        │
Kubernetes Secret               ← app reads it normally

You get managed rotation + audit at the source, and dev-friendly native consumption in the cluster.

Decision shortcut

• AWS-only, want simple + rotation: AWS Secrets Manager (+ ESO if on Kubernetes).
• Multi-cloud / need dynamic secrets / one plane: Vault (+ ESO or the agent injector).
• On Kubernetes, want apps to read native Secrets: External Secrets Operator over your chosen backend.

Whatever you choose, do these

• Least-privilege access: each workload reaches only its own secrets.
• Rotation: short-lived or rotated credentials beat permanent ones.
• Audit: know who/what read which secret and when.
• Scan for leaks: gitleaks/trufflehog in CI so a secret never reaches the repo in the first place (see my devsecops-starter-kit).

The best secrets manager is the one you'll actually operate correctly. For most AWS teams that's Secrets Manager; for multi-cloud and dynamic secrets it's Vault; on Kubernetes, ESO ties it together.

---

Hardening how your team handles secrets? That's part of my DevSecOps consulting, get in touch.