EC2 Patch Management with AWS Systems Manager: Keeping Instances Current

The most common unforced error in EC2 fleet management is running instances on operating system versions that stopped receiving security updates months ago. It's not intentional neglect — it's the natural result of treating EC2 instances like servers rather than infrastructure. Servers get patched when someone remembers. Infrastructure gets patched on a schedule, automatically, with auditability built in. The difference between these two approaches determines whether your EC2 fleet passes an AWS Inspector scan or generates a list of critical vulnerabilities long enough to fill a spreadsheet.

AWS Systems Manager Patch Manager handles the operational complexity of fleet-wide patching. It maintains patch baselines per operating system, integrates with maintenance windows for scheduled downtime, and provides compliance reporting that shows which instances are current and which have outstanding critical patches. This guide covers the full setup and operational model.

How Patch Manager Works

Patch Manager requires the SSM Agent on each managed instance and an instance profile with permissions to call SSM APIs. The agent is pre-installed on Amazon Linux, Ubuntu Server, and Windows Server AMIs; for other operating systems you install it manually or bake it into your AMIs.

The patch workflow involves three components. A patch baseline defines which patches are approved for installation — either automatically by classification and severity, or explicitly by patch ID. A patch group tags instances that share a patching schedule, allowing you to patch production instances on a different schedule than staging. A maintenance window defines when patching runs and what action to take (scan only, install, or install and reboot).

Patch Manager integrates with AWS Inspector for vulnerability context. Inspector identifies CVEs present on your instances; Patch Manager closes them. The two services work together — Inspector finds the problems, Patch Manager fixes them.

Setting Up Patch Baselines

AWS provides pre-defined patch baselines for Amazon Linux, Ubuntu, CentOS, RHEL, Windows Server, and other supported operating systems. These baselines auto-approve security patches released 7 days ago or later, which strikes a balance between speed and stability — new patches have a short soak period before being automatically deployed to your fleet.

For most organizations, the default baselines are a reasonable starting point. Customize them when you have specific requirements: rejecting patches for packages that conflict with your application, adding a longer auto-approval delay for production versus development, or requiring explicit approval for major version updates.

Create a custom baseline by navigating to Systems Manager Patch Manager and clicking "Create patch baseline." Specify the operating system, define auto-approval rules based on patch classification (Security, Bugfix, Enhancement) and severity (Critical, Important, Medium, Low), and optionally set a rejection list for specific patches known to cause issues.

Instance Discovery and Patch Group Tagging

Patch Manager discovers managed instances automatically through the SSM fleet manager. Any instance with the SSM agent installed and an instance profile with the managed policy AmazonSSMManagedInstanceCore appears in the managed instances list. This profile can be attached to existing instances without requiring a restart — it takes effect the next time the SSM agent contacts the service.

Patch groups segment your fleet for different patching schedules. Tag each instance with the key Patch Group and a value that describes its environment — Production, Staging, Development. Associate each patch baseline with one or more patch groups, and create separate maintenance windows for each group with different schedules and approval lag times.

A common pattern: development instances patch on Tuesday nights, staging patches Wednesday nights with 2 hours of post-patch testing, and production patches Thursday nights only after successful staging patching. This cascading model catches patch-introduced regressions before they reach production.

Maintenance Windows and Patch Execution

Maintenance windows define the time slots when Patch Manager can take patching actions. Each window has a schedule (cron expression), a duration, and a cutoff — the time before the end of the window when no new patch operations start. Configure windows conservatively: 4-hour windows with 1-hour cutoffs give adequate time for patching and rebooting without running past the window end.

Create maintenance window tasks that run the AWS-RunPatchBaseline document. This document checks the instance's patch group, finds the appropriate baseline, downloads and installs approved patches, and reboots if required. Set the concurrency to a percentage rather than a fixed number — patching 20% of instances at a time means the others remain available during patching, which matters for load-balanced services.

For production instances where reboots require coordination with the application team, use two tasks: first a scan task that identifies required patches and reports compliance status, then a separate install task run only after the application team confirms they're ready for the maintenance window. This gives teams visibility into upcoming patches without forcing immediate installation.

Patch Compliance Reporting

After each patching run, Patch Manager updates compliance data in Systems Manager. Query this data through the SSM console, the AWS CLI, or push it to an S3 bucket for longer-term analysis. The compliance report shows each instance's patch state: compliant (all approved patches installed), non-compliant (approved patches missing), or not configured (instance not managed by Patch Manager).

Create a CloudWatch alarm that fires when non-compliant instance count exceeds a threshold. A new critical vulnerability that Patch Manager hasn't addressed yet will show up as a compliance violation within hours of the patch becoming available. Combined with AWS Inspector's vulnerability scanning, this gives you a complete view of your patch exposure.

AWS Config also tracks patch compliance through the ec2-managedinstance-patch-compliance-status-check rule. This Config rule provides an additional compliance record that integrates with Security Hub and your existing Config aggregation setup.

Handling Immutable Infrastructure

If your EC2 instances are immutable — launched from AMIs, never patched in place, replaced rather than updated — the patching model is different. Instead of patching running instances, you update the AMI using EC2 Image Builder or a custom pipeline that runs Patch Manager on a fresh instance, captures the AMI after patching, and updates your launch templates to reference the new AMI.

EC2 Image Builder has native Patch Manager integration. Add the UpdateOS component to your build pipeline and Image Builder will run Patch Manager against the builder instance before capturing the AMI, ensuring every AMI you produce starts life fully patched.

Related Reading

• EC2 security groups audit — network controls that complement patch management
• IMDSv2 migration — another essential EC2 security baseline item
• Essential AWS Config rules — compliance reporting for patch state and other controls
• AWS account suspension prevention — how security posture affects suspension risk

FAQ

Do I need to pay extra for AWS Systems Manager Patch Manager?

Patch Manager is included with Systems Manager at no additional charge for on-premises instances using the standard tier. For EC2 instances, the SSM service itself is free. You pay for the EC2 instances and any data transfer costs. The only Systems Manager cost to watch is Advanced Instances tier, which is needed for some features on non-EC2 managed instances and carries a per-instance-hour charge.

Can Patch Manager patch Windows Server instances?

Yes. Patch Manager supports Windows Server 2008 R2 through the current version. It uses Windows Update under the hood and respects your patch baseline settings. For Windows instances, Patch Manager also supports patching Microsoft applications like SQL Server and .NET components in addition to the OS itself.

How do I handle instances that can't be rebooted?

Some patches require a reboot to take effect; others don't. You can configure Patch Manager to "Install without reboot" and patch kernel and other reboot-required packages separately during planned downtime. This approach is common for production databases and stateful services that can't easily tolerate unexpected reboots. Track which patches are pending reboot separately from which are installed — an installed-but-not-rebooted kernel patch doesn't protect against the vulnerability it addresses.