9.2 Systems Manager Patch Manager & Session Manager

9.2 Systems Manager Patch Manager & Session Manager

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your ability to automate operating system patching with Systems Manager Patch Manager, establish multi-tier approval rules using Patch Groups, schedule update cycles via Maintenance Windows, and eliminate bastion hosts using secure, audited Session Manager access.

Systems Manager Patch Manager Architecture & Baselines

Maintaining operating system security compliance across enterprise server fleets requires automated patch evaluation, testing, and deployment. AWS Systems Manager Patch Manager automates operating system patching for Amazon EC2 instances and hybrid servers across Windows Server and Linux distributions (Amazon Linux, AL2023, Ubuntu, RHEL, Debian, SLES).

Under the hood, Patch Manager orchestrates native operating system package managers (yum, dnf, apt, zypper, Windows Update) using the Systems Manager document AWS-RunPatchBaseline.

Default vs. Custom Patch Baselines

A Patch Baseline defines the specific rules governing which operating system patches are approved for installation.

AWS provides Default Patch Baselines for each supported OS (e.g., AWS-AmazonLinux2023DefaultPatchBaseline, AWS-WindowsPredefinedpatchBaseline-OS). These baselines automatically approve all vendor patches categorized as Critical or Important security updates after an auto-approval wait period of 7 days. However, default baselines cannot be modified, do not support custom package exclusions, and cannot be tailored to specific compliance regimes.

Enterprise cloud operations rely on Custom Patch Baselines, configuring granular controls:

• Product Filtering: Explicitly targets specific operating system versions (such as WindowsServer2022, Ubuntu22.04, or AmazonLinux2023).
• Classification & Severity: Filters updates by classification (Security, Bugfix, Enhancement, CriticalUpdates) and severity (Critical, Important, Moderate, Low).
• Auto-Approval Delay: Specifies the number of days to wait after vendor release before a patch is automatically approved (e.g., 10 days or 14 days). This delay creates a vital testing soak buffer, preventing untested zero-day updates from breaking production workloads.
• Compliance Severity Level: Assigns a compliance status severity (Critical, High, Medium, Low) if an approved patch is missing during a compliance scan.
• Approved Patches List: An explicit allowlist that immediately approves critical patches regardless of auto-approval delay rules.
• Rejected Patches List: An explicit blocklist that prevents designated packages (such as a buggy kernel release or incompatible driver) from ever being installed, overriding general approval criteria.

---

Patch Groups & Target Segmentation

To safely roll out updates, administrators segment fleets into staged deployment tiers (Development, Staging, Production) using Patch Groups.

A Patch Group links a Patch Baseline to a designated set of managed nodes:

• Instances are assigned to a patch group using the reserved tag key Patch Group.
• The tag value defines the group name (e.g., Patch Group = Web-Dev or Patch Group = Web-Prod).
• A managed node can belong to only one Patch Group at any given time.
• Each Patch Group is registered to exactly one Patch Baseline within an AWS Region.

---

Maintenance Windows: Scheduled Execution Windows

While Patch Baselines define what patches to install, Systems Manager Maintenance Windows dictate when and how patching operations execute, preventing business disruption.

A Maintenance Window consists of five core components:

1. Schedule: Defined using timezone-aware cron expressions (e.g., cron(0 2 ? * SUN *)) or rate expressions.
2. Duration: The total window duration (between 1 and 24 hours, e.g., 4 hours).
3. Cutoff Buffer: The hours before window end (e.g., 1 hour) when Systems Manager stops scheduling tasks. In a 4-hour window with a 1-hour cutoff, tasks dispatch only during the first 3 hours, leaving the final hour for active tasks and reboots to finish safely.
4. Registered Targets: Instances targeted by tags (e.g., Patch Group = Web-Prod), Resource Groups, or explicit IDs.
5. Registered Tasks: Configured tasks specifying:
   • Task Document: Typically AWS-RunPatchBaseline.
   • Operation Parameter: Scan (evaluates missing patches and reports compliance without changes) or Install (downloads and applies approved missing patches).
   • Reboot Behavior: RebootIfNeeded (restarts if an installed update requires it) or NoReboot (installs updates but defers reboot).
   • Rate Control: Configures Concurrency and Error Thresholds to prevent concurrent patching from causing service outages.

---

Systems Manager Session Manager: Secure Bastionless Access

AWS Systems Manager Session Manager replaces bastion hosts, public IP addresses, and SSH key management with fully managed, auditable shell access:

• Zero Inbound Open Ports: The SSM Agent connects outbound over HTTPS (port 443) to the ssmmessages endpoint. Instance security groups require no inbound rules for SSH (port 22) or RDP (port 3389).
• Centralized IAM Governance: Access permissions are managed entirely through AWS IAM policies. Administrators use tag-based conditions (e.g., ssm:resourceTag/Environment: "Development") to grant access while denying production sessions.
• RunAs OS User Support: Session Manager can enforce launching sessions under a restricted local OS account (e.g., ec2-user or ssm-user) rather than root.
• Auditing & Logging:
  • Terminal session streams are logged in real time to Amazon CloudWatch Logs and archived to Amazon S3.
  • Logs are encrypted using an AWS KMS customer managed key (CMK) to prevent tampering.
  • AWS CloudTrail audits session lifecycle events (StartSession, ResumeSession, TerminateSession).

Port Forwarding and SSH Tunneling via Session Manager Plugin

Using the AWS CLI Session Manager Plugin (session-manager-plugin), operators tunnel traffic securely to private instances:

• Port Forwarding (AWS-StartPortForwardingSession): Forwards a local port to a remote instance or private resource (such as an Amazon RDS MySQL database in an isolated subnet) using AWS-StartPortForwardingSessionToRemoteHost without exposing database ports to the internet.
• SSH Tunneling (AWS-StartSSHSession): Proxies standard OpenSSH and SCP commands over Session Manager via the SSH ProxyCommand directive, enabling secure file copy and IDE remote development without public IPs.