Actions

Each entry records the action (e.g. Block, Unblock, Stop instance, Revoke ingress), the target (service + resource or IAM principal), the source (a rule, a manual run, or a rollback), the status (Success, Failed, Skipped or Reverted), and when it ran. The list is newest-first and paginated.

Every action records the inverse needed to undo it. When an action is reversible and not already reverted, a Rollback button is shown. Rolling back replays the inverse — release a contained principal, start a stopped instance, or re-authorize a revoked ingress rule from the rule captured at revoke time — and marks the original row Reverted. A new row is written for the inverse action, linked back to the one it undid.

The Active Containments filter narrows the same log to principals currently contained (a containment that has not been rolled back). It replaces the old separate blocked/allowed view — containment state is now derived from the action history itself, so there is a single source of truth.

Containing an IAM user or role attaches a customer-managed deny policy that blocks the principal. For principals in a member account, this runs cross-account through a scoped ContainmentAutomationRole; for principals in the application account, the deny policies are created there too. Rolling back detaches the policy.

Beyond containment, automation can remediate resources — stop / start / terminate an EC2 instance, or revoke / re-authorize a security-group ingress rule. These appear in the same log; the reversible ones (stop↔start, revoke↔authorize) carry a Rollback button, so a remediation applied in error can be undone in one click.

Rows triggered by a rule carry the execution id, so you can jump from an action back to the Automation → Executions record and its investigation report to see exactly which detection produced it.