2015/06/07

DRYness for Cloud Formation Environments

AWS Cloud Formation opens up many possibilities in terms of creating re-usable infrastructure. The concept seems to support immutable environments by helping to automate the creation of a whole cluster of machines (just try to ignore the 'update' command for now).


If you have ever tried to create a cloud formation stack for a reasonably serious environment you may have noticed how there was some duplication of resources for different hosts. Let's say for example that you use multiple availability zones to achieve high availability of your website or service. If you aren't using an auto scaling group then you may end up with multiple very similar EC2 resource instances. The chore of pasting these things around can mean that you spend too much time on copying and pasting and not enough on the design of the stack. Add to this that when you want to update the instance you end up having to modify it in multiple places. In steps my favourite problem: DRYness (or here the lack of it).


Though it might seem like overkill, one thing you may want to consider is creating a cloud formation stack for each VM role in your organisation. That way you can minimise the number of parameters needed for each resource. As an added bonus, when you modify the role you get it applied to all instances. This means you have more time to focus on making the instance role design better. Combined with outputting the instance into a top level super stack, and perhaps using the comma separated list of subnets and you will be creating nicer cloud formation templates in no time.


With all of the time you saved from copying and pasting resources, perhaps you could look into setting up standard alarms for the resources that you build which will save time on manual setup also. For extra points why not create a global stack with all of your shared resources that you don't want to recreate with each build of your environment?