Of all the things I love at GorillaStack, including beer, coffee, workplace banter and of course AWS, there are two in particular that I was able to enjoy the last few nights after work; Open Source and CloudFormation.
We love Open Source at GorillaStack and highly prioritize giving back useful code to the broader developer community. We also love AWS CloudFormation, which makes it super easy to deploy and update stacks and gives you the opportunity to version your AWS resources. This may seem like a fringe benefit, but it is a very important practice in empowering developers and encouraging them to define and maintain the environments required to host or serve their applications. When updating, versioning, committing CloudFormation template becomes part of a developer’s deliverables for a piece of work and it is pull requested, peer reviewed, tested and deployed along with other source code, this breeds a true devops culture, one in which development and operations teams are not two isolated entities.
But I digress. The point of this blog post is that since we wrote Auto Tag last year before AWS re:Invent, we have had AWS customers from all over asking questions for help with the setup process.
And fair enough! There are heaps of resources to be created and I recognize the need for more succinct or accessible documentation.
Enter CloudFormation. Our CloudFormation template defines the two roles, one S3 bucket, one bucket policy, one bucket notification policy, one CloudTrail and one Lambda function required to run Auto Tag. This should make it far easier for you to get started.
This new version adds:
We are also hosting a version of the zipped lambda code in each AWS region in a public S3 bucket to make it even easier for users to deploy the CloudFormation template, to save users from having to store the code in their own S3 bucket.