基于CloudFormation部署的AWS Lambda API：万次调用下用AWS Secrets Manager的可行性

是不是合理选择？ #

绝对是比硬编码靠谱得多的选择，完全应该替换掉当前的硬编码方式：

• 安全上：硬编码会把数据库账号密码这类敏感信息直接暴露在代码、版本库甚至部署包里，风险极高。Secrets Manager会加密存储这些信息，还能自动轮换数据库密码，从根源上降低泄露风险，这也是AWS官方推荐的最佳实践。
• 运维上：以后要改数据库连接信息，直接在Secrets Manager里更新就行，不用重新部署Lambda函数——对于每月上万次调用的服务来说，少一次部署就少一次服务中断的可能。
• 合规上：如果你的业务涉及PCI、HIPAA这类合规要求，用Secrets Manager更容易满足审计和数据保护的合规标准，省得后期整改麻烦。

成本开销到底有多少？ #

Secrets Manager的成本主要分两块，都很低：

• 存储费：每个秘钥每月固定收0.4美元，你只存一个数据库连接秘钥的话，这部分钱基本可以忽略。
• API调用费：每1万次调用收0.05美元。就算你的Lambda每次调用都去拉一次秘钥，每月1万次调用也就花0.05美元，10万次也才0.5美元，完全在可控范围内。
  而且你还可以在Lambda里缓存秘钥——比如把获取到的秘钥存在全局变量里，冷启动时拉一次，后续复用，这样能大幅减少Secrets Manager的调用次数，成本还能再降。

性能会不会受影响？ #

• 第一次拉取秘钥的时候，会有几十毫秒的API调用延迟，对于绝大多数API场景来说，这点延迟用户根本感知不到。
• 缓存秘钥之后，后续的Lambda调用就不用再请求Secrets Manager了，性能和硬编码几乎没差别。
• 唯一要注意的是Lambda冷启动：如果函数长时间没被调用，冷启动时需要重新拉取秘钥，会多一点启动时间，但你每月有上万次调用，冷启动的频率会很低，对整体性能影响可以忽略不计。

额外提几个优化点 #

• 给Lambda的IAM角色配最小权限，只允许它访问你存储数据库秘钥的那个Secrets Manager资源，别给太宽的权限，避免权限泄露。
• 开启Secrets Manager的自动轮换功能，让它定期自动更新数据库密码，不用你手动操作，安全性拉满。
• 代码里加个简单的缓存逻辑，比如用全局变量存秘钥，再加个过期判断，避免长时间复用同一个秘钥（如果开启了自动轮换的话）。

内容的提问来源于stack exchange，提问作者Tanu