AWS Secrets Manager vs HashiCorp Vault vs External Secrets Operator 2026

Secrets management is one of those decisions that's painful to reverse. Pick the wrong tool and you're either locked into AWS forever or managing a complex Vault cluster nobody wants to operate.

Here's the honest comparison.

The Three Tools at a Glance

AWS Secrets Manager — Managed service, stores and rotates secrets, AWS-native
HashiCorp Vault — Self-hosted (or HCP Vault), powerful, complex, vendor-neutral
External Secrets Operator (ESO) — Kubernetes operator that syncs secrets from any backend into Kubernetes Secrets

These aren't really competing — ESO is often used WITH Secrets Manager or Vault to bridge the gap into Kubernetes.

AWS Secrets Manager

What it does

• Stores secrets (API keys, DB passwords, certs) in AWS
• Auto-rotates secrets (native integration with RDS, Redshift)
• Fine-grained IAM policies per secret
• Versioning and audit trail via CloudTrail

Pricing

$0.40/secret/month + $0.05 per 10,000 API calls

A team with 100 secrets = ~$40/month. Adds up in large orgs.

Getting secrets into Kubernetes

AWS Secrets Manager doesn't natively push secrets into Kubernetes. Options:

Option 1: AWS Secrets and Config Provider (ASCP)

# SecretProviderClass
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "prod/db-password"
        objectType: "secretsmanager"

Option 2: External Secrets Operator (ESO) — more Kubernetes-native, covered below

Best for

• AWS-only teams who want zero ops overhead
• RDS password rotation (built-in integration)
• Teams already deep in AWS IAM

HashiCorp Vault

What it does

• Secret storage (KV, dynamic secrets, PKI, SSH)
• Dynamic secrets — generates DB credentials on demand, auto-expires
• Identity-based auth (Kubernetes auth, AWS IAM, GitHub, LDAP)
• Works on any cloud or on-prem

Dynamic secrets — the killer feature

# Vault generates a unique DB user for each service
# Credentials auto-expire after TTL
 
vault read database/creds/my-role
# Key                Value
# lease_duration     1h
# username           v-k8s-app-AbCdEf
# password           A1B2C3-auto-generated

Each microservice gets unique credentials. If one is compromised, blast radius is limited.

Kubernetes integration

# Vault Agent Injector — sidecars inject secrets as files
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "my-app"
  vault.hashicorp.com/agent-inject-secret-db-password: "secret/db"

Pricing

• Open source: Free (self-hosted)
• HCP Vault Dedicated: ~$1.58/hour for dev cluster
• Enterprise: Contact sales

Best for

• Multi-cloud or hybrid environments
• Teams needing dynamic secrets (auto-rotating DB creds)
• Organizations with strict compliance (SOC2, PCI-DSS)
• Platform teams who can operate it

The honest downside

Vault has a learning curve and operational overhead. Someone has to manage the cluster, handle unsealing, upgrades, HA setup. If you don't have a platform team, this becomes a burden.

External Secrets Operator (ESO)

What it does

ESO is a Kubernetes operator that connects to external secret backends and syncs secrets into native Kubernetes Secrets.

Think of it as a bridge:

AWS Secrets Manager / Vault / GCP Secret Manager
              ↓  ESO syncs
        Kubernetes Secret
              ↓
         Your Pod

Why this matters

Your app doesn't need to know WHERE secrets come from. It just reads a Kubernetes Secret as normal. You can swap backends without changing app code.

Setup with AWS Secrets Manager

# SecretStore
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secretsmanager
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
---
# ExternalSecret — syncs to K8s Secret
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
  target:
    name: db-credentials   # creates this K8s Secret
  data:
    - secretKey: password
      remoteRef:
        key: prod/db-password

Best for

• Any team using Kubernetes who wants secrets as native K8s Secrets
• Multi-cloud teams (ESO supports 20+ backends)
• Teams who want to abstract away the secret backend

Head-to-Head Comparison

What to Choose

Just on AWS, small team → AWS Secrets Manager + ESO
Simple, managed, no ops burden. Pay per secret.

Multi-cloud or need dynamic secrets → Vault + ESO
More powerful but someone needs to run it.

Already using AWS but want K8s-native secrets → ESO + Secrets Manager
Best of both worlds. Backend can be swapped later.

No platform team, just want it to work → AWS Secrets Manager directly
Simplest path, accept the AWS lock-in.

Practical Setup: ESO + AWS Secrets Manager (Recommended Pattern)

# Install ESO
helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace
 
# Create IAM role for ESO (using IRSA)
# Attach policy: secretsmanager:GetSecretValue, secretsmanager:DescribeSecret

Then create ClusterSecretStore (cluster-wide) or SecretStore (namespace-scoped) pointing to AWS, and ExternalSecret objects per namespace.

This pattern gives you centralized secret storage in AWS with zero app-level changes — pods just see Kubernetes Secrets.

For hands-on Vault practice, KodeKloud's Vault course walks through setup, policies, dynamic secrets, and Kubernetes integration from scratch.