Lab 02 · Afternoon session · Runs with Module 04

Taking Action with Systems Manager

Module 4 argued that detection is worthless without the ability to act. This lab is the acting half. You group resources by what they are for rather than by what they are called, read operational data for the group as a unit, then run an operation that lands on every member at once — without logging into a single host.

AWS Systems Manager Resource Groups Automated operations Hands-on lab

What you’re actually proving

The lab looks small. Make a group, look at a dashboard, run something. The idea underneath it is the one that decides whether your operations practice survives contact with a real estate: at scale you stop operating on individual resources and start operating on sets defined by intent.

Read this alongside the official lab guide, not instead of it. The guide in your lab environment carries the authoritative click-by-click steps, the exact resource names, and the region you are working in. This page deliberately does not repeat them — it explains what each task is demonstrating, what to look at while you are in there, and how it connects back to Module 4. If the two ever disagree, the lab guide wins.

A resource group is a query, not a list

This is the single sentence worth carrying out of the lab. When you define a group you are not enumerating resources. You are writing a predicate — “every EC2 instance tagged env=prod and app=payments” — and the group is whatever satisfies that predicate at the moment somebody asks.

The consequence is the whole point. Tomorrow morning an Auto Scaling group adds four instances. They carry the tags because the launch template sets them. They are in the group instantly. Nobody edited the group. Nobody opened a ticket to add them. Next week three instances are terminated; they leave the group just as quietly. A list would have gone stale within a day. A query cannot go stale, because it is re-evaluated every time it is used.

That property is what makes grouping worth doing before acting rather than after. If your targeting mechanism drifts out of date, every automation built on top of it inherits the drift — and the failure mode is silent. Nothing errors. The action simply misses resources, and you find out during an audit.

Why the old way stops working

Everyone has done operations the manual way, and for a handful of servers it is genuinely fine. It is worth being precise about where the wheels come off, because the breaking point is lower than most people expect.

Connect to each host and do the thing
  • Effort scales linearly with fleet size. Twelve instances is an afternoon; two hundred is a project.
  • Requires inbound access, a bastion or jump path, and key material in someone’s hands — all of which is attack surface you now own.
  • No record of what ran where. The audit trail is a shell history on a host that may be gone next week.
  • Partial completion is invisible. If you got bored at instance 47, nothing tells you.
  • Drift compounds, because the humans doing it make slightly different choices each pass.
Describe the target, run the operation once
  • Effort is flat. The same command targets four resources or four hundred.
  • No inbound access needed — the managed agent on the instance reaches out, so you can keep hosts in private subnets with no SSH path at all.
  • Every invocation is recorded per target, with status and output, so “did this land everywhere?” is a question with an answer.
  • Failures are enumerated rather than lost. You get a list of which targets did not succeed.
  • Repeatable. The same document run next month does the same thing, because it is a definition, not a memory.
The breaking point is not a hundred instances — it is two teams. Manual operations fail long before the fleet gets big, because the moment more than one person is doing it the results diverge. Grouping and automation are less about scale than about making the operation the same every time, no matter who triggers it.

Where this sits in the module

Module 4 describes four activities that make up operating with control: monitor, audit, act, operate. Lab 2 is a concentrated dose of the third one, and it touches the fourth.

Group

Organise resources into logical sets using tags, so that the unit of operational work matches the unit of business meaning — an application, an environment, a patch cohort.

See

Read aggregated operational data with the group as the lens. The interesting question is rarely “how is this instance?” It is “how is the payments application?”

Act

Run an operation against the whole group in one invocation, with per-target results. This is the capability that lets a detection in Config or GuardDuty turn into a repair rather than a ticket.

Keep one thing in view while you work. Systems Manager is the service Module 4 named as the remediation arm of the governance loop. Config detects, EventBridge alerts, Systems Manager fixes. Everything you build in this lab is the fixing machinery — you are just triggering it by hand instead of by finding.