Mastering Fleet Updates with AWS Systems Manager Patch Manager

Learning Objectives

After studying this guide, you should be able to:

• Define the core components of SSM Patch Manager including Baselines, Groups, and Maintenance Windows.
• Configure a Patch Baseline with specific approval rules for security and non-security updates.
• Organize managed nodes into Patch Groups using resource tags for targeted updates.
• Schedule automated patching tasks that balance system availability with security compliance.
• Analyze patch compliance reports to identify and remediate non-compliant instances.

Key Terms & Glossary

• Managed Node: Any EC2 instance or on-premises server configured for use with AWS Systems Manager (requires SSM Agent).
• Patch Baseline: A set of rules that defines which patches are approved for installation on your instances (e.g., approve all critical security updates after 7 days).
• Patch Group: An optional organization strategy that associates managed nodes with specific patch baselines using tags.
• Maintenance Window: A defined schedule for when SSM can perform disruptive tasks, like patching and rebooting, on your instances.
• AWS-RunPatchBaseline: The predefined SSM Document (runbook) used by Patch Manager to execute scanning or installation operations.

The "Big Idea"

In a cloud environment, managing security updates for hundreds or thousands of servers manually is impossible and prone to error. SSM Patch Manager shifts the burden from manual intervention to "Policy-as-Code." Instead of deciding what to patch on each server, you define a Baseline (the strategy) and a Maintenance Window (the timing), and AWS handles the execution across the entire fleet, ensuring consistency and security compliance at scale.

Formula / Concept Box

Hierarchical Outline

1. Preparation
   • SSM Agent: Must be installed and running on all target nodes.
   • IAM Role: Instances must have AmazonSSMManagedInstanceCore permissions.
2. Configuration Lifecycle
   • Define Baselines: Select operating system and approval rules.
   • Organize Groups: Use the Patch Group tag key to link instances to baselines.
   • Schedule Execution: Create Maintenance Windows to prevent business downtime.
3. Operations
   • Scanning: Identifying missing patches without changing the system state.
   • Installation: Applying approved patches and handling reboots.
4. Reporting
   • Compliance Dashboard: Visualizing "Compliant" vs "Non-compliant" status.
   • S3 Logging: Exporting detailed patch logs for auditing.

Visual Anchors

Patch Manager Workflow

Instance Targeting Logic

\begin{tikzpicture} \draw[thick, dashed] (0,0) circle (2cm) node[yshift=2.2cm] {\textbf{Patch Group: Production}}; \draw (0.5,0.5) rectangle (1.5,1.5) node[pos=.5] {EC2-A}; \draw (-1.5,0.5) rectangle (-0.5,1.5) node[pos=.5] {EC2-B}; \draw (-0.5,-1.5) rectangle (0.5,-0.5) node[pos=.5] {EC2-C}; \draw[->, thick] (3,0) -- (1.5,0) node[midway, above] {\small Apply Baseline}; \node[draw, fill=gray!20] at (5,0) {\small Default/Custom Baseline}; \end{tikzpicture}

Definition-Example Pairs

• Auto-Approval Delay: The number of days to wait after a patch is released before it is automatically approved for installation.
  • Example: Setting a 7-day delay for "Production" baselines to ensure patches don't cause crashes in "Development" first.
• Patch Compliance: A state indicating whether an instance has all approved patches installed according to its baseline.
  • Example: A dashboard showing 95% compliance because 5 instances failed to reboot after a critical kernel update.
• Rejected Patches: A list of specific patches that should never be installed, even if they meet the approval rules.
  • Example: Explicitly blocking a specific driver update known to cause compatibility issues with your proprietary software.

Worked Examples

Scenario: Securing a Web Fleet

Goal: Automatically install Critical Security updates on all Linux web servers every Tuesday at 1:00 AM, but only after they have been out for 3 days.

1. Step 1: Create Baseline:
   • Select Amazon Linux 2.
   • Rule: Classification = Security, Severity = Critical, Auto-approval delay = 3 days.
2. Step 2: Tag Instances:
   • Add tag Patch Group = Web-Servers to all target EC2 instances.
3. Step 3: Link Baseline:
   • Go to Patch Manager > Patch Baselines > Modify Patch Groups.
   • Add Web-Servers to your new baseline.
4. Step 4: Maintenance Window:
   • Schedule: cron(0 1 ? * TUE *).
   • Register Task: AWS-RunPatchBaseline with Operation: Install.

Checkpoint Questions

1. What is the minimum requirement for an EC2 instance to be managed by SSM Patch Manager?
2. If a patch is released today and your baseline has a 5-day auto-approval delay, will a "Scan" operation show it as missing tomorrow?
3. How does a Patch Group differ from a standard EC2 Resource Tag?
4. What happens to an instance if the AWS-RunPatchBaseline task is set to Scan instead of Install?
5. Where can an administrator look to see which specific patches failed to install on a single node?