3. 与 AWS Parameter Store 的对比（基础篇）
说实话，很多刚接触云上配置管理的人，都会在 Secrets Manager 和 Parameter Store 之间犹豫。我当年也一样，站在控制台前看着两个服务名，心想：这俩到底有啥区别？
这一章咱们就从功能、定价、限制三个角度，把这两个服务掰开揉碎，帮你快速决定入门用哪个。
一句话总结：Secrets Manager 是“专业密码管家”，Parameter Store 是“轻量配置仓库”。选哪个，看你想要多少护栏。
3.1 功能对比：到底差在哪？
先看一个整体对比表格。我项目中经常用这个表给团队做决策参考。
| 对比维度 | Secrets Manager | Parameter Store |
|---|---|---|
| 核心用途 | 管理数据库密码、、证书等敏感凭证 | 存储配置参数、环境变量、非敏感字符串 |
| 自动轮转 | 原生支持，可对接 RDS、Redshift、DocDB 等 | 不支持，需自己写 Lambda |
| 密钥加密 | 强制使用 KMS，默认 AWS 托管密钥或自定义 CMK | 可选：明文或 KMS 加密（标准/高级参数） |
| 跨账号访问 | 通过资源策略支持 | 需要 KMS 密钥策略 + SSM 策略配合，略麻烦 |
| 版本管理 | 每个 Secret 有版本标签（AWSCURRENT, AWSPREVIOUS） | 标准参数不支持版本；高级参数支持版本号 |
| CloudFormation 集成 | 支持动态引用（动态引用解析） | 支持动态引用，但仅限高级参数 |
| 最大存储限制 | 65536 字节（64 KB） | 标准 4 KB / 高级 8 KB（分层参数可达 8 KB） |
| 分层参数 | 无 | 支持分层路径（如 /prod/db/password） |
你看，最核心的差异就是自动轮转和加密强制性。我在某金融客户项目里，审计要求数据库密码必须每 90 天轮转一次。用 Parameter Store 我得自己写 Lambda + EventBridge 来触发，折腾了两天。后来换成 Secrets Manager，打开控制台配一下轮转周期就完事了——嗯，这种时候你就知道“专业管家”的意义了。
3.2 定价对比：钱花在哪？
定价这块，我见过不少团队因为“免费”二字选了 Parameter Store，结果后期运维成本翻倍。咱们看真实的价格模型。
| 计费项 | Secrets Manager | Parameter Store |
|---|---|---|
| 月度存储费 | $0.40 / Secret / 月 | 标准：免费；高级：$0.05 / 参数 / 月 |
| API 调用费 | $0.05 / 10000 次调用 | 标准：免费（前 10000 次/月）；高级：$0.05 / 10000 次 |
| 自动轮转费用 | 轮转期间额外 Lambda 执行费（按实际算） | 无原生轮转，自己搭的成本另算 |
| KMS 密钥费 | 强制使用，每月 $1 / CMK + 按调用次数 | 可选：用 KMS 则按相同费率，不用则零 |
我的个人经验：如果你管理的秘密少于 5 个，且不需要轮转，Parameter Store 高级参数的确更省钱。但超过 10 个且涉及轮转，Secrets Manager 的人力节省远超那几美元差价。
3.3 限制对比：容易被忽略的坑
限制这个东西，文档里写得清清楚楚，但很多人在选型时直接跳过。我吃亏过，所以得提醒你。
- Parameter Store 的值大小限制太死：标准参数最大 4 KB，Java 的 JDBC 连接字符串加个证书内容很可能超。我在一个 IoT 项目里把整个 CA 证书扔进去，结果 truncate 了，排查了半天才发现是大小超限。
- Secrets Manager 不支持分层路径：它没有 /prod/db/password 这种路径概念，所有 Secret 是扁平化的，只能靠标签和命名前缀组织。如果你习惯用层次路径管理上千个参数，Parameter Store 的路径式树结构更顺手。
- 自动轮转有 Region 限制：Secrets Manager 的内置轮转模板只支持部分 AWS 服务。我上次想轮转自家自建的 PostgreSQL（不在 RDS 上），结果发现内置模板不适用，得自己写 Lambda 逻辑——也不算太难，但初次接触的人容易被“自动”两个字误导。
- Parameter Store 的高级参数限制：高级参数虽然有版本号和加密，但不能做密码轮转，而且每个参数每月要收 $0.05，量大了也是笔不可忽视的开销。
避坑指南：我曾经在 Parameter Store 里存了 50 多个“加密字符串”，以为用 KMS 加密就安全了。结果审计时发现，这些参数没有版本管理，一旦错误覆盖就回不去了。解决方案是用 Secrets Manager 的多版本标签，或者自己写备份脚本。总之，任何不可逆的配置变更都要留后路。
3.4 选型决策流程
下面这张 SVG 图总结了我的决策逻辑，你可以直接拿去做架构评审的参考。
说白了，决策逻辑特别简单：
- 需要自动轮转？ → 直接上 Secrets Manager，别纠结。
- 值超过 8 KB 或者要版本回退？ → 同样选 Secrets Manager。
- 轻量配置，小于 4 KB，明文或简单加密就够了？ → Parameter Store 免费版完全能打。
- 介于中间？ → 用 Parameter Store 高级参数，但要自己管轮转和备份。
3.5 实战建议：入门怎么选？
我的结论：如果你是第一次做配置管理项目，而且团队里没人踩过坑，我建议直接从 Secrets Manager 起步。
原因有三：
- 它强制加密，你不用担心“忘了勾选加密”导致密码明文泄漏。
- 自动轮转功能让你后期很容易满足合规要求，不用重构。
- 虽然每月每 Secret 多花 $0.40，但比起花两天写轮转脚本的人力成本，这笔钱太值了。
当然，如果你只是存个非敏感的环境变量（比如日志级别、功能开关），Parameter Store 免费版够用。把 Secrets Manager 留给真正的秘密，把 Parameter Store 留给配置——这样既省钱又安全。
小技巧：我习惯在 CloudFormation 模板里同时用两个服务。用 aws:ssm 动态引用拉取 Parameter Store 的配置参数，用 aws:secretsmanager 拉取数据库密码。这样各取所长，运维上也清晰。
好了，这一章我们透彻地对比了两个服务。你心里应该有谱了吧？下回见到有人问“选哪个”，直接把本章甩给他就行。