Using EC2 Systems Manager to Maintain your Amazon Machine Images (AMI)
[Amazon EC2 System Manager (SSM)] ( https://aws.amazon.com/ec2/systems-manager/ ) is an agent-based solution that allows you to remotely manage and collect inventory data from EC2 instances as well as on-premise Windows and Linux systems.
Outside of managing long-running EC2 instances, you can also use SSM to manage your [Amazon Machine Images (AMI).] ( http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html ) Think of an AMI as a gold-image, it’s a pre-built server image that you can use as part of an [auto-scaling] ( https://aws.amazon.com/autoscaling/ ) solution, reference in a [CloudFormation] ( https://aws.amazon.com/cloudformation/ ) template or when manually deploying an instance via the CLI or through the Management console.
AMI’s play an essential role in your overall AWS Cloud Strategy and because they form the foundation of your EC2 deployment, you need to have a solution in place to maintain them. You can manually update AMIs, but this can become time-consuming, and error-prone. A better solution is to automate the process by using EC2 Systems Manager, the Systems Manager [Parameter Store] ( https://aws.amazon.com/ec2/systems-manager/parameter-store/ ) and [AWS Lambda.] ( http://docs.aws.amazon.com/lambda/latest/dg/welcome.html )
Here’s one possible way to use SSM to help maintain a fleet of AMIs.
Let’s walk through the different components of the example solution.
Parameter Store
The Parameter Store is where we store all the information required to execute our automated AMI patching process. In this particular situation, we’re going to store the latest AMI id and the IAM Roles required to execute the automation job.
Lambda[Platform]UpdateAMI
This Lambda function is triggered via CloudWatch Events and in the example is invoked every Friday AM. It’s responsible for getting the latest AMI information from the Parameter Store and executing the Automation Document. It executes each of the seven steps outlined in the document in sequence.
updateParameterStore
This Lambda function is invoked as the last step of our automation job and is responsible for updating the Parameter store with the newest AMI identifier. Next week, when the job runs again, we’ll use the stored AMI identifier as the starting point.
IAM Roles
Although they are not represented in the diagram, there are a few IAM roles required to make the solution function as expected. First, we’ll need IAM Roles for both our Lambda functions, we also need an IAM Role to allow SSM to interact with different AWS services, and finally, we’ll need an IAM Role (and instance profile) to provide the temporary EC2 instance with the access it requires during the update process
There are a couple of things to keep in mind when deploying a solution like this. First, EC2 Systems Manager leverages the default VPC to implement the temporary EC2 instances used during the update process. If you’ve deleted the Default VPC, you’ll need to [create a new Default VPC.] ( http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html#create-default-vpc )
Also, new Windows AMIs have the SSM agent installed, Linux instances do not - so you’ll have to [install the SSM agent] ( http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/tutorial_run_command.html#tutorial-agent-install ) before getting started. Windows AMIs need a minor update to enable a task which usually executes only the first time the Windows EC2 instance. If you don’t allow the job to run each time the Windows instance starts, the SSM agent won’t be able to get the instance metadata, and the process will fail.
One last thing - while some of the Systems Manager solution is supported by CloudFormation, much of it is not (yet). This means that some of the work I’ve mentioned in this article will need to be performed manually - not great, but doable.