Table of Contents
- How CloudFormation Updates and Deletes Resources
- Next Steps
- Watch The Series Here
- The Complete CloudFormation Guide Index
How CloudFormation Updates and Deletes Resources
So, before we dive into how to create templates themselves and their structure, we should discuss how CloudFormation updates and deletes resources. The reason is that there's some gotchas around updates that are good to know, if you don't want to accidentally delete something you didn't mean to. It happens, so to keep it from happening to us we'll start with updates.
Let's use an example here. Let's say we have a template we've built that defines an EC2 instance. There's nothing else to it. It's just a plain old instance that's not running an application at all. Well first up, let's open up that doc page for the EC2 Resource in CloudFormation.
On here we can see what the JSON syntax for an EC2 instance would look like in a template. We see one property here called ImageId. It's by using this property that we tell it which AMI (or Amazon Machine Image, the starting configuration for the server) to use. So, are we using Amazon Linux 2? Or are we using Ubuntu? Or maybe some other type of image. (And again folks, if the word AMI is completely going over your head, I really suggest going through my AWS EC2 fundamentals course.)
Okay, let's say we're using some version of Amazon Linux 2. The way we'd tell it to use a particular AMI is to just get its ID and list it like it's shown in the examples. But what if we want to change it to a different image? Well, we just put in the different image ID for the new AMI. What do you expect to happen after we do this?
Well, what will happen is that CloudFormation will actually kill the current instance and make a new one with the new AMI ID. As you can imagine, if you weren't expecting your instance to go down, you'd have some problems.
"Whoa, so you're telling me that when I go to update something in my template, it might get deleted and replaced instead of just straight updated?"
Yeah. And that seems a bit annoying until you think about how you'd do it in the console. If you want to change the underlying Amazon Machine Image (AMI) in an instance in the console, what do you have to do? You have to make a new one.
But there's an easier way to figure out what's going to happen. First up, what property did we change? The ImageId. If we take a look at that property in the docs, we see a quick blurb about what does...and then there's a nice little section there called 'Update requires'. And here we can see right next to it that it requires replacement.
If you look through any of these properties, you'll see an Update requires section for all of them. So while something like ImageId requires the complete replacement of the instance, something like InstanceInitiatedShutdownBehavior doesn't even interrupt the instance. It'll just keep going on like nothing happened!
1 - HOW can AWS update your resources?
There's three possibilities:
1. Update with No Interruption
2. Updates with Some Interruption
Those are the things it can do. We can see the full docs on Update Behavior here. If you look through this, they go into full detail on that process.
Now this may seem like a lot to remember, but the workflow to make sure you don't get caught blind is simple. And that's the second thing here:
When you update a resource, check out its 'Update requires' property.
It's that simple. So, for example, when I go to change the ImageId property on my instance, the best bet is for me to double-check its Update requires first. By simply looking that over, I'll know exactly what's going to happen to it.
Okay, so that's all there is really when it comes to updating and catching what AWS will do to your stack. If you recall from the earlier section, when you upload a modified template to update a stack, you'll get a change set. Well this is the second way you can catch it. When you view that change set, it'll tell you right then and there if it's going to replace it or not.
Now if some of this is a bit odd or overwhelming, just bear with me. When we get to the project, all of this stuff will come full circle and make sense. Just get the terms down for now before we start putting them into practice.
2 - What happens if an update fails?
Unless you tell it to do otherwise, CloudFormation is actually pretty smart. If an update fails, it'll just ROLL your infrastructure back to its previous state. This is obviously super useful for those times when you push up a bug or typo that would otherwise result in everything going down. And again, we'll get to see all of this stuff in action when we do the project. Just get familiar with the concepts and terminology right now.
So that's all for updating. When you go to update a stack, be sure to watch for HOW it will update your resources. Will it replace them? Cause interruption? To figure out what CloudFormation will do, just check that Update requires field on any property you're planning to update. And finally, if you put up a bad update, CloudFormation is smart enough to roll back to its previous state.
3 - What about deleting a stack?
Okay, this our final and simple topic: deleting CloudFormation stacks. Note here that I said STACKS. This goes for both creates, updates, and deletes. Remember this - you make a stack from a template. You then update and delete that stack. You might modify the template, but the template is just...well...the template to make the stack from.
When you've created a stack from a template, CloudFormation groups all of the resources together like we covered before. It does so with tags and other metadata. This is insanely useful for organization, especially if you have multiple infrastructure setups in one account. It means there's little to no chance that you'll accidentally trample on another stack's resources when updating or deleting your own.
So what's involved with deleting CloudFormation stacks? How complicated can it possibly be? Well, it's not. All you do is delete the stack. On the CLI, it's a simple command. On the console, it's a couple of buttons. After that, CloudFormation will correctly remove ALL resources for that stack.
Okay, so that's all on updating and deleting. Again, I'm sure some of you are thinking, "Oh geez, this sounds like a lot to keep in my head, and we haven't even written at template yet!" But trust me, it's really not that bad. Once we dive into the template anatomy and the project itself, all of this will come together beautifully.
The Next Post - Our Project Setup
The Previous Post - The Main Concepts 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 1 - CloudFormation Updates and Deletes
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
Developer Advocate @HashiCorp, DevOps Enthusiast, Startup Lover, Teaching at awsdevops.io