自建方案 vs 云原生方案：什么时候该用自建Vault，什么时候直接上云服务？
这个话题，我几乎在每个客户那里都会被问到。说白了，这是个灵魂拷问：到底是我自己搭一套HashiCorp Vault，还是直接用云厂商的Secrets Manager？
我的答案从来都不是二选一。你想想看，一个跨国企业，可能AWS上跑着电商业务，Azure上挂着AD，GCP上做着AI训练。这时候你非要统一用一种方案，不是跟自己过不去吗？
下面这张图，是我这些年总结出来的决策框架。先有个整体印象，我们再细聊。
核心决策因素：控制力 vs 运维成本
先说说最关键的判断依据。我个人习惯把它看作一道算术题：你愿意投入多少人手，去换取多大的控制权？
我在一个金融客户那里遇到过这样的情况：合规要求所有密钥必须由公司自有硬件生成、存储，连云厂商的HSM都不能用。你说这时候能用AWS Secrets Manager吗？不行。只能用自建Vault，后面接自己的HSM。这种情况下，控制力就是硬门槛，没得商量。
| 维度 | SaaS 原生（AWS Secrets Manager） | 托管 Vault（HCP Vault） | 自建 Vault |
|---|---|---|---|
| 运维投入 | 几乎为零 | 少量（升级、配置） | 1-2 名专职 SRE |
| 控制力 | 弱（厂商锁定） | 中等 | 完全控制 |
| 定制化 | 无 | 有限（插件受限） | 完全开放 |
| 合规灵活度 | 依赖厂商认证 | 依赖厂商 + 部分自控 | 全链条可审计 |
| 月度成本（1000条Secrets） | 约 $400 | 约 $800 | 服务器 + 人力 ≈ $2000+ |
什么时候必须自建 Vault？
我用四个具体场景来说清楚。
1. 合规压着你，你必须控制密钥生命周期
比如 PCI-DSS、FedRAMP 或者你自己的内部审计要求。有些审计员明确要求「密钥的生成、轮换、销毁必须在客户自有环境中完成」。云厂商的托管服务虽然也有审计日志，但密钥其实还是在厂商的HSM里。审计员不认。
这时候自建 Vault，配合自有的 HSM 或 KMS，是唯一解。
2. 你需要高度定制
标准的 Secrets Manager 只支持静态密钥、自动轮转。但你的场景可能是：
- 动态数据库凭证（每次连接自动生成临时用户）
- SSH 证书自动签发
- 自定义审计插件，把每一次访问记录写入自建的 SIEM
云厂商的服务不会给你这些能力。自建 Vault 的插件系统就是为了干这个的。
3. 你想把它做成公司的内部平台
我见过一个互联网公司，把所有基础设施的凭证、数据库密码、、MFA 全部交给自建 Vault，然后对外封装了一层 Web 控制台，给内部所有开发团队用。这就是把 Secrets 管理变成了可复用的平台能力。你用云服务很难做到这种「可变现资产」的程度。
4. 甚至你愿意为「出问题」负责
自建 Vault 意味着：
- HA 架构你得自己搭
- 灾备切换你得自己写脚本
- 出故障了，你（或者你的团队）得凌晨爬起来修
如果你的团队有这个能力和觉悟，那就自建。否则，别勉强。
什么时候直接上云服务？
反过来，有些场景我觉得直接上云服务，省心省力，性价比很高。
1. 你只有一个小团队，甚至就你一个人
我接触过不少初创公司，整个 DevOps 就两三号人。这时候你去搭一套 Vault，从安装、配置、TLS、存储后端、HA、监控、升级……全走一遍，至少要一个月。而且你心里还没底：万一挂了怎么办？
不如直接买云服务，两天集成完，剩下的时间去搞业务。
2. 你的应用和云厂商深度绑定
如果你的应用全部跑在 AWS 上，EC2 自动从 Secrets Manager 拿 RDS 密码，Lambda 直接读 。那用 AWS Secrets Manager 是天作之合。
你再自建一个 Vault，还要考虑怎么打通 IAM 角色。这不是给自己找麻烦吗？
3. 你的预算逻辑是「买服务比养人划算」
算一笔简单的账：
- AWS Secrets Manager: 每 10000 条密钥每月 $400，加上 API 调用费
- 自建 Vault: 3 台 EC2（至少 c5.large），加上 RDS（存储后端），加上专职 SRE 一个人（年薪折合每月 30000？），每个月至少 35000+
当然，规模上去以后自建会更便宜。但如果你就管理几百几千条密钥，云服务是省钱的。
4. 你希望降低运维复杂度
你想想看，Vault 的存储后端选 consul 还是 raft？TLS 证书怎么自动续？性能达到瓶颈了该怎么扩？迁移版本时怎么保证不停服？
这些问题，用云服务全都不用担心。厂商帮你兜底了。对于很多非核心业务系统，这个「不用操心」本身就值回票价。
真正的艺术：混合策略
大多数成熟团队的最终方案，其实不是非黑即白。我就说说我在一个中型电商公司看到的真实案例：
- 核心支付链路：自建 Vault + 自有 HSM，密钥 100% 自控，满足 PCI-DSS
- 业务应用（RDS 密码、）：AWS Secrets Manager，通过 Vault 的 AWS Secret Engine 动态生成并自动注入
- 测试环境：直接用 AWS Parameter Store，便宜，不要求高可用
你看，三个场景三种方案。自建 Vault 作为中心控制平面，负责高安全需求的密钥；云服务处理大量低敏感、高频率的调用；Parameter Store 存非机密配置。这种分层的做法，兼顾了安全、成本和效率。
避坑指南：我踩过最大的坑
我曾经帮一家公司从自建 Vault 迁移到 AWS Secrets Manager。听起来很简单是吧？结果审计发现问题了：
- 旧的 Vault 里有一些密钥是用 AES256-GCM 加密的，AWS 不支持这个算法
- 还有一些密钥是动态生成的（每次读取都会改变），AWS Secrets Manager 只存静态值
- 转过去以后，有些老应用的调用方式变了，需要改代码
整个迁移花了三个月，比预计多了一倍。所以我的教训是：不要先选工具，先列清楚你的密钥类型和消费方式。
另一个坑：有人用自建 Vault，但遭遇了集群脑裂（split-brain）。因为他们用了 consul 做存储后端，网络分区导致两个 Vault 节点都以为自己是主节点。结果密钥版本不一致，下游应用拿到的是过期密码，直接报 401 认证失败。
如果你要自建，请务必在存储后端上做对选型：
- 小规模：用 raft（Vault 内置）
- 大规模：用 consul 或 etcd，但要做好网络容错设计和备份策略
总而言之，自建还是上云，没有标准答案。你得从控制力需求、运维能力、预算预算、合规等级四个维度去权衡。如果拿捏不定，就先找个最小的业务试点，走一遍从选型到上线的完整流程。嗯，试试看，你就知道适合自己了。