21. CloudFormation TerminationProtection
very quick lecture. But if you wanted to protect your stacks against accidental deletes, you could use something called “termination protection.” The same way we have it for easy two-instances, we also have it for confirmation templates. The term “electronic commerce” refers to the sale of electronic goods. All right, so I’m going to create a stack, and I will upload this template file, and I’ll just upload the very first one, just EC-2 YAML. Click on “next.” Click on “next.” I’ll just need to name it. I’ll name it Test and the next, and at the bottom, create a stack.
So here we go. We’re creating our stack. And as we know already, this is going to create yet another easy instance. Okay, so now our stack has been created, and as we can see, we’re in “create complete.” So if I go back to my stack, I am able to delete it, but I won’t this time. I will edit the termination protection and say right now it is disabled, but I will enable my termination protection so I can’t delete this accidentally. So let’s try to delete it right now. I say action: delete the stack. And it says you can’t delete it because termination protection is enabled. So to delete the stack, I may go ahead and edit determination protection and disable it. And now, after disabling it, I can go ahead and delete my stack. So that’s it; that’s all. I want to show you a quick one, but I hope that was helpful, and I will see you in the next lecture.
22. ASG – CloudFormation CreationPolicy
Okay, so let’s have a look at how we can create auto-scaling groups using cloud formation, because this is something you need to know. So let’s go into create stack, and then we’ll choose a template file, and that template file will be the one you get from the code under auto scaling and cloud formation. And we’ll start with a zero-creation policy for ASG. So let’s go quickly see what this does in my code editor. So in this template, I have a parameter, and it’s using the SSM public parameter store to get the AMI ID for the latest Amazon Linux tube.
Then we create an auto-scaling group, and for AZ, it’s getting them from the region. I’m getting ready for the launch configuration. It’s a reference to the launch configuration I defined below. The desired capacity is going to be three instances, the minimum size is going to be one, and the maximum size is going to be four. But how do we know if this auto-scaling group is being launched correctly? We want to make sure that the instances are able to signal the fact that they have launched correctly so that we know that this creation of the autoscaling group itself has worked as well. So we can attach a creation policy to your auto-scaling group so that we are waiting for resources to signal and we are waiting for three resources to signal the correct number. So this is the same as my desired capacity, obviously.
And we’re saying we are willing to accept 15 minutes of waiting before these instances come up. And if that timeout happens, then the whole auto-scaling group will fail to launch. So this is really good because if you have a very complicated launch configuration with a lot of easy-to-user data in it and something fails within your easy-to-user data, you want to make sure that this auto-scaling group does receive a failed signal. And if it does, then this entire thing will just roll back and stop working. So if we scroll down and look at the launch configuration, it’s very simple. For the image ID and the AMI, it’s using the latest Linux AMI ID that I get from the parameters. And then I will scroll down the instance types: the two microbes and the user data, which is very simple. It’s the base 64 of this entire script file, and it does something very simple. It gets the bootstrap script, and then it uses the CFN signal script to say to my stack, my stackname for the resource auto scaling group, which is defined right here for the resource auto scaling group, and the region you’re in, to signal the fact that you are successful. And so this launch configuration attached to this auto-scaling group on the three instances we have will send three signals to the auto-scaling group and hopefully work. So let’s go back to confirmation. We’re going to click on “Next.” I’ll call it a demo ASG CFN. And I’ll click on “next.” I’ll scroll down and click on Next, then create my stack at the very bottom. Here we go. And now my creation is in progress.
And as we can see here, the Oto scaling group is being created. And if we go to my Otoskeleton Group UI, it has been created. But the CFN stack itself is not in a Create Complete state because we are waiting for three signals to come from these three easy-to-create instances that are being created for me. So we need to wait for these three EC2 instances to use the user data script and then signal back for confirmation of their success. And when they do signal their success, it hits. Then we will go into creating a complete timeline, and we can see here that there are three events that happened in this timeline. And the event specifies that the success signal should be received with a unique ID, which in this case is the instance ID. So we have three different instance IDs. And so the three instances here, here, and here have signalled their success to Cloud Watch and to Cloud Formation. Sorry. And so, as long as Cloud Formation has had the success it was waiting for (three success counts as part of the creation policy), what we get out of it is a Create Complete for this ASG. The answer is yes. Okay? Well, that’s it for this lecture. In the next lecture, we’ll look at updates to policy.
23. ASG – CloudFormation UpdatePolicy
Okay, so let’s have a look at how we can create auto-scaling groups using cloud formation, because this is something you need to know. So let’s go into create stack, and then we’ll choose a template file, and that template file will be the one you get from the code under auto scaling and cloud formation. And we’ll start with a zero-creation policy for ASG.
So let’s go quickly see what this does in my code editor. So in this template, I have a parameter, and it’s using the SSM public parameter store to get the AMI ID for the latest Amazon Linux tube. Then we create an auto-scaling group, and for the AZ, it’s getting them from the region I’m already in for the launch configuration. It’s a reference to the launch configuration I defined below. The desired capacity is going to be three instances, the minimum size is going to be one, and the maximum size is going to be four. But how do we know if this auto-scaling group was properly launched? We want to make sure that the instances are able to signal the fact that they have launched correctly, so that we know that this creation of the autoscaling group itself has worked as well. So we can attach a creation policy to your auto-scaling group so that we are waiting for resources to signal and we are waiting for three resources to signal the correct number. So this is the same as my desired capacity, obviously. And we’re saying we are willing to accept 15 minutes of waiting before these instances come up.
And if that timeout happens, then the whole auto-scaling group will fail to launch. So this is really good because if you have a very complicated launch configuration with a lot of easy-to-user data in it and something fails within your easy-to-user data, you want to make sure that this auto-scaling group does receive a failed signal. And if it does, then this entire thing will just roll back and stop working. So if we scroll down and look at the launch configuration, it’s very simple for the image ID, and the AMI is using the latest Linux AMIID that I get from the parameters. And then I will scroll down the instance types: the two microbes and the user data, which is very simple. It’s the basics of this entire script file, and it does something very simple. It gets the bootstrap scripts, and then it uses the CFN signal script to say to my stack, my stackname for the resource auto scaling group, which is defined right here for the resource auto scaling group, and the region you’re in, to signal the fact that you are successful. And so this launch configuration attached to this auto-scaling group on the three instances we have will send three signals to the auto-scaling group and hopefully work. So let’s go back to confirmation. We’re going to click on “Next.” I’ll call it Demo ASG CFN, and I’ll click on “next.” I’ll scroll down and click on Next, then create my stack at the very bottom. Here we go. And now my creation is in progress. And as we can see here, the Oto scaling group is being created. And if we go to my Otoscale group UI, it has been created.
But the CFN stack itself is not in a Create Complete state because we are waiting for three signals to come from these three easy-to-create instances that are being created for me. So we need to wait for these three EC2 instances to use the user data script and then signal back for confirmation of their success. And when they do signal their success, it hits. Then we will go into creating a complete timeline, and we can see here that there are three events that happened in this timeline. And the event specifies that the success signal should be received with a unique ID, which in this case is the instance ID. So we have three different instance IDs. And so the three instances here, here, and here have signalled their success to Cloud Watch in obscuring the formation. Sorry. And so, as long as Cloud Formation has had the success it was waiting for (three success counts as part of the creation policy), what we get out of it is a Create Complete for this ASG. So remember, okay, going into the exam, if you want to make sure that the instances are properly configured when being created for the first creation of an ASG, then you must set a creation policy for your ASG itself. Okay? Well, that’s it for this lecture. In the next lecture, we’ll look at updates to policy.
24. CloudFormation – DependsOn
Okay, so next let’s learn about “depends on” and we’ll open the file “twelve depends on.” So this file is interesting; let’s get started. So we have a mapping, and we’ve seen mappings before; mappings map, for example, regions to AMI. So this is an old way of finding a way to map a region name to an AMI. So, for example, if you run this template from US-east, you’ll resolve this value; if you go from US-west, you’ll resolve that value, and so on.
And then we have a resource that’s easy to instance, and we have the image ID. So for the AMI ID, we use a find-in-map function, and so this references this mapping right here, and we’re saying, “Okay, in the mapping named “AWSregion” arch to “AMI,” which is the name of this one, then you need to use the reference AWS region.” So this is a pseudo-parameter, and look at the value HVM 64. So if I run this within EU West 1, it’s going to say okay here, then it’s going to go down to EU West 1, then it’s going to go down to key HVM 64, and the value is going to be this. So this is going to be the result of this finding about map functions. So we have an easy instance, and it’s going to pick up an AMI idea from this mapping. And then there is this thing called “depends on.” And this is what I want to draw your attention to in this lecture.
So depends on is a way of saying that this resource, this EC2 instance, should not be created until my database is ready, and this is what depends on me. So if I had removed it, for example, the EC2 instance and the database would be created at the same time. And for example, if I had an application running on my EC2 instance that tried to connect to the database, well, it would not work, right? So by using this mechanism, we can say that, for cloud formation, you should only create this instance after the Mydb and RDSDB instances have been successfully created. So let’s try it out and see how that works. So we’ll go to stacks, create a stack, upload the templates, and we’ll use the template number twelve depending on, and then I’ll click on next. It can take a lot of time, but the demo depends on it because creating a database is very, very long. But we’ll just observe the beginning of the behavior. So let’s go ahead and create this tag. And now this tag gets created in progress, right? Then I’ll refresh, and the first thing that gets created is MyDB. So, as I refresh, mydbhas a resource creation has begun. But my EC2 instance is not being created at all. So I have to wait—a very long time, in fact—for the MyDB to be created so that the EC-2 instance can be created. And similarly, if I went and waited for the entire thing to happen and then deleted my resources, then this would be deleted first and then this would be deleted second. So, by introducing some relationship between the EC two instances, mydb, and tellcloud formation, we can determine which one we want to happen first. So that’s something you need to remember if it comes up at the exam. Okay, as far as this tag is concerned, if I wait, it will take forever. But as you can see, the EC2 instance is still not being created. So I’ll go ahead and delete it right away. All right, that’s it. I will see you at the next lecture.
25. CloudFormation – Stack Policies
An update Update is in progress for our stack Stack policy, but if I refresh now, and it says that the update has failed, and the reason for the failure is that the action is denied by this tag policy. So this statement updates the star for this logical resource, which does not accept this security group to be updated. And so this is where we get updates that roll back into progress, and then we’ll get back to normal states. So, at the very bottom, the Stack policy was protecting and stating that any updates against this logical resource ID to be a critical security group should be denied. And like in AWS, for everything else, deny has precedence over allow. So you can say, “Okay, how can I even update my security group then?” Well, the way you can do it is by doing the exact same thing.
So we’ll update the cider http, but in your stack policy in here, you should enter a new stack policy, and that’s going to be temporary; it’s going to be reverted afterwards. But if you delete this “deny” statement in here and go back, click on Next, and then click on Update. We’ve made the conscious choice to change the stack policy for this update and to update our critical security group. And as you can see, our critical security group is being updated. Now the update is complete. Let’s go back to our stack info, and we’ll scroll down, and we can see here in the stack policy that yes, the stack policy has not changed. It’s still the same as before. So when we update a Stack policy during an update, it is only to revert it for that particular update. Okay? And so that’s the power of the stack policy. Now you can do a lot of things with them, but the idea is to protect confirmation resources from being accidentally or intentionally updated. Sorry. And as such, we can have deny statements, but if we really, really wanted to update some resources, we could modify the stack policy at update time to perform the required updates. So I do recommend you check out that link, “Prevent Updates to Stack Resources,” and it shows you a lot of examples of the kinds of policies you can define. It’s just for your own knowledge, but from the perspective of the exam, you need to know at a high level what stack policies are, how they’re used, and how they work. Alright? Right. So that’s it. I will see you at the next lecture.
26. Multi Region – CloudFormation StackSets (from DOP)
So how can we deploy an application across multiple regions consistently, and even across multiple accounts? For this, you can use stack sets in cloud formation. So stack sets allow you to create, update, or delete stacks across multiple accounts and multiple regions with a single operation. The administrator account has access to create stack sets, and then trusted accounts allow the administrator account to create, update, and delete stack instances directly from the stack sets. So when you update the stack sets in the administrator account, all the associated stack instances are updated throughout all the accounts and regions.
Don’t worry, we’ll witness it firsthand. You can also set a maximum number of concurrent actions on the targets as a number or a percentage. And you also have the ability to express the number of offences you can tolerate as a number or a percentage. So this is extremely helpful once you start having a global architecture and want to have global confirmation templates deployed in multiple regions and multiple accounts. So let’s take a look at how this works. So let’s go into cloud formation. And in cloud formation, we’ve seen all there is to see about stacks, but what about stack sets? And so these stack sets are right here, and we have never used them. So let’s go ahead and use those right now. But first, we must obtain some immigration permits. So, as I said, there was an administrator account and then there were some trusted accounts. And so we need to create the IAM roles that will be necessary for these accounts to exist.
And so, thankfully, this documentation page has some confirmation templates that will allow us to just do that. So here is a confirmation template, and I’m going to copy the link address, and this will create an IAM role named AWS cloud formation stack set administration role. So let’s assume that we have the administrator account, and we’ll create a stack, and I’ll say the stack is here, I’ll click on next, and I’ll say the administrator account confirmation stack sets, okay, and I’m going to click on next, and finally everything looks good. I’m going to acknowledge that this will create roles and click on “create stack.” So this goes ahead and creates the first Im role we need. And then the trusted account is also going to be the same account as we have here because we actually need this account to be doing the multiregion stuff. In this hands-on, we only support multi-region, not multi-account. And so for this, we need to go to a target account so that ours can just copy this template, okay? And then we’ll be prompted to provide the name of the initiative account with which we have a trusted relationship.
Okay? So let’s have a look at this. So we’ll have to execute on this role. So I’ll refresh this page; everything is beginning to be created right now. So I’ll just wait a second. And now the creation is complete. So we have a resource being created, and that’s an application that does everything we need it to do. And so we’ll go ahead and create a new stack. I’ll also include the URL for the stack set execution role. Click on “next.” And here we need to put “parameter,” which is the administrator account ID. So this is where we need to provide our own ID. But I think I could have this from here. Here we go. So I’m just going to be the ID. I’ll just copy this entire thing and then get the ID out of it. So here we go. We have the administrator account ID, and this is the account where the stack sets will be created. In the role stack sets, I’ll call this one targetaccount. Okay. And click on “Next.” Click on “Next” and scroll all the way down.
This will create another obstacle. So that’s perfect. And click on “Create Stack.” So let’s wait for this to be over. Okay, so this stack is created, and now if I go back to my stack sets, I should be able to create my first stack sets. So let’s talk about a problem that we have. Say for example that we go to configuration, and you may remember that we did configuration in this course. And so if we go to Configuration, we can see that we can track all the resources within my region. And I’m in EU West 1, but if I go to say, US East 1, for example, in this example, well, configuration is not configured, and if I go to US East 2, well, configuration is not configured either. And so what I’m trying to show you here is that I would like conflict to be deployed in every single region that I’m operating in, right? So what I’m going to do is use the example template in here because the template is already created for me, but this is just a normal confirmation template that we have in here. And I’m going to choose a template to enable AWS configuration. If you’re curious, you can go to this URL and see what it creates.
It creates just a bunch of resources that are needed to create a configuration to track the resources within the account. So let’s click on Next, and I’m going to say here in the stack name, “enable AWS configuration.” and this text description is the exact same. And now for the parameters. So include global resource types, yes. The following is a list of the resources available to you. Topic: delivery channelname; generated frequency: 24 hours; all resource types supported: yes. So we don’t touch any of these parameters. They all work just fine. Click on “next.” And this is where we should mention the impending execution. So this AWS cloud formation stack set execution role is the one we have created directly from the confirmation stacks from before. So let’s go to roles and let me look for this role. Right now it doesn’t exist because you haven’t refreshed. Here we go. It exists; here it is. And so it’s going to use this role to execute on the Accounts Excellence plan. Click on “next.” And now I can say to which accounts I want to deploy this.
As a result, if I ask AWS Organization to manage my account, I can deploy in multiple accounts or organisational units. But I’m just using accounts right now, and I’ll specify the account number I’m in, so I’ll copy this and extract the account number. So here is my account number. And I could have multiple account numbers by just having commas, so I can just have many commas and have many different accounts, but for now I’ll just have one because we want to deploy only within my accounts. And then, for a specific region, I’m going to say, “Okay, deploy it to US East North Vernon, Virginia, and deploy it to the US.” and I’m going to say EU London. I’m not deploying to my region, Ireland, because I don’t know if it’s going to conflict with the configuration I’ve already done. So I know that for these two, I haven’t been enabled. So I’ll just enable these two right now. So you can add all regions, you can remove all regions, you can select the regions you want, and you’re free to do however you want.
Then we can specify how many concurrent accounts we can have. So we’re saying, “Okay, one at a time.” That means that only one of these two regions will be deployed first, so maybe Northern Virginia. And then, when it’s done, it will move on to London. And if we have zero fault tolerance, that means that if one of those fails, everything fails and rolls back. Whereas if we have a number saying one, we allow one region to fail. So we’ll just say “zero,” because we don’t want any failures. And click on “next.” Okay, we can review everything. So this is a normal confirmation template that’s just going to be deployed in all the regions right here, specified here in this account. And they say yes; I’m good to go. And click on “Submit.” And here we go. So this is going on, and now we can look at the operations. So the create is running okay, and we can look at stack instances, which is okay, where the stack is being created, and right now it says “outdated,” so it’s bringing the user into the operation. So let’s see what happens if we go to stack set information. Okay, so right now the stack is being created, so this is why it says outdated.
So we just need to wait a little bit. So what we can do in the meantime though is go to US East One and see if the stack is being created over there. So I’m in EU East One, and I’m going to Stacks, and we can see this. The stack is called Stack Set, and the creation is finished. So this stack creation has worked. And if I went into the configuration console for this region, I should see some configuration, and hopefully everything will be configured already. So let’s have a look, get started, and the configuration might already be included. So let’s wait a little bit. Here we go. So we can see from the dashboard that the resources are currently being discovered. So that means that this stack set has been applied to US East 1. And because East One is now finished, It’s current. And now the other region is getting started with the rollout of the confirmation template. That’s because, as you may recall, I select a configuration of one region at a time to maximise the number of concurrent operations. So let’s just wait for this to be over. They’re now both current, and my alias Configenable has been applied to these two regions. But I can do something really cool. I can add new stacks to stack sets and say, “Okay, use the same account,” so use the same account number, but I would like you to add a region, and please add Singapore.
Okay, and I’ll just say next, and we’ll have the same parameters. So we’ll click on “next,” and everything looks good. We submit this, and here we go. Now we’re going to have a third stack instance being created in AP Southeast 1. So it’s really easy to do multiregional deployment and multi-account deployment directly from this UI. Similarly, you can delete stack from the stack sets, so you can say which regions and which accounts you want to delete stack from. So that could be really handy. And you could altogether delete this stack set, which will delete all the stacks from the stack set, obviously. And when you think about it, the use cases for Stack Set are huge. I mean, any template that works in multiregion will work as a stack set. So it’s quite powerful because this is the same confirmation template. But if you look at the simple templates of what we may want to have enabled by this feature, they’re really nice. For example, enabling Cloud Trail in all the regions This is done with one stack set: configuration guard duty. And then maybe you want to add config rules like root account, MFA enabled, roll craft trail enabled, EIP attached, and encrypted volumes as rules directly on all the configurations that we have created in all the regions. So those are just some examples of what you can do with Stack set.
But anytime you want to deploy a confirmation template across multiple regions, then you would need to use stack sets. And then, as we see multiple operations, multiple things are done. And so when we’re ready, we click on “Action Deleting Stack Sets,” which will delete everything. And so we need to first delete all the stacks from the stack sets. So I’ll add all the regions to my accounts. Here we go. As a result, this is added. And now I can go ahead and delete three at a time, for example, and click on Next. And then click on “Submit.” So here we go. Now the operation to delete the entire stack set is running. And now this operation has succeeded. And what I can do next is see that I have zero stack instances, and now I can go ahead and delete this tax set altogether. So that’s it for this lecture on stack sets. Whenever you see global deployment, think cloud formation and stack sets. I hope that was helpful, and I will see you in the next lecture.
27. Continue Rolling Back an Update
So now let’s discuss how we can continue to roll back updates. So whenever a rollback happens, maybe sometimes the rollback itself will be a failure, and you will be in a state named “Update Rollback Failed.” In that case, the resource cannot be returned to its original state, causing the rollback to fail. For example, you roll back an old database instance that was deleted outside of cloud formation. So, for example, we create a stack, it is complete, and the RDS database instance is created as part of my stack. Then we update the stack, which is going to create a new RDS database instance. But the update rollback will fail because the new instance will have a failure as well.
And it turns out that, in the meantime, our user has deleted our previous RDS database. And so therefore this is a very, very edge case, right? But this will trigger an update rollback if it fails. So the solution when you have this is to fix the error manually outside of cloud formation and then continue to do the rollback of the stack. Or you can skip the resources that cannot be rolled back successfully, and then confirmation will automatically mark the failed resources as complete. And if you are in the Update rollback failed state, these are the only two things you can do. You cannot update a stack in this state, so you cannot apply an update on top of it. And in the case of nested stacks, rolling back the parent stack will attempt to roll back all the child stacks as well. So that’s it. Now let’s go hands-on to practise this. Okay, so let’s see how we can trigger an update rollback cells.So we’re going to have a rollback, and first we need to create a stack. So we’re going to specify an image ID for AmazonX Two and we’re going to create an auto-scaling group. Okay? The term “electronic commerce” refers to the sale of electronic goods. So we’ll use the first one from the Aztecs within the region.
So this is a cool way to see a new function called “Get AZ,” which is to find all the availability zones within a region. And then we can select the first one. We have a desired capacity of one and a maximum size of one, and the launch configuration name refers to this specific launch configuration. Now, this launch configuration is very, very simple. We have an image ID that represents the image ID that we have from the parameter. And the instance type is T-2 micro. So, we effectively create an ASG with one EC2 instance, a T2 micro. So let’s upload this template, and I’m going to go into continuing rollback and choose the first one. So demo rollback and next, and then create the stack. So my ASG is now complete. If I go to resources, I can find my launch configuration as well as my auto-scaling group. Okay, so here’s my auto-scaling group, and as we can see here, we have one instance; there’s a capacity of one, and under instance management, we will find our instance right here. Okay, so this is excellent and under launch configuration, as we can see the launch configuration is right here and it has been created.
So now we want to trigger an update and a failure on the update, which will trigger a rollback. So much to do, but let’s go ahead and start the ongoing rollback sale. YAML, so the parameter here is the same as the image ID. The SG has the exact same configuration. So we don’t change anything here, but what we’re going to change is the launch configuration. So the launch configuration now has an instance type of “two nano.” Effectively, this will create a new launch configuration within cloud formation. Okay, so we have this one that is going to be created, and then we also have a wait condition, and the wait condition is a way for the confirmation template to wait for a signal coming from the CFN signal command. Okay? And this weight condition has a cringe-inducing policy of resource signal counts equaling one in the timeout of 1 minute. So what will happen is that this weight condition will never receive a signal because nothing in this template will send a signal to it, and therefore, because the wait condition will have an error, it will go into a rollback state. However, let us add that an employee wanted to create a new launch configuration, so he went ahead and said new launch configuration.
Okay, the AMI is going to be manually done, so I will choose Amazon Linux 2. So Amazon Linux Two Let’s just find the AMI right here. So here is my AMI ID, and I’m going to just do something manual. So this is an employee who does something really bad. So, new LC, here is the AMI that I’m going to put in. Perfect. The instance type is going to be a T2-micro, so I’ll click on “Choose instance type” and again use a T2-micro. This is going to be the same kind of launch configuration but a different physical one within AWS, so everything else looks good, and I’m going to create a new security group. It doesn’t really matter; choose a key pair. Here we go. Acknowledge and create this launch configuration. Okay, so now we’re going to go ahead and update our Otis scaling group, so we’ll edit our Otis scaling group, and the launch configuration that I’m going to use is the new LC. So we go ahead, and we’re good. We do updates, and the update is successful. And now I’m a really, really bad employee. So I’m going to take this one, this old launch configuration, and I’m going to delete it. So this is one that was managed by cloud formation. So we can see now that we’ve updated the launch configuration of our ESG and replaced it with a new one.
And the old one from Cloud Formation is gone. So all of this is a good recipe to trigger the behaviour we want. So we’ll update this and replace the existing templates with new ones. Rollback failed. So this should create another launch configuration. Okay, but this time we will not receive a signal on the weight condition. It will go. into a rollback. But the rollback will fail because the previous launch configuration that was created by confirmation does not exist anymore. So let’s go ahead and look at the chain set. So the LC is going to be modified. And it will perform a replacement. True. So this is going to create a new launch configuration. And the ASG will also be modified as well.And the “wait” condition has been added. So let’s update the stack, and now the update is in progress. The new launch configuration has been created. So if you go in here and refresh, we can find a new launch configuration right here of type T 20. And this launch configuration is going to be applied to my ASG. So this is complete. My ASG does have access to the new launch configuration. And now we have a waiting condition.
So this wait condition, remember, is going to be waiting for a signal. And the signal, it only wants one signal with a one-minute timeout. But this will not happen because we are not sending any signals to our CloudFormation stack. And so, therefore, this will trigger a rollback. So as we can see now, the wait condition failed to receive one resource signal, so the rollback was in progress. Because the LC was updated, the ole was deleted. And then the ASG was supposed to be updated, but now it’s saying, “Hey, this launch configuration with this name, demo, rollback, blah, blah, does not exist anymore,” which is not what was expected. As a result, the ASG has not been rolled back, which is obviously a problem. So we need to fix this. And so for stack actions, we can click on “Continue Update Rollback.” And so we have two options. Either we want to skip this resource, the ASG, or we’re saying, “Hey, it’s okay.” This ASG, we’ll just skip the rollback, and we’re happy with the state it’s in. Or we can just continue, do an update rollback, and try again. Okay, but this is the only way for you to do it. You cannot update this tactic right now. So to solve this problem well, we have to recreate this launch configuration manually to fix our problem. So let’s create a launch configuration. Here is the name: The AMI is going to be the one from before. So let me get it. It’s not very easy to always get it, but let’s go to launch configurations.
Finally, here is my AMI great.The instance type is going to be a T, two micro I will choose that, and I will go ahead and just create my launch configuration. I can choose a key pair; it doesn’t really matter that we’ll have a drift; we can actually see the drift as well; it will be pretty interesting. So now my demo rollback has the right name recreated, and I can again stack action/continue update rollback and continue update rollback. So this is going to try again to do the rollback and update my ASG. But now, because, well, the ASG found the previous launch configuration, it was successful, and therefore we went into a delete complete for the old for the new launch configuration, and the update rollback is complete for my stack, which is cool. And as a bonus, we can detect the drift to see if anything has drifted from our initial configuration. So we can look at the drift results and see that for now everything is in sync. So I guess it did not detect anything special regarding security groups, but that’s the limits of drift. It’s the best effort, I think, in the end. So cool, that’s it for this demo. I hope you liked it; don’t forget to delete your SG; and I will see you in the next lecture.
