Complete Guide to Automating Monthly Linux Patching with AWS Systems Manager Patch Manager

Managing patches across a fleet of Linux EC2 instances can be challenging and time-consuming. AWS Systems Manager Patch Manager automates this process, allowing you to apply security updates and patches consistently across your infrastructure. This comprehensive guide walks you through setting up monthly automated patching, from prerequisites to compliance monitoring.

What You’ll Learn

• Configure patch baselines for multiple Linux distributions
• Set up patch groups using EC2 tags
• Create maintenance windows with cron expressions for monthly scheduling
• Monitor compliance through AWS dashboards
• Perform on-demand patching when needed

Solution Overview

Patch Manager operates as the central patching tool in AWS Systems Manager. The workflow consists of five key components working together:

1. Patch Baseline — Defines which patches are approved based on classification and severity
2. Patch Groups — Associates target instances with specific baselines using tags
3. Maintenance Windows — Schedules when patching operations run (monthly, weekly, etc.)
4. Patching Task — Executes AWS-RunPatchBaseline to scan and install patches
5. Compliance Reporting — Tracks patch status across your fleet

Prerequisites

Before configuring Patch Manager, ensure your instances meet the following requirements.

Supported Operating Systems

Patch Manager supports the following Linux distributions:

• Amazon Linux 2 and Amazon Linux 2023
• Red Hat Enterprise Linux (RHEL) 7.x, 8.x, 9.x, and 10.x
• Ubuntu Server 16.04 LTS through 24.04 LTS
• Debian Server 9.x through 12.x
• SUSE Linux Enterprise Server (SLES) 12.x and 15.x
• CentOS 7.x
• Oracle Linux 7.x, 8.x, and 9.x
• AlmaLinux 8.x and 9.x
• Rocky Linux 8.x and 9.x

SSM Agent Requirements

The SSM Agent must be installed and running on all target instances. Some distributions come with SSM Agent pre-installed:

To verify the agent is running, connect to your instance and run:

sudo systemctl status amazon-ssm-agent

To check the agent version:

amazon-ssm-agent --version

Network Connectivity

Your instances must communicate with Systems Manager endpoints on port 443 (HTTPS).

For instances in public subnets: Ensure outbound internet access and security groups allow outbound traffic to 0.0.0.0/0 on port 443.

For instances in private subnets: Create VPC Endpoints for these services:

• com.amazonaws.region.ssm
• com.amazonaws.region.ssmmessages
• com.amazonaws.region.ec2messages
• com.amazonaws.region.s3 (Gateway endpoint)

Verification

Confirm your instances appear as managed nodes:

1. Navigate to the Systems Manager console
2. Click Fleet Manager in the left navigation
3. Verify your instances appear with Ping status showing “Online”

💡 Tip: If instances don’t appear, verify SSM Agent is running, confirm the IAM instance profile is attached, check network connectivity, and review SSM Agent logs at /var/log/amazon/ssm/amazon-ssm-agent.log

Step 1: Create Custom Patch Baselines

A patch baseline defines the rules for which patches are approved for installation. While AWS provides default baselines, creating custom baselines gives you greater control. You’ll need a separate baseline for each operating system type.

Navigate to: Systems Manager → Patch Manager → Patch baselines → Create patch baseline

Baseline Configuration

1. Name: Use a descriptive name like Company-AmazonLinux2023-Monthly
2. Description: Monthly security patching baseline for Amazon Linux 2023
3. Operating system: Select your target OS from the dropdown
4. Default patch baseline: Optionally set as default for this OS

Approval Rules

Configure your approval rules based on your organization’s security policies:

• Products: Select “All” or specific product versions
• Classification: Choose patch types (Security, Bugfix, etc.)
• Severity: Select severity levels (Critical, Important, etc.)
• Auto-approval: Set days to wait before auto-approving patches
• Compliance reporting: Select severity level for compliance reporting

⚠️ Auto-approval days explained:

• 0 days: Patches approved immediately (use for critical vulnerabilities)
• 7 days: Provides buffer for testing in lower environments
• Adjust based on your organization’s risk tolerance and change management requirements

Patch Exceptions (Optional)

This section allows you to explicitly approve or reject specific patches regardless of the approval rules:

• Approved patches: Enter specific patch IDs to always approve (comma-separated)
• Rejected patches: Enter specific patch IDs to always reject (comma-separated)
• Rejected patches action: Select “Allow as dependency” or “Block”

Repeat this process for each operating system in your environment (Amazon Linux, RHEL, Ubuntu, SUSE, Debian, etc.).

Step 2: Create Patch Groups Using Tags

