Automated patch and compliance management with Systems Manager
How to patch a whole fleet on a schedule, prove it stayed compliant, and never SSH into a box to run an update again.
The problem: patching does not scale by hand
Logging into servers to run updates works for three instances and collapses at three hundred. Patches drift, some boxes get missed, and when an auditor asks 'which hosts are missing the latest critical update,' nobody can answer quickly.
AWS Systems Manager Patch Manager solves this by treating patching as a fleet-wide, scheduled, reportable operation. Any server it can reach becomes a managed node: an EC2 instance or an on-premises server running the SSM Agent, with permission to talk to Systems Manager. Once a node is managed, Patch Manager can scan it, patch it, and report its compliance without anyone opening a shell.
From manual patching to a managed-node fleet
Trace
Manual SSH patching collapses at scale. Instead every EC2 instance and on-prem server runs the SSM Agent and registers with AWS Systems Manager, forming one managed-node fleet. A single engineer drives it, per-node patch compliance is recorded centrally, and an auditor can answer 'which hosts are missing critical updates?' without touching a box.
The building blocks: baselines, patch groups, and maintenance windows
A patch baseline is the rulebook: it defines which patches are approved for install, using approval rules based on product, classification, and severity, plus an auto-approval delay so a patch is only auto-approved after it has been available for a set number of days. AWS provides predefined baselines per operating system, and you can create custom baselines when you need tighter control.
A patch group ties nodes to a baseline. You tag a node with the key 'Patch Group' and a value like prod or dev; Patch Manager maps that value to a specific baseline, so production can run a conservative baseline while development runs a more aggressive one, all in the same account.
A maintenance window controls when patching happens. Instead of patching at random, you schedule a recurring window that runs the patch task against a target set of nodes, which bounds the blast radius and keeps reboots inside an approved change slot.
Baselines, patch groups, and maintenance windows
Trace
The three building blocks work together: a patch baseline is the rulebook of approved patches, a patch group is a tag that maps a node to a specific baseline, and a maintenance window schedules when the patch task runs against its targets. This lets prod run a conservative baseline and dev an aggressive one in the same account, with reboots confined to an approved slot.
Scan versus install, and proving compliance
Patch Manager runs the AWS-RunPatchBaseline document with one of two operations. Scan only reports what is missing and updates each node's compliance state; it installs nothing and never reboots. Install actually applies approved patches and can reboot when required. A common pattern is to scan continuously for visibility and install only inside a maintenance window.
The results become patch compliance data in Systems Manager: every node is marked compliant or non-compliant against its baseline. That state can be exported to Amazon S3 for reporting, evaluated by an AWS Config managed rule so drift shows up as a config violation, and wired to Amazon SNS so operators are notified when nodes fall out of compliance. This is the same Config-plus-remediation loop the exam expects for any 'detect and correct drift' scenario.
Scan vs Install and the compliance loop
Trace
Patch Manager runs AWS-RunPatchBaseline in one of two operations. Scan (typically continuous) only reports what is missing and updates compliance state, installing nothing and never rebooting. Install (only inside a maintenance window) applies approved patches and can reboot. Either way the node reports compliance, which is exported to S3, evaluated by an AWS Config managed rule, and drift is pushed to operators through SNS.
What this teaches for the exam
A node cannot be patched until it is a managed node, which means the SSM Agent plus an IAM instance profile granting the AmazonSSMManagedInstanceCore permissions (or the newer Default Host Management Configuration). If patching 'does nothing,' the missing piece is almost always that permission or agent, not the baseline.
Hybrid is first-class: on-premises servers register through the SSM Agent and join the very same fleet, so one patch process covers cloud and data center together. And when a question asks how to separate environments, the answer is patch groups mapping to different baselines, scheduled through maintenance windows, not one-off manual runs.
How a node becomes managed (cloud + hybrid)
Trace
A node cannot be patched until it is a managed node. In the cloud that means the SSM Agent, an IAM instance profile granting AmazonSSMManagedInstanceCore (or account-wide Default Host Management Configuration), and a network path to Systems Manager via interface VPC endpoints or NAT. On-prem servers use a hybrid activation plus a service role. Both paths join the same fleet and only then become eligible for Patch Manager.
