A factory fleet's disks are filling, and a CloudWatch alarm already sees the disk metric cross the threshold. Operators have been SSHing to each instance to delete files. How should the alarm drive the cleanup?
Select an answer to reveal the explanation.
Short Explanation
You already have a smoke detector, so you do not need someone to run between rooms with a bucket. The alarm state change can match an EventBridge rule whose target is a Systems Manager Automation runbook. A reboot does not delete the files, and a bastion full of SSH keys is how this keeps getting done badly.
Full Explanation
CloudWatch emits an alarm state-change event to EventBridge, and an EventBridge rule can target a Systems Manager Automation runbook. That is the reviewed, repeatable place to delete the known junk files or expand the step the fleet already trusts, on the instances the alarm identifies, without pasting SSH keys into a ticket. A bastion loop is the manual path the team is trying to retire, and it fails when the instance has no inbound SSH path. Rebooting an instance does not free a disk that is full of files. The process comes back to the same filesystem. A CloudTrail trail records API calls. It does not receive the disk metric and it does not start a cleanup. Caveat: the rule's role needs permission to start the automation, and the runbook should be safe to run twice because a flapping alarm can deliver more than one event. Operational check: set the test alarm to ALARM, confirm one automation execution starts, and confirm free disk space recovers on the targeted instance only.