Managing instances through scripts
Start course
1h 5m

Please note: this course has now been removed from our content library. If you want to study for the SysOps Administrator Associate Level Certification, we recommend you take our dedicated learning path for that certification that you can find here.


The AWS Certified SysOps Administrator (associate) certification requires its candidates to be comfortable deploying and managing full production operations on AWS. The certification demands familiarity with the whole range of Amazon cloud services, and the ability to choose from among them the most appropriate and cost-effective combination that best fits a given project.

In this exclusive Cloud Academy course, IT Solutions Specialist Eric Magalhães will guide you through an imaginary but realistic scenario that closely reflects many real-world pressures and demands. You'll learn to leverage Amazon's elasticity to effectively and reliably respond to a quickly changing business environment.

The SysOps certification is built on solid competence in pretty much all AWS services. Therefore, before attempting the SysOps exam, you should make sure that, besides this course, you have also worked through the material covered by our three AWS Solutions Architect Associate level courses.

If you have thoughts or suggestions for this course, please contact Cloud Academy at


Hi and welcome to our fourth lecture. In this lecture, we will start planning our new deployment. But before that, there are some things that we will need to clarify, to make sure that you understand how things are being created. Over the next two lectures, we will create a new elastic infrastructure for Cloud Motors. We will end up with something like this. You could create auto scaling for custom applications using AMIs, but there's no challenge to that. We will choose the most cost effective way. We will bootstrap our application and deploy auto scaling in a way that we will not have to change if we ever create a new version of our portal.

We need to understand these three topics before starting. User data is a way to run code on your AWS instances. The data runs only once, at the instance's launch. You can check this user data, both through the console or inside the instance. Meta data is information about the instance. This information is available inside the instance, and you can use it to manage or configure anything you desire inside the instance itself. It's very helpful for scripting. CFN-init is a helper script, that makes use of both user data and metadata, that you can run on your instance to query for metadata on the cloud formation init key, at the cloud formation template. It reads and is responsible for running the code in your instance. Too complicated? It's probably best to show you how we interact with them, using a hands on example. Maybe after that, you will better understand these topics. I'm on the EC2 dashboard. If you select any instance that has user data, go to actions, instance settings, view change user data, and you'll be able to see the user data. In our case, it is a shell script. No need to understand what it does right now. Just let me copy this script and I will launch another instance with this user data to see what happens. I will select Amazon Linux because it is the image we're using. I will select a T2.micro instance, where we will need to click on advanced details to see the user data field and paste the script. Next, let me name the instance. Here, I will use the security group that cloud formation has created, and click launch. Okay. Let's wait for the results. In the meantime, I'll show you how to query the instance metadata. For that, we need to connect to our instance, using SSH.

We need to use curl to query metadata on Linux machines. We just type curl

Here, we can see the categories to query. It's important to use the slash on the end of the URL. Otherwise, it will return nothing. Let's query something. For instance, I would like to know the instance ID. I just need to type it to see the results. Another example, we can also query the user data inside the instance.

For that, we just need to change metadata to user data, with a dash in the middle. Here it is. The same user data we saw in the console is available here. You could run it again using shell commands, for instance. Another tool that we have is CFN init, which is present on our script, and also present in the instance. It is part of the AWS bootstrapping tools, and is available by default on Amazon Linux. CFN signal is also part of this set of tools.

It's used to send signals from the instance to cloud formation. Let me show you the code behind our cloud formation template. There's no need to understand that. I just want to show you where CFN init grabs the metadata that we need. Here in resources, we can see our rails server resources, and on its metadata, we see the cloud formation init key, that has a config setting called full install. And it has these steps, which are described here.

You can see the steps as they are human readable. There's no need to an expert to know what's going on. After you perform all these steps, cloud formation will call CFN signal to tell the stack that the resource was successfully created. Here, we also can see the user data, since the parameter of CFN signal is dependent on information that's created during the stack creation. We can see in here that I've specified reference tags for them.

This function reads them and then launches with the script, the proper values. We could also use CFN init's descriptive language to personalize our instance, without the need to have a cloud formation template see the script. It will do almost the same things as this script does, but with descriptive language. It uses YML syntax. The benefit for us is that you can use CFN init even without cloud formation.

To see the output of what user data is doing, we could select the instance. Go to actions, instance settings, and get system log. It will show us the output of everything that the instance runs during its launch. Now let's take a look at the instance we launched earlier to see what happened. It has created another front end server for our application. See that I have both instances opened on my browser.

This is not part of the cloud formation stack. We can check the tags to see that there's no tag related to the cloud formation stack, like this other instance has. Look. Our fancy tag is in here as well. Amazing, isn't it? In the next lecture, we'll use what we learned here to apply auto scaling.


About the Author

Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.