SSM Patch Manager

AWS Systems Manager Patch Manager automates the process of patching managed nodes with security-related updates and other types of updates. You can use Patch Manager to scan for missing patches and apply them on a schedule using maintenance windows. It supports both Windows and Linux operating systems on EC2 instances and on-premises servers (via hybrid activations).

Manual patching is error-prone, time-consuming, and inconsistent. Patch Manager centralizes patch compliance reporting and enforcement, ensuring all nodes meet your organization's security baseline. It integrates with AWS Identity and Access Management (IAM) for permissions, Amazon CloudWatch for monitoring, and AWS Config for compliance tracking.

Patch Manager operates through the SSM Agent installed on each managed node. The agent communicates with the AWS Systems Manager service over HTTPS (port 443). When you initiate a patching operation (either on-demand or via a maintenance window), the following occurs:

- Approval rules (e.g., approve all patches with classification 'Critical' within 7 days of release) - Approved and rejected patch lists (by patch ID, product, classification, severity) - Source repositories for Linux (e.g., Amazon Linux 2 default repo) - Patch Group – A logical group of nodes that share a common patch baseline. You tag instances with a tag key Patch Group and assign a value (e.g., Production). Patch Manager uses this tag to determine which baseline to apply. - Maintenance Window – A schedule (cron expression) that defines when patching can occur. It includes a duration and a set of target nodes. You can also specify a cutoff time so that patching stops if it cannot complete within the window. - Run Command – Used for on-demand patching. You can send the AWS-RunPatchBaseline document to instances immediately. - State Manager – Can be used to enforce a patch baseline on a recurring schedule, ensuring continuous compliance.

Creating a Custom Patch Baseline (AWS CLI):

aws ssm create-patch-baseline \
    --name "Production-Windows-Baseline" \
    --operating-system WINDOWS \
    --approval-rules 'PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=CLASSIFICATION,Values=["Critical","Important"]},{Key=MSRC_SEVERITY,Values=["Critical"]}]},ApproveAfterDays=7}]' \
    --description "Baseline for production Windows servers"

Registering a Patch Group:

aws ssm register-patch-baseline-for-patch-group \
    --baseline-id pb-0123456789abcdef0 \
    --patch-group "Production"

Running a Patch Scan (without installing):

aws ssm send-command \
    --document-name "AWS-RunPatchBaseline" \
    --targets Key=tag:Environment,Values=Production \
    --parameters '{"Operation":"Scan"}' \
    --timeout-seconds 600

Checking Patch Compliance:

aws ssm describe-instance-patch-states-for-patch-group \
    --patch-group "Production"

A large enterprise runs hundreds of EC2 instances across Development, Staging, and Production environments. They need different patch approval timelines: Development patches are applied immediately upon release, Staging waits 3 days, Production waits 7 days after testing. The SysOps team creates three custom patch baselines: Dev-Baseline (ApproveAfterDays=0), Staging-Baseline (ApproveAfterDays=3), Prod-Baseline (ApproveAfterDays=7). They tag instances with Patch Group: Dev, Patch Group: Staging, or Patch Group: Prod. Each baseline is registered with its respective patch group. Maintenance windows are created for each environment: Dev window runs nightly at 2 AM, Staging window runs Tuesday and Thursday at 1 AM, Production window runs Sunday at 3 AM. The team uses AWS Config rules to ensure all instances have the Patch Group tag and are compliant. Common issues include instances missing the tag (they fall back to default baseline, which may not match the desired policy) and maintenance window duration too short for large patch sets (e.g., Windows Server 2012 R2 with many updates). The team sets the duration to 4 hours for Production and monitors CloudWatch alarms for failed commands. They also use SSM Run Command for emergency patching (e.g., zero-day vulnerability) outside maintenance windows.

A company has 50 on-premises servers running Windows Server and Amazon Linux 2. They use AWS Systems Manager Hybrid Activations to register these servers as managed instances. The servers do not have direct internet access; they connect via a VPC endpoint for SSM and an S3 gateway endpoint for patch downloads. The SysOps team creates a single patch baseline for all Windows servers (approving Critical updates within 7 days) and another for Linux servers (approving security updates with severity Critical within 7 days). They tag all on-premises servers with Patch Group: OnPrem. Maintenance windows are scheduled for weekends to minimize impact. A common issue is that on-premises servers may not have the correct SSM Agent version or network connectivity problems. The team uses the AWS-RunPatchBaseline document with Operation: Scan first to verify connectivity and baseline assignment. They also configure CloudWatch Logs to capture patch failure details. Performance considerations: patching on-premises servers over a VPN or Direct Connect can be slower due to latency; the team sets a longer timeout (1800 seconds) for the Run Command.