Vault vs AWS Secrets Manager vs SOPS: Cost Comparison and Selection Criteria

Why “What do you use for secrets?” has no single right answer

Secret-management comparison posts are everywhere, but after reading them you end up right back where you started. Feature tables give Vault an overwhelming number of checkmarks, so it feels like you should adopt Vault—except your team has maybe 30 secrets and 1.5 infrastructure people.

The problem is the comparison criteria. The real cost of choosing a tool is monthly infrastructure bill + ops labor + recovery time when something breaks, yet most comparison tables don’t even calculate the first item. If a 30-secret team stands up a 3-node Vault HA cluster, the labor spent documenting unseal procedures and rehearsing Raft snapshot recovery will dwarf the EC2 bill.

This post judges the three tools on these criteria only:

• Scenario-by-scenario monthly bills, with the formulas shown as-is
• Blast radius when an incident hits at 3 a.m.
• What evidence you can submit in an ISMS-P audit

If you want a deeper look at Kubernetes integration architecture itself, see How to Fully Manage Kubernetes Secret Security Vulnerabilities with Vault and the CSI Driver and Kubernetes Secret Management: Vault vs AWS Secrets Manager Comparison and Optimal Architecture Guide. This post focuses on money and people, not architecture.

These three are different kinds of things to begin with

First thing to get straight: SOPS is not a secret store; it is an encryption format. Vault and ASM are “servers that store secrets and serve them over an API,” while SOPS is “a CLI tool that encrypts only the value portions of YAML/JSON files.” Storage is your Git repository’s job. Miss this difference and the comparison doesn’t even hold.

The decisive axis that splits the field is dynamic secrets. If you actually need “issue a one-hour DB login at request time and auto-revoke it,” there is effectively no choice besides Vault. If you don’t have that requirement, a large share of Vault’s feature-table advantage is value that never gets billed to your team.

Monthly cost: unit prices and formulas, shown as-is

Pricing snapshot: August 2026 / region: Seoul (ap-northeast-2) / on-demand. AWS unit prices can change, so reconfirm on the official AWS pricing page before making a final decision.

The core formulas are three lines:

• AWS Secrets Manager: secret count × $0.40 + (API calls ÷ 10,000) × $0.05
• SOPS + age: If you also use KMS, number of keys × $1.00 + decrypt API call cost. Using age keys only, infrastructure cost is $0
• Vault self-hosted: EC2 instance + EBS + NLB + ops labor (hours/month × hourly rate)

Splitting ops labor into its own row is the point of this calculation. For convenience, hourly rate is set at ₩50,000 (about $36). Plug in your team’s actual labor cost and recalculate.

Scenario 1: 30 secrets / 50,000 API calls / 3 developers

At 30 secrets, Vault’s ops labor ($288) is 13× the infrastructure cost ($21). Standing up Vault in this range is clearly over-investment.

Scenario 2: 300 secrets / 2 million API calls / 15 services

This is where it flips. SOPS infrastructure stays $0, but once you pass 300 secrets and 15 services, the burden of managing “who can decrypt what with which key” via creation_rules in .sops.yaml grows sharply. When a developer joins or leaves, you remove their key from the age recipient list and re-encrypt every file—and that work scales with the number of files.

Empirically, the break-even sits in the 100–150 secret range. ASM cost scales linearly with secret count ($0.40) while ops time barely grows; SOPS costs $0 but ops time grows almost linearly with secret count. You’re trading 150 × $0.40 = $60 for about 1.7 hours of labor—and a single re-encryption pass already exceeds that.

Scenario 3: 1,000 secrets / multi-region, multi-cloud

In this range SOPS drops out not on cost but on operability. If you are AWS-only, ASM is still cheaper; if you are multi-cloud or dynamic credentials are mandatory, Vault’s $1,730 is justified.

Beyond money: learning curve and blast radius

On blast radius alone, SOPS is the safest. Decryption finishes in the deploy pipeline, so there is no runtime dependency. Vault has the largest runtime dependency, which is why Auto-unseal is not optional—it is effectively mandatory. If you run with manual unseal, a 3 a.m. incident means waking three people who each hold one of three unseal key shares at the same time.

Vault’s BSL switch: when it matters and when it doesn’t

In August 2023, HashiCorp changed the license of its major products from MPL 2.0 to the BSL (Business Source License). A community fork, OpenBao, later launched under the Linux Foundation and continues development under an MPL-family license.

The decision rule is surprisingly simple.

• Doesn’t apply: You install Vault internally to manage in-house secrets for your own services → ordinary internal use is not restricted by BSL. Most startups and mid-size companies fall here.
• Needs review: You offer secret-management as a service to customers on top of Vault, or resell it as a core feature of a SaaS product → this can fall under HashiCorp’s “competitive product” interpretation, so legal review is required.

