Automate EC2 Patch Management with SSM Patch Manager (2026)

SSM Patch Manager doesn’t just install patches; it orchestrates a complex, stateful dance between your EC2 instances and the AWS control plane to ensure security compliance.

Let’s see it in action. Imagine you have a fleet of t3.micro EC2 instances tagged with Environment: Production. You want to patch them every Sunday between 2 AM and 4 AM UTC with a "Critical" and "Security" patch severity.

First, you need an SSM Maintenance Window. This defines when patching can occur.

aws ssm create-maintenance-window \
    --name "Weekly-EC2-Patching-Prod" \
    --description "Patch Production EC2 instances weekly" \
    --schedule "cron(0 2 ? * SUN *)" \
    --duration 2 \
    --window-days-of-week SUN \
    --window-start-date "2023-10-29T02:00:00Z" \
    --tags Key=Project,Value=SecurityPatching

This creates a window that recurs every Sunday at 02:00 UTC and lasts for 2 hours. The cron(0 2 ? * SUN *) syntax is a bit arcane, but it translates to "at minute 0 of hour 2, on any day of the month, in any month, on Sunday."

Next, you need to tell the Maintenance Window what to do. This is an SSM Maintenance Window Task. For patching, we’ll use the AWS-RunPatchBaseline document.

aws ssm register-task-with-maintenance-window \
    --window-id "mw-0123456789abcdef0" \
    --task-type "RUN_COMMAND" \
    --task-arn "AWS-RunPatchBaseline" \
    --task-name "Patch-EC2-Prod" \
    --priority 10 \
    --targets Key=tag:Environment,Values=Production \
    --max-concurrency "5" \
    --max-errors "1" \
    --service-role-arn "arn:aws:iam::123456789012:role/aws-service-role/ssm.amazonaws.com/AWSServiceRoleForAmazonSSM" \
    --document-version "1" \
    --parameters '{"Operation": ["Install"],"Classification": ["Critical","Security"],"RebootOption": ["RebootIfNeeded"]}'

Here’s what’s happening:

• --window-id: The ID of the Maintenance Window we just created.
• --task-type "RUN_COMMAND": We’re executing an SSM document.
• --task-arn "AWS-RunPatchBaseline": This is the SSM document specifically designed for patching.
• --targets Key=tag:Environment,Values=Production: This is crucial. It tells SSM which instances to target – those with the tag Environment: Production.
• --max-concurrency "5": Only 5 instances will be patched at a time. This prevents overwhelming your network or application during the patching window.
• --max-errors "1": If more than 1 instance fails patching, the entire task for this window run will stop. This prevents a cascade of failures.
• --service-role-arn: The IAM role SSM assumes to perform actions on your behalf (like installing patches, rebooting instances). This role needs permissions like AmazonSSMManagedInstanceCore and potentially AmazonEC2ContainerRegistryReadOnly if you’re patching Docker images.
• --parameters: This is where we configure the AWS-RunPatchBaseline document:
  • "Operation": ["Install"]: We want to install the patches.
  • "Classification": ["Critical","Security"]: We’re only interested in critical and security updates.
  • "RebootOption": ["RebootIfNeeded"]: If a patch requires a reboot, the instance will be rebooted.

SSM Patch Manager uses Patch Baselines to define what patches are approved. You can create custom baselines or use the default ones (like AWS-Default-Patch-Baseline). A baseline specifies rules for patch inclusion/exclusion based on classification, severity, and KBs. The AWS-RunPatchBaseline task references a baseline to determine which patches to apply. When you don’t explicitly specify a baseline in the task, it uses the default one associated with the region and OS.

The system works by having the SSM Agent installed on your EC2 instances. When a Maintenance Window task is scheduled and an instance matches the targets, the SSM Agent polls the SSM service. If it finds a task assigned to it, it downloads the AWS-RunPatchBaseline document and executes it according to the specified parameters, reporting its progress back to SSM.

What most people don’t realize is how granular the AWS-RunPatchBaseline parameters can get. Beyond Classification and RebootOption, you can specify Products (e.g., Windows, Amazon Linux 2), Patches (a list of specific KBs or CVEs to include or exclude), and even MsrcSeverityLevel (a more detailed mapping of Microsoft Security Response Center severities). This allows for incredibly precise control over your patching strategy.

The next thing you’ll likely encounter is managing different patching strategies for different environments, which leads to creating multiple custom Patch Baselines and associating them with specific Maintenance Window tasks or even instance tags.