We currently have a number of resources deployed to an AWS dev and prod account. These include lambda functions, kinesis streams, dynamo db tables and RDS instances. Some of these resources are deployed using our ci tool and cloudformation and some are done manually. For a number of reasons we want to have everything defined in cloudformation. Most of the resources are part of a larger system or stack. I.e an api gateway connected to a lambda function which might consume a kinesis stream which is populated by another lambda function. The question is, in this scenario where should the cloudformation template live? In the repo for the first lambda? The second lambda? A central cloudformation repo or somewhere else?
3 Answers
2
votes
Storing the templates in any source control is a great start to get the benefits of centralizing and versioning the code.
However, if you are investing in automating primarily in the AWS cloud you should look at storing your templates (and other code) in AWS CodeCommit git service.
The main reasons and benefits of this are:
- tight integration options with other AWS services
- triggers for events on repo action like pull requests and commits that send SNS notifications or trigger Lambda actions.
- ability to share repo access with developers and other services and applications using IAM policies and roles.
CodeCommit gives a really fine grained and safe way to separate who can do what, and what applications have access to repo's so you can segment production and staging environments.
1
votes
Best practice I've seen is to develop/commit your template to a source code repository (Git usually) and then leverage a CI tool (like Jenkins, Travis CI, Bamboo, etc) to copy those to an S3 bucket which your accounts have permissions to read (NOT PUBLIC). Reference all templates from their S3 URL and keep those URLs up to date with your CI tool.
For example, master branches end up at http://bucket-name-here.s3.amazonaws.com/project-name/template.json and develop branch ends up at http://bucket-name-here.s3.amazonaws.com/project-name/template-develop.json. You could expand feature/release branches to follow http://bucket-name-here.s3.amazonaws.com/project-name/template-release-v1.0.json or similar.
When you reference these in your other resources you'll always go against whatever code level you want (reference template.json for the production-level code).
