我们目前有许多资源部署到AWS dev和prod帐户 . 这些包括lambda函数，kinesis流，dynamo db表和RDS实例 . 其中一些资源使用我们的ci工具和cloudformation进行部署，有些是手动完成的 . 出于多种原因，我们希望在cloudformation中定义所有内容 . 大多数资源都是较大系统或堆栈的一部分 . 即连接到lambda函数的api网关，该函数可能消耗由另一个lambda函数填充的kinesis流 . 问题是，在这种情况下， Cloud 形态模板应该存在于何处？在第一个lambda的回购？第二个lambda？中央 Cloud 信息仓库或其他地方？
3 回答
将模板存储在任何源代码控制中是一个很好的开始，可以获得集中和版本化代码的好处 .
但是，如果您主要在AWS Cloud 中投资自动化，则应该考虑在 AWS CodeCommit git服务中存储模板（和其他代码） .
这样做的主要原因和好处是：
与其他AWS服务的紧密集成选项
触发repo操作上的事件，例如发送SNS通知或触发Lambda操作的pull请求和提交 .
能够使用IAM策略和角色与开发人员以及其他服务和应用程序共享repo访问权限 .
CodeCommit提供了一种非常精细且安全的方式来分离谁可以做什么，以及哪些应用程序可以访问repo，因此您可以分割 生产环境 和登台环境 .
我见过的最佳实践是将您的模板开发/提交到源代码存储库（通常是Git），然后利用CI工具（如Jenkins，Travis CI，Bamboo等）将这些工具复制到您的帐户所拥有的S3存储桶中读取权限（NOT PUBLIC） . 引用其S3网址中的所有模板，并使用CI工具使这些网址保持最新 .
例如，
master分支最终位于http://bucket-name-here.s3.amazonaws.com/project-name/template.json，develop分支最终位于http://bucket-name-here.s3.amazonaws.com/project-name/template-develop.json. 您可以扩展功能/发布分支以遵循http://bucket-name-here.s3.amazonaws.com/project-name/template-release-v1.0.json或类似功能 .当您在其他资源中引用这些内容时，您将始终违反所需的任何代码级别（对于 生产环境 级代码，请参考
template.json） .我们在GitLab中拥有大量Jenkins CI / CD环境的所有源代码 . 并考虑添加管道步骤以触发AWS CodeCommit CodePipeline从专用GitLab repos拉出以亚马逊专用方式执行CloudFormation模板，并带来所有好处 .