Patch groups associate instances with specific patch baselines and enable coordinated rollouts. A patch group is simply a tag value applied to your instances—not a separate resource you create.

Part A: Tag Your EC2 Instances

1. Navigate to the EC2 console
2. Select the instance(s) to include
3. Click the Tags tab → Manage tags
4. Add a new tag:

• Key: Patch Group
• Value: production-linux (or your preferred name)

1. Click Save

📌 Note: The tag key must be exactly “Patch Group” (with a space). The tag value becomes your patch group name.

Part B: Register Baselines to Patch Group

After tagging your instances, register each OS-specific baseline to recognize that patch group name:

1. Navigate to: Systems Manager → Patch Manager → Patch baselines
2. Select your custom baseline (e.g., Company-AmazonLinux2023-Monthly)
3. Click Actions → Modify patch groups
4. Enter your patch group name exactly as tagged (e.g., production-linux)
5. Click Add → Close

Repeat for each OS-specific baseline:

• Select your RHEL baseline → Actions → Modify patch groups → Add → Close
• Select your Ubuntu baseline → Actions → Modify patch groups → Add → Close
• Select your SUSE baseline → Actions → Modify patch groups → Add → Close
• Select your Debian baseline → Actions → Modify patch groups → Add → Close

⚠️ Important: Each patch group can only be registered to one patch baseline per operating system. If you have multiple OS types in the same patch group, register each OS-specific baseline to that group.

Step 3: Create Maintenance Window

Maintenance windows schedule your patching operations. This is where you configure your monthly schedule using cron expressions.

Navigate to: Systems Manager → Maintenance Windows → Create maintenance window

Configuration