Final interpretation of the license terms must follow the original text and legal review. This section only sketches the direction; confirm against the BSL text and in-house counsel before adopting. If license risk bothers you but you still need Vault’s dynamic secrets, OpenBao is a practical alternative.

Mapping to ISMS-P cryptographic-key management controls

Evidence commonly requested in Korean certification audits is “key generation, storage, rotation, and destruction history” plus “access-control records.”

SOPS’s weakness is clear: it cannot record who read a secret. You have change history, not access history. If an audit item requires read-audit evidence, SOPS alone is likely insufficient—check the original control language first.

On region and support, AWS Secrets Manager is available in Seoul (ap-northeast-2) and offers Korean documentation plus Korean-language response via paid support plans. Vault and SOPS are community-centric; official docs are English-first.

Decision table: five questions

There is also a realistic hybrid: keep application config in Git with SOPS, and put only rotation-needed items like DB passwords in ASM. In the 100–200 secret range, that mix balances cost and ops burden best.

Do this today: five lines to encrypt .env with SOPS

# 1. age 키 생성 (개인키는 절대 커밋 금지)
age-keygen -o ~/.config/sops/age/keys.txt

# 2. 공개키 확인 (age1... 로 시작하는 문자열)
grep "public key" ~/.config/sops/age/keys.txt

# 3. .sops.yaml 작성 — 복수 수신자로 키 분실 대비
cat > .sops.yaml <<'EOF'
creation_rules:
  - path_regex: secrets/.*\.yaml$
    age: >-
      age1abc...개발자A공개키,
      age1def...백업용공개키
EOF

# 4. 평문 YAML 암호화 (값만 암호화, 키 이름은 평문 유지)
sops -e secrets/prod.yaml > secrets/prod.enc.yaml && rm secrets/prod.yaml

# 5. 커밋
git add .sops.yaml secrets/prod.enc.yaml && git commit -m "chore: encrypt prod secrets with SOPS"

Expected result: open secrets/prod.enc.yaml and the key names are readable, values have become ENC[AES256_GCM,data:...], and a sops: metadata block is appended at the bottom. If values are still plaintext, path_regex in .sops.yaml doesn’t match the actual path—fix the path pattern first.

To verify decryption: sops -d secrets/prod.enc.yaml. A no matching creation rules error means a rule mismatch; failed to get the data key means SOPS_AGE_KEY_FILE does not point at the private-key path.

If you use ASM: minimal ESO YAML

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secretsmanager
  namespace: prod
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-northeast-2
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-db-secret
  namespace: prod
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: SecretStore
  target:
    name: app-db-secret
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: prod/app/db
        property: password

After applying, if kubectl get externalsecret -n prod shows STATUS SecretSynced, you’re good. If you see SecretSyncedError, first check that the IRSA service account has secretsmanager:GetSecretValue.

Failure-path checklist (three cases)

1. Vault is sealed and deploys are fully stopped

vault status                      # Sealed: true 확인
vault operator unseal <key-share-1>
vault operator unseal <key-share-2>
vault operator unseal <key-share-3>   # threshold 만큼 반복

Prevention is switching to KMS Auto-unseal. After you configure it, a restart unseals without human intervention.

seal "awskms" {
  region     = "ap-northeast-2"
  kms_key_id = "arn:aws:kms:ap-northeast-2:<account-id>:key/<key-id>"
}

2. You lost the age private key

There is no recovery. Prevention is the only answer. Specify multiple recipients at encrypt time.

sops -e --age "age1개발자키,age1백업키,age1CI키" secrets/prod.yaml > secrets/prod.enc.yaml
# 이미 암호화된 파일에 수신자 추가
sops updatekeys secrets/prod.enc.yaml

3. You deleted an ASM secret and cannot recreate it under the same name

ASM uses a 7–30 day recovery window by default, so a name in that window cannot be reused.

# 복구 (권장)
aws secretsmanager restore-secret --secret-id prod/app/db --region ap-northeast-2

# 즉시 완전 삭제 후 재생성 — 복구 불가, 신중히
aws secretsmanager delete-secret --secret-id prod/app/db \
  --force-delete-without-recovery --region ap-northeast-2

FAQ

Q. At what secret count should you move to AWS Secrets Manager? A. On infrastructure cost alone SOPS is always cheaper, but once you convert ops time to labor cost the crossover is in the 100–150 secret range. At 150 secrets, ASM is 150 × $0.40 = $60; at that scale, SOPS re-encryption and key management already exceed two hours a month.

Q. Do we have to rip out Vault because of the BSL change? A. Internal use for running your own services is generally fine. Legal review is needed only if you provide or resell secret-management to customers on top of Vault. If you want to avoid license risk entirely, the OpenBao fork is the alternative.

Q. Can SOPS alone pass ISMS-P cryptographic-key management controls? A. You can submit change history (Git commits), but there is no read history. If a control requires access/read audit, SOPS alone may not be enough. Check the original control language and, if needed, consider pairing ASM (CloudTrail) or a Vault audit device.