Keep Your EC2 Instances Always Up To Date with AWS Systems Manager Maintenance Windows

If you run an EC2-based workload in AWS, you must have a patching strategy in place. Otherwise, you leave yourself exposed to all kinds of vulnerabilities that are discovered in software systems these days almost every day.

Maybe yours is a small workload and manually SSHing into the instances and running yum update once in a while meets your needs. But this isn’t feasible for larger systems with hundreds of instances in play.

Fortunately, AWS Systems Manager provides many services to manage EC2 instances. Using Systems Manager’s Run Command or Patch Manager service, you can update your instances at any time in bulk. Moreover, using Maintenance Windows, you can schedule and automate common instance management tasks like updates!

In this article, you will learn how Maintenance Windows work by using it to schedule updates for a single instance. You will then see how to scale up this operation for any number of instances and even customize which updates are applied when.

Before we begin, make sure you have an EC2 instance that is managed by Systems Manager. If you don’t already, follow the steps in our earlier article to create one:

Still Using EC2 Key Pairs? Switch to Session Manager Now!

Create Maintenance Window

With an instance ready, start by creating a maintenance window. Go to Click Create Maintenance Window:

Provide a name and description, and allow unregistered targets for now so we try it out without registering our instance with this window:

Next, provide a time when the maintenance tasks should run. In this case, we’re setting it to run at midnight every night:

Depending on how long you think the tasks in your window will need to run, set an appropriate duration:

A window can have several tasks on its to-do list. It will invoke them one-by-one during the specified time window until all of them are done. The “Stop initiating tasks” setting above controls how long before the end of the time window, Systems Manager should stop initiating tasks (since they may not complete in time).

By default, this window will take effect as soon as it’s created. If you prefer it to be active between a certain date range, provide it next:

Finally, click Create Maintenance Window.

Add Maintenance Tasks

We are now ready to start adding maintenance tasks to this window. Open the task in the console by clicking its ID, switch to the Tasks tab, and select “Register Run Command Task”:

Select the AWS-RunPatchBaseline command document:

This document scans for and installs patches on your instances in accordance with a patch baseline. We’ll see what a patch baseline is later.

Back in the create task screen, select the instance you created earlier as the target of this task:

When you do this on a large scale, rate control will come in handy. It lets you control how many instances at a time should be patched and how many failures are acceptable:

The service role grants the maintenance windows service, the permissions it needs to access and act upon the instances:

In the parameters section, select “Install” as the operation. “Scan” will simply create a report of the missing patches but won’t install them. If it’s OK to reboot your instances without affecting your apps, set the Reboot Option as RebootIfNeeded. The timeout specifies how long this task can run before being forcefully terminated:

Finish creating the task.

You have now automated updates on your instance. The task will run automatically at midnight every night.


We have explored a very small part of the capabilities of Systems Manager. There is a lot more you can do.

You can create patch baselines which are a set of rules that determine when it’s safe to apply certain patches, when patches should be auto-approved for instances, or if they need manual approval.

You can also group your instances into patch groups for patching purposes using tags. For example, set Patch Group = Web Servers on your web servers; then you can target this group for maintenance activities without disturbing other instances.

About the Author ✍🏻

Harish KM is a Principal DevOps Engineer at QloudX & a top-ranked AWS Ambassador since 2020. 👨🏻‍💻

With over a decade of industry experience as everything from a full-stack engineer to a cloud architect, Harish has built many world-class solutions for clients around the world! 👷🏻‍♂️

With over 20 certifications in cloud (AWS, Azure, GCP), containers (Kubernetes, Docker) & DevOps (Terraform, Ansible, Jenkins), Harish is an expert in a multitude of technologies. 📚

These days, his focus is on the fascinating world of DevOps & how it can transform the way we do things! 🚀

Leave a Reply

Your email address will not be published. Required fields are marked *