• Name: Monthly-Linux-Patching
• Description: Monthly patching window for Linux servers
• Uncheck “Allow unregistered targets” unless specifically needed
• Specify with: Cron/Rate expression
• Cron expression: cron(0 2 ? * SUN#2 *) (Second Sunday at 2 AM UTC)
• Duration: 4 hours
• Stop initiating tasks: 1 hour before window closes
• Timezone: Select your preferred timezone

Cron Expression Examples

Step 4: Register Targets

This step identifies which instances will be patched during the maintenance window.

Navigate to: Systems Manager → Maintenance Windows → Select your window → Targets tab

1. Select your maintenance window (Monthly-Linux-Patching)
2. Click the Targets tab
3. Click Register target
4. Configure:

• Target name: Production-Linux-Servers
• Description: Production Linux servers for monthly patching
• Targets: Select “Specify instance tags”
• Tag key: Patch Group
• Tag value: production-linux
• Click Add to add the tag key-value pair

1. Click Register target

Step 5: Create IAM Service Role

Before registering the patching task, create an IAM role that allows the maintenance window to execute tasks.

1. Navigate to IAM console → Roles → Create role
2. Select “AWS service” as trusted entity type
3. Under Use case, select “Systems Manager”
4. Click Next
5. Search for and attach: AmazonSSMMaintenanceWindowRole
6. Click Next
7. Role name: MW-PatchingRole
8. Click Create role

After creation, update the trust policy:

1. Click on the role to edit it
2. Click the Trust relationships tab
3. Click Edit trust policy
4. Replace the policy with:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

5. Click Update policy

Step 6: Register Patching Task

This defines the action that occurs during the maintenance window—running AWS-RunPatchBaseline to install patches.

Navigate to: Systems Manager → Maintenance Windows → Select your window → Tasks tab

1. Select your maintenance window
2. Click the Tasks tab
3. Click Register tasks → Register Run Command task

Maintenance Window Task Details

• Name: Install-Patches
• Description: Install approved patches on target instances
• New task invocation cutoff: Check “Enabled”

Command Document

• Document: Select AWS-RunPatchBaseline
• Document version: Leave as default

Task Priority

• Priority: 1 (lower number = higher priority)

Targets

• Verify your registered target (e.g., Production-Linux-Servers) is listed under Strict Targets

Rate Control

• Concurrency: Select “percentage” and enter 25
• Error threshold: Select “percentage” and enter 10

IAM Service Role

• Service role: Select MW-PatchingRole

Output Options (Optional)

• S3 bucket: Enable for storing detailed logs
• S3 key prefix: patch-logs/
• CloudWatch logs: Enable for centralized logging
• Log group: /aws/ssm/patch-manager
• SNS notifications: Enable for status alerts

Parameters

• Operation: Select Install
• RebootOption: Select RebootIfNeeded
• Leave other parameters as default

Click Register task

Key Parameters Explained

• Concurrency at 25%: Only 25% of target instances are patched simultaneously, reducing risk of widespread issues
• Error threshold at 10%: If more than 10% of instances fail, the operation stops to prevent further issues
• RebootIfNeeded: Instances only reboot if installed patches require it

Recommended: Phased Patching Strategy

For production environments, implement a phased approach using separate maintenance windows and patch groups:

This provides a one-week buffer between environments for issue identification and resolution before patches reach production.

Compliance Monitoring

After patching operations run, monitor compliance through two primary dashboards.

Patch Manager Dashboard

Navigate to: Systems Manager → Patch Manager → Dashboard

The Dashboard tab provides:

Compliance Summary:

• Summary of compliance status for managed nodes that have reported patch data

Noncompliance Counts:

• Nodes with missing patches
• Nodes with failed patches
• Nodes pending reboot
• Nodes with available security updates

Compliance Reports:

• Visual pie chart showing compliance percentages
• Compliance reported within the past 7 days (green)
• Compliance not reported within the past 7 days (yellow)
• Compliance never reported (red)

Non-patch Policy-based Operations:

• Lists recent patching operations with status, document name, and affected targets

Compliance Reporting Tab

Navigate to: Systems Manager → Patch Manager → Compliance reporting

Generate detailed compliance reports in CSV format:

1. Click “Export to S3”
2. Configure report name and S3 bucket
3. Choose one-time or scheduled report generation

Systems Manager Compliance Dashboard

Navigate to: Systems Manager → Compliance (under Node Tools)

This dashboard provides a unified compliance view with filtering options:

• Group by: Compliance type, Patch group, or Resource group
• Filter: Search for specific resources
• Toggle: Switch between “Resources” and “Rules” view

Compliance Resources Summary:

• Compliance type (Association or Patch)
• Compliant resources count
• Non-compliant resources count
• Severity breakdown (Critical, High, Medium, Low)

On-Demand Patching (Patch Now)

While scheduled maintenance windows handle routine patching, sometimes you need to patch immediately.

Method 1: Patch Now via Patch Groups (Recommended)

1. Navigate to: Systems Manager → Patch Manager → Patch groups tab
2. Select your patch group (e.g., production-linux)
3. Click Patch now
4. Configure:

• Patching operation: Select “Scan and install” or “Scan”
• Reboot option: Select “Reboot if needed”
• Patching log storage: Select an S3 bucket (optional)

1. Click Patch now

Method 2: Patch Now via Dashboard

1. Navigate to: Systems Manager → Patch Manager → Dashboard
2. Click Patch now button (top right)
3. Configure:

• Patching operation: Select “Scan and install” or “Scan”
• Instances to patch: Choose one of:
  • Patch all instances
  • Patch only the target instances I specify
  • Patch instances using tags
• Reboot option: Select “Reboot if needed”
• Patching log storage: Select an S3 bucket (optional)

1. Click Patch now

Monitoring the Patching Operation

After initiating “Patch now”, you’re taken to the Run Command execution page showing:

• Overall status: In Progress, Success, or Failed
• Summary: Number of targets, completed, errors, and timed out
• Per-instance status:
• Pending: Waiting to start
• In Progress: Currently patching
• Success: Completed successfully
• Failed: Encountered an error

Click on any instance ID to view detailed output and logs.

Troubleshooting Common Issues

Instances Not Appearing in Fleet Manager

• Verify SSM Agent is installed and running
• Confirm IAM instance profile is attached with correct permissions
• Check network connectivity (security groups, NACLs, VPC endpoints)
• Review SSM Agent logs: /var/log/amazon/ssm/amazon-ssm-agent.log

Patching Fails on Specific Instances

• Check instance has sufficient disk space
• Verify package manager repositories are accessible
• Review Run Command output for specific error messages
• Ensure no package manager locks are held by other processes

Compliance Shows “No Data”

• Ensure at least one patching operation (Scan or Install) has run
• Verify instances are properly tagged with Patch Group
• Check that patch baselines are registered to the patch group

Conclusion

AWS Systems Manager Patch Manager provides a robust solution for automating Linux patching across your EC2 fleet. By implementing patch baselines, patch groups, and maintenance windows, you can ensure consistent security updates while minimizing operational overhead. The phased patching strategy adds an extra layer of safety for production environments, and the compliance dashboards give you visibility into your patch status at a glance.

References

• AWS Systems Manager Patch Manager Documentation
• Patch Manager Prerequisites
• Supported Operating Systems
• Find AMIs with SSM Agent Preinstalled
• SSM Agent Installation Guide
• Configure Instance Permissions
• VPC Endpoints for Systems Manager
• Working with Maintenance Windows
• Troubleshooting Patch Manager