AWS Cloud Formation

AWS Cloud Formation

AWS Cloud Formation is one of the pioneers in Infrastructure as Code, as Cloud Formation existed as a Service in the stack  as far as 2011. It is an AWS-specific service that allows you to define a deployment of AWS resources into “Templates”, that once provided to the Cloud Formation service will create “Stacks” that can be managed. Once these “Stacks” are deployed, it becomes far easier to manage the resources “Stack”-wise to (say) rollout application updates or manage resource limitations. The resources and their metadata are defined in JSON or YAML files. There is a little learning curve to get started because of this. AWS also provides a visual diagramming tool, which could improve a lot at the moment this is being written.

A Cloud Formation (CF) template consists of several sections.

1. Resources

The resources section is where the required AWS resources are defined, in any order. For example, if there is a need for an EC2 instance, an Elastic Load Balancer, and a Security Group to manage access, those can be defined in the Resources section as follows.

2. Parameters

Parameters are similar to arguments that are passed into a function upon invocation. Almost always a Cloud Formation template has to make use of data that should be retrieved from the user. These data include values like the AWS Key Pair name, Certificate names, credentials to databases, etc. These cannot be hard-coded into a template. Parameters are a way to make these data available from the user who is invoking the template. For example, if the following parameter definition is included in a CF Template, the user will be prompted to enter a value to it, when the Stack creation initiates.

3. Outputs

Outputs are the opposite of Parameters in terms of functionality. A CF Template’s Outputs are its return values. For example, if the following CF Template contains the above Resources block along with an additional Outputs block that contains the Elastic Load Balancer’s Public DNS name, then that value could be used by another CF Template (which is possible. A CF Template can include another CF Template via the use of a Stack resource type) that includes this one.

4. Mappings

Mappings are a way to introduce some kind of flexibility to values that can be neither prompted by the user to be hard-coded at the place where it’s used. An ideal example of this is the AMI ID to be used to spawn instances. The AMI ID cannot be prompted by the user, for obvious reasons, one of which is that CF logic might not be compatible with every AMI out there. However, this cannot be hard-coded into the EC2Instance Resource declaration as well. An AMI ID is region specific. Even for the same AWS-provided Base AMI, the ID changes across regions. A CF template should be written in a way that doesn’t restrict it to a specific region. To tackle this, a Mapping can be used where for each region name, an AMI ID is mapped.

5. Conditions

Conditions are an effort to introduce some level of logical structure to the CF Templates. They are defined separately and can then be matched against certain values (ex: true or false ).