Systems Manager Automation

Configuration management on existing solutions

Task 3.1 lists configuration management tools (for example, AWS Systems Manager) and the skill of recommending automation for that management. SAP-C02 is not asking you to memorize every SSM document name. It is asking whether you can keep hundreds of managed nodes in a defined state, patch them without taking a trading floor down at noon, reach them without bastions, and turn CloudWatch alarms into guided work items.

AWS Systems Manager operates managed nodes: Amazon EC2 instances, on-premises servers, and edge devices running SSM Agent. Hybrid nodes use a hybrid activation. Once a node is managed, Patch Manager, State Manager, Inventory, Session Manager, and Run Command share that identity. If the exam stem still has unmanaged EC2, the first automation step is often an instance profile (or hybrid activation) plus agent health—not a new AWS Config rule.

Patch Manager and the trading-hours window

Patch Manager applies OS and (on Windows, Microsoft-released) application patches using patch baselines that approve patches by classification, severity, and auto-approval delays. The command document AWS-RunPatchBaseline supports Linux, macOS, and Windows Server (SSM Agent 2.0.834.0 or later). It replaces the Windows-only legacy AWS-ApplyPatchBaseline. Required parameter: Operation (scan versus install). Optional parameters include RebootOption, BaselineOverride, and Snapshot ID. AWS recommends supplying a snapshot ID when you run the document outside a maintenance window so a batch of nodes installs the same approved set; inside a window, Patch Manager can supply that value.

Potentially disruptive work—reboots, kernel updates, driver installs—belongs in Maintenance Windows, which define a clock-bounded schedule, duration, cutoff (stop starting new tasks before the window ends), targets (IDs, tags, resource groups), maximum concurrency, and maximum error rate. Register AWS-RunPatchBaseline as a Run Command or Automation task in that window. A 02:00–04:00 window with concurrency 10 percent and a 5 percent error cutoff is the professional pattern for “do not reboot during trading hours.”

State Manager can also run patch documents on a cron, but AWS’s comparison is explicit: State Manager is for continuous desired state and compliance; Maintenance Windows are for high-priority, time-sensitive, disruptive tasks in a period you specify. Using State Manager to patch-and-reboot all day is how you fail the patch-window scenario.

State Manager versus Maintenance Windows

Desired state versus a change window

State Manager associations apply an SSM document (Command, Policy, or Automation) and re-apply it so configuration drift is corrected: CloudWatch agent installed, daemon running, tags present, security group rules enforced via Automation, nodes joined to a domain. Associations can target IDs, tags, resource groups, or all managed nodes in the account. Safety controls: max concurrency and max errors. Associations are the right answer for “keep the agent config identical forever.”

Maintenance Windows support four task types: Run Command, Automation, AWS Lambda, and AWS Step Functions (Standard workflows only, not Express). Tasks run in parallel unless you set priorities. Windows can target many resource types besides nodes (for example S3 buckets) when you use resource groups. Both tools have concurrency and error-rate brakes; only windows give you a cutoff tied to a change calendar.

Automation runbooks

An Automation runbook is an SSM document of type Automation (schema 0.3) in YAML or JSON: sequential steps with parameters. AWS ships predefined runbooks to restart instances, create images, and remediate common issues. Custom runbooks encode your recovery actions so they are invocable from OpsCenter, Config, EventBridge, or a window. Execution uses an Automation assume role; if you attach a runbook to a maintenance window without a per-task role, the window service role must be allowed to perform every step.

Session Manager

Session Manager is a fully managed shell and port-forwarding tool for EC2, on-premises, and edge nodes. Benefits AWS documents: no inbound SSH or RDP ports, no bastion fleet, access via AWS Identity and Access Management (IAM) policies instead of distributed SSH keys, optional encryption, and session logging to CloudWatch Logs or Amazon S3 (and optionally CloudTrail for start/end). A session is a connection from the console, AWS CLI, or SDK through the Systems Manager service to SSM Agent. For SAP-C02, Session Manager is the answer when auditors forbid 0.0.0.0/0 on port 22 and want who-did-what logs. Storing SSH private keys in Parameter Store is not that design.

Inventory, Parameter Store, and OpsCenter

Inventory gathers metadata (applications, files, network config, custom JSON) on a schedule, typically via the AWS-GatherSoftwareInventory policy document and a State Manager association. Pair Inventory with AWS Config to audit configuration over time, and use a resource data sync to an S3 bucket for fleet analytics. Inventory answers “what is actually running”; it does not patch it.

Parameter Store is hierarchical ops configuration: types String, StringList, and SecureString (AWS Key Management Service encryption). Standard parameters: 4 KB value limit, 10,000 per Region per account, no extra parameter charge, no parameter policies. Advanced parameters: 8 KB, 100,000 per Region, parameter policies (expiration, expiration notification, no-change notification), and a charge. You can promote standard to advanced; you cannot revert advanced to standard in place (would truncate 8 KB to 4 KB and drop policies). Store CloudWatch agent JSON, patch-window IDs, and feature flags here. AWS Secrets Manager remains the better fit when the stem requires automatic rotation of database credentials; Task 3.2 covers that split in more depth. Do not put long-lived production passwords in plaintext String parameters.

OpsCenter is the work-item console for OpsItems related to AWS resources. It aggregates context, related resources, and a Runbooks list to run Automation against the affected resource. AWS documents a 30-day record of Automation runbooks run for an OpsItem. CloudWatch alarms, EventBridge, Security Hub, and Config can create OpsItems. EventBridge rules created through OpsCenter can auto-associate runbooks for common events. Mean time to resolution drops when the alarm already points at AWS-RestartEC2Instance rather than at an empty ticket.

SAP-C02 scenario: patch windows

A brokerage must patch 800 Amazon EC2 instances and 40 on-premises VMs. Reboots are forbidden 13:00–21:00 local. Instances were previously updated with SSH and a shared key. The architect: (1) makes every node managed, (2) stores agent and baseline IDs in Parameter Store, (3) uses State Manager to keep the CloudWatch agent and Inventory association applied, (4) registers Patch Manager AWS-RunPatchBaseline (install + reboot) on a Maintenance Window 02:00–04:00 with concurrency and error-rate limits, (5) replaces bastions with Session Manager and log sessions to CloudWatch Logs, (6) opens OpsItems from patch-failure EventBridge events with an Automation runbook to isolate a failed node. That package is configuration-management automation for Task 3.1. Deep Config rule design and secret rotation stay in the later security chapter; here Config is only a trigger into OpsCenter or Automation.