Systems Manager Automation Runbooks

Every remediation runbook starts life as a single concrete action, restarting a service on a known instance set, reapplying a required tag to a resource list, something small enough to describe in one sentence. The hard part isn't the action itself. It's proving, after the fact, exactly what happened, to whom, and with what result. Systems Manager Automation exists to close that gap: it turns a manual action into a controlled execution where AWS records the inputs, assumes an execution role, runs a step sequence, and persists outputs and logs so what happened can be proven later.

Before running anything, the risk surface is worth treating as three levers that change the blast radius. Target scope determines how many resources can change, the execution role determines what changes are even possible, and rate controls determine how fast failures can repeat across a fleet. Cost is driven mostly by execution volume and the time spent triaging failures and validating outcomes.

The diagram below traces where evidence appears as the Automation flows from inputs to roles to steps to outputs.

The point of ...