Table of Contents
- The Main Concepts of CloudFormation
- The Stack
- Next Steps
- Watch The Series Here
- The Complete CloudFormation Guide Index
The Main Concepts of CloudFormation
Okay, so let's talk about all of the main concepts you need to know about CloudFormation. Keep in mind, this is going to be the 50,000 ft view. We want this for the same reason you want a map while traveling: so that no matter where you're trying to go, you've got a healthy birds-eye view of how to get there.
So here's our 50,000 ft view of the whole CloudFormation process:
Make a template -> Upload it
That's it: make a CloudFormation template that has all of the stuff you want for your infrastructure...and then upload it to AWS CloudFormation. No matter how deep we dive into the details, don't forget that the workflow is actually this simple. Now obviously there's some things to expand on here in regards to making a template so let's do that now.
First - What is a Template?
Simply, it's just a JSON or YAML file that lists everything you want in your infrastructure AND how you want it connected. It's all just JSON or YAML syntax and semantics with AWS's own set of rules sprinkled on top. But at the end of the day, it's just a plain JSON or YAML file.
What if we zoom into the process of making that template, what are we doing? Well, we're just listing and connecting our resources:
Make a template -> upload it / list and connect resources
What do I mean by that? Well, just like how in the console you pick a service and start something up...well, in CloudFormation, you pick a service and then you list it in your template following the right syntax and semantics. We can see some examples on the AWS Resource and Property Types Reference documentation page.
Second - A Useful Mental Model
On this page is a list of ALL the AWS resources that you can make with CloudFormation. And how do you make them? You put them in your template. So, let's say I wanted to create a Security Group. How would we figure how to put that in CloudFormation? First, treat this page as if it were the AWS console. This is an EXTREMELY helpful mental model to use when developing in CloudFormation. Ask yourself: what would I do if this were the console?
Well, if it was, you'd go to the EC2 console right? So on this page, we'd go to the EC2 Resource page.
In the console, when you select EC2 there, you're shown all the different things you can make. Similarly here, when we go to the EC2 Resource Type Reference that I just linked to above, we're shown all of the things we can make for EC2 with CloudFormation.
(If you're not up to speed on EC2 and would like a full rundown of it, you can check out my AWS EC2 Fundamentals series that I mentioned earlier. It'll be really useful for getting the most out of this series too.)
So, say you wanted to create a security group. In the console, you'd select 'Security Groups' and then create one. For CloudFormation, we've navigated to the EC2 resource list page so we need to FIND the Security Group Resource which is right here in this long list.
Third - CloudFormation Assumes You Know the Services
Once we're on that page, we can see the Security Group with all its properties, and these should look pretty familiar. But you'll notice that the documentation is pretty sparse, right? That brings up a really important point I want to drive home with you:
If you want to work with a service in CloudFormation, you need to already know it.
As you can see on these pages, there's no hand-holding here. None of these property descriptions tell you ANYTHING about how Security Groups work or their relation to EC2. We'll talk about this more shortly. For now, let's scroll down to examples. Down in the examples section, we can see what a Security Group should look like in a template. If we use our mental model here: while in the console you'd just create the group and fill out the information, but in CloudFormation, you find the resource you want in the docs, fill in its properties, and add it to your template. So the process now is:
Make a template -> Upload it / List and Connect Resources / Find what you want, Pick the properties, Add it to your template
And again, the great mental model to operate on is to treat this as if it were the main console page. You just pick your service, pick what you want to make, pick what properties you want on it, and then add it to your template. I know it's a bit repetitive but I'm really trying to drive this home because that's how dang simple this all can be despite the mysterious magic it can be painted as sometimes.
That all being said, there's two points we should cover before we move on. First, let's return to that point we made just a moment ago: CloudFormation Assumes You Know the Services.
We saw it on the Security Group resource page. There's no hand-holding once you get to CloudFormation. If you don't know how EC2 works, if you don't know the options and configurations, if you don't know the relationships between different resources...well, quite frankly, it's irresponsible to keep going because all you'll be able to do is copy/paste example code and hope that things work. Considering just how important infrastructure is to a business, that should never be your approach. It also hurts you in the long run too because you miss out on an opportunity to actually learn and instead hold yourself hostage to examples and step-by-steps...which may kind of work in the short run, but will absolutely bite you long-term.
Fourth - CloudFormation Shows You the Hidden Pieces of AWS
The second point is how CloudFormation shows you the hidden pieces of AWS. To see an example of this, let's hop back over to the docs. If we look again at the EC2 Resource Type Reference, we will see that some of these are familiar...but others, like EIPAssociation or SecurityGroupIngress are new to us. If all you've done is work with the console or CLI in AWS, then you'll probably have never seen those resources. And why is that? Well, because the console and CLI take care of these for us a lot of the time.
So, let's take SecurityGroupIngress for example. When we go into this, even though there isn't a resource in EC2 called SecurityGroupIngress, this should still look familiar. And how should it look familiar? Well, when you make a security group in the console, what's it ask you while doing so (aside from normal stuff like name and the like)? Well, it asks you to make rules for inbound rules and outbound rules. Rules that dictate what can come in and leave.
Even though the console makes that all look like one thing, what actually happens is you create a security group, and then you create a set of SecurityGroupIngress rules that are associated with the security group. For example, when you add a rule that allows for HTTP traffic on Port 80? Well, that's just a SecurityGroupIngress resource associated with a Security Group. In the console that's hidden from us for convenience, but in CloudFormation we have to do it for ourselves.
That's what I mean with this point: when you start working with CloudFormation, you get to see all of these smaller background pieces that you don't in the console or CLI. On one hand it's fascinating...but on the other hand it can trip you up.
Okay, so that's the first part of our workflow:
Make a template -> Upload it / List and Connect Resources / Find what you want, Pick the properties, Add it to your template.
Conceptually, this is pretty simple so let's move onto the next step.
Once your template is done, you upload it to AWS CloudFormation either through the console or CLI. Now of course, there are some extra parts to doing this:
Make a template -> Upload it / Select options for your template, Check changes.
The only thing you really do when uploading is selecting options about how you want it deployed. These are things like: What do you want to name the set of resources created from it? What notifications do you want to set up? What parameters do you want to use with it? (Don't worry, we'll cover these options when we get to them.)
When you've uploaded a valid template, CloudFormation hauls off and makes all the resources you've asked it to. And what is the result of your built template? A STACK.
A stack is just what all of the built resources from the template you uploaded, bound together, are referred to as. The beauty of this is that they're LITERALLY grouped together from AWS's point-of-view because all resources created from a template get tagged so that you can easily group them together. You can also add tags yourself.
I bring this up because 'stack' is one of three core terms in CloudFormation. We've already talked about one earlier: template. It's the template for the infrastructure you want to build. Then the second term is the stack. And, to get to the third term, we need to look at our workflow.
What we've done so far is talk about how to create a stack of resources from a template. We say, "Oh look at this list, my wonderful list of everything I need to create some infrastructure." Maybe it has some EC2 instances in it, a network, and other things. When we're ready, we pass it to CloudFormation and it goes on to create everything in our template, groups it together, and calls it a stack.
But what if we want to update an infrastructure created from a template? Well, the workflow isn't that different. The first thing we do is update the template that we made our stack from. So, say we have a template with a security group that allows for HTTP traffic and we want to open up SSH traffic as well. The first step would be to add that to our template, pick our deployed stack from CloudFormation, and upload the updated template:
Update the Template -> Upload it to the Same Stack.
So, it's like the same process as before except we choose to 'update an existing stack' rather than 'create a new stack' like last time.
We have one more step after that:
Update the Template -> Upload it to Same Stack -> Confirm Change Set.
This final step is to confirm the set of changes that CloudFormation will make and this set of changes is our 3rd core term - a Change Set. When you update a stack with an updated template, it'll generate a change set, and this will show you ALL the things that CloudFormation plans to do. Obviously this is incredibly useful for catching any hiccups or mishaps. And after you've confirmed it? Well, it'll go and do the updates.
Now that folks...is it. That's really all there is to CloudFormation from a 50,000 ft view. Despite all the crazy tooling and DSLs out there, all the silver bullets...just know that it can be this simple. You can just make a single JSON file and be on your merry way. You don't have to have some labyrinth of a development environment or framework to write infrastructure as code. You just need one file.
The Next Post - How CloudFormation Does Updates and Deletes
The Previous Post - An Introduction to and History of CloudFormation
Watch The Series Here
If you'd like to watch instead of read, the AWS CloudFormation Fundamentals series is also on YouTube! Check out the link below for the sections covered in this blog post.
Video 3 - The Main Concepts of AWS CloudFormation
The Complete CloudFormation Guide Index
If you're enjoying this series and finding it useful, be sure to check out the rest of the blog posts in it! The links below will take you to the other posts in The Complete CloudFormation Guide here on Tech Guides and Thoughts so you can continue building your CloudFormation template along with me.
- The Complete CloudFormation Guide
- An Introduction to and History of CloudFormation
- The Main Concepts of CloudFormation
- How CloudFormation Does Updates and Deletes
- Our Project Setup
- Parameters and Refs
- Our First Time Launch
- Functions, Pseudo Parameters, and Conditions Part 1
- Functions, Pseudo Parameters, and Conditions Part 2
- The Best Next Steps to Take from Here
Enjoy Posts Like These? Sign up to my mailing list!
My Tech Guides and Thoughts Mailing List
J Cole Morrisonhttp://start.jcolemorrison.com
DevOps Specialist, Software Engineer, former Techstars Hackstar, and Founder / Instructor at AwsDevops.io!