AWS Cloudformation is a service that enables you to provision, update and delete AWS services.

The file or files you submit, in JSON or YAML format, via the AWS console or the command line describe the desired state of your infrastructure. Cloudformation takes that description and does the heavy lifting. You do not program the steps needed to get from zero to your target. It’s not scripting. Your declare services and properties. The automation is done by Cloudformation. Sounds familiar, doesn’t it? Infrastructure as code.

I’m sure you are familiar with infrastructure as code. Maybe you have already switched from scripts in various languages to tools like Ansible (that I like). There are a few of these very known tools, no need to create an SEO buzz list here for nothing. Cloudformation is AWS’ tool and it is very handy.

What format you pick is entirely up to you, but I can’t be arsed typing curly brace and semi colons every two words, so YAML it is for me.

OK, let’s not be too long winded with the presentation and dive in.

 

Here’s the skeleton of a Cloudformation YAML file and what’s what:

• Template version: defines the capabilities of the template
• Description: a … description, duh!
• Metadata: mostly used to group parameters in the web interface, but can do more
• Parameters: custom values for your templates
• Mappings: for key name mappings
• Conditions: condition that determine if resources are created or configured
• Resources: the actual resources you want to use
• Outputs: output values (like an EC2 IP address)

Confusing? Normal! There’s detailed explanations here. But it’ll all make sense soon.

So, what resource are we going to create? A VPC is a good start. Let’s do that.

Fire up your preferred text/code editor and follow along.

The resource we want is a VPC. The only section a template really needs is a resource section. But we’ll throw in the template version and description as well.

 

 

If we upload the template to Cloudformation, our VPC will be created in a matter of minutes.

Actually it took 21 seconds for the VPC to be created.

 

We have a hard coded value in our template. If we do care about that, maybe it’d be a good idea to customise it.

Enters Parameters.

 

This is a very minimalist Parameters section, but it’ll do the trick. VPCCIDR is the variable we will use and define in the web interface.

In the resource section, we reference the variable by using intrinsic functions, here with the YAML short notation syntax.

This is a step in the right direction, but we could enter an arbitrary string for the VPCCIDR in the web interface. We can re-inforce what is expected at this stage, before we submit the template.

 

If we use this version that uses a regular expression to validate the VPCCIDR field, this is what we’ll get in the web interface if we do indicate a valid CIDR block (like “yeah yeah, blah!blah!blah!” instead of “10.0.0.0/16”)

 

 

As indicated previously, the Metadata section can be used to group parameters into sections in the web interface. Here’s how we’d do that.

 

 

Now we’ll see a “Network Configuration” section in the interface that holds the VPCCIDR parameter. Of course, this makes a lot more sense for a template with more parameters and resources. We’ll get to it.

 

This can save us a failed run and debugging.

We could do with an internet gateway, subnets and routing tables because right now our VPC is pretty useless. That’s OK, we’re learning Cloudformation together, no pressure!

Stay tuned, we’ll extend our template next time.