We love Amazon EC2 instances because of how easy they are to deploy and we have a huge catalog of templates (AMIs) to choose from which really speeds up our provisioning. But once those instances are up and running it would be really nice to have some methods of managing those instances. Luckily, Amazon has developed several capabilities to help manage Amazon EC2 instances after they’ve been deployed. These capabilities are used to execute scripts, manage patches and kick off automation routines within an EC2 instance, directly from the AWS console.

AWS EC2 Systems Manager Capabilities

The following non-exhaustive list of capabilities are currently available through Amazon EC2 Systems Manager:

• Run Command – Allows you to execute commands directly on an EC2 Systems Manager enabled instance.
• State Manager – Allows you to specify a desired state for an EC2 Systems Manager enabled instance.
• Automations – Allows for the automation of deployment tasks.
• Patch Management – The ability to monitor and manage the deployment of patches.
• Inventory – Is a way to collect software inventory from your managed instances.
• Parameter Store – Centralizes configuration data such as passwords.

Setting up Managed Instances

SSM Agent

The first thing to know is that not all instances deployed through AWS are considered managed instances. To be used with the EC2 Systems Manager capabilities, instances must have an SSM Agent installed on them. Out of the box, a Windows Server 2003-2012 R2 AMI published in November 2016 or later will automatically have the SSM Agent installed on them. If you have an EC2 instance deployed through an Amazon AMI published before this date you should update the instance with the latest agent or redeploy from a more recent AMI. For Linux instances, the SSM Agent is not installed by default. You must install the SSM Agent on a Linux instance before any of the cool toys can be used with them. Luckily for us this is pretty simple for deploying new instances.

During the deployment of a Linux instance, under the Advanced Details, some user data can be added so that the agent is downloaded and installed upon initial provisioning. The example below is the user data that I used to deploy a CentOS instance on Amazon EC2. The commands for your favorite flavor of Linux can be found on the Amazon documentation page: http://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html#sysman-install-ssm-agent

The SSM Agent will need to be able to communicate back to the EC2 Systems Manager service which means that it requires outbound Internet access. The agent will check in with the service so outbound access is required while inbound access is not.

Supported Operating Systems

Not all operating systems are supported with Amazon EC2 Systems Manager capabilities. Obviously these will change so I recommend checking the latest documentation, but the current operating systems supported include:

Windows

• Windows Server 2003 (including R2)
• Windows Server 2008 (including R2)
• Windows Server 2012 (including R2)
• Windows Server 2016

Linux

• 64-bit and 32-bit
  • Amazon Linux 2014.09, 2014.03 or later
  • Ubuntu Server 16.04 LTS, 14.04 LTS, or 12.04 LTS
  • Red Hat Enterprise Linux (RHEL) 6.5 or later
  • CentOS 6.3 or later
• 64-bit Only
  • Amazon Linux 2015.09, 2015.03 or later
  • Red Hat Enterprise Linux (RHEL) 7.x or later
  • CentOS 7.1 or later
  • SUSE Linux Enterprise Server (SLES) 12 or higher

Region Limitations

As with most Amazon Web Services solutions, they are not available across all regions. EC2 Systems Manager is no exception. For a full list of regions please visit: http://docs.aws.amazon.com/general/latest/gr/rande.html#ssm_region

Setting Up Permissions

Before we start using the services we’ll want to have our permissions and roles ready to go. First, your login must have permissions to access the Amazon Systems Manager console. If you’re an administrator for the VPC in which the EC2 instances will live, then you already have sufficient permissions. If not, you’ll want to assign your user account the AmazonSSMFullAccess policy to the account.

Now that we’ve confirmed that the user account will have the correct permissions to take actions on the instances, we also need to assign some permissions to the EC2 instances that will be managed. We’ll create a role and assign it to our instance so that it has the correct permissions to interact with the EC2 Systems Manager Service.

To do that we’ll create a new role through the IAM console. Create a new role and select the Amazon EC2 service role.

From there type SSM in the policy type to filter down the list and then select the AmazonEC2RoleforSSM in the list.

Give the role a name and pay attention to what it is. We’ll use the name again later when spinning up our instances. Click Create Role.

Setup CloudWatch Events

If we want to log our commands executed through Systems Manager, we can use CloudWatch Events as well. This is an optional setup task but useful for enterprise deployments. To get started go to the CloudWatch service and create a new rule under Events. In the service name select the EC2 Simple Systems Manager (SSM) and then under type select which event type you want to alert on. I selected just Run Command but you can pick whatever you’d like. In the Targets section I have selected a Simple Notification Services topic named “NotifyMe” which I setup previously.

Deploy Some EC2 Instances

We’ve got things ready to go but we’ll need some test instances to manage. Go to the EC2 instances page and select a supported server type from the list. I’ll choose the Amazon Linux AMI for this example. We’ll want to do the standard things for deploying an EC2 instance such as selecting a family and a type. The important steps for working with EC2 Systems Manager are configuring the instance details. On the “Configure Instance” page change the IAM role to the role that we created in the section above. In my case it’s EC2SystemsManagerRole.

Then further down enter our user data to perform the installation of the SSM Agent during provisioning.

Complete the EC2 deployment with your own settings for networks, tagging, storage and all the other properties that make sense in your environment.

Summary

We haven’t gotten to see the power of the EC2 Systems Manager services yet, but we have a good foundation ready to go and in the next posts we can start playing with the services. To read more about the real power of EC2 Systems Manager, check out the links below.

Additional Posts on Systems Manager:

Run Command

Patch Compliance