cost agent's "unused" security group was the bastion's - lockout after cleanup
Recovers from a cleanup that deleted a bastion's security group by restoring access and excluding infrastructure security groups from deletion. Use when a cost agent's cleanup deletes a security group that was actually in use. Not for intentionally removed groups.
TL;DR
The agent classified the bastion host's security group as unused (no attached instances at scan time, or a stale-attachment check) and deleted it, locking out administrative access. Restore access first (via Systems Manager Session Manager, which does not need the bastion, or by recreating the group), then exclude infrastructure security groups from the agent's deletion scope permanently. Security groups with no attachments are not necessarily unused.
Error
cost agent's "unused" security group was the bastion's - lockout after cleanupSteps
- Restore administrative access: use Session Manager or the console to reach the affected instances, bypassing the deleted bastion path. Expected: you have a working admin channel.
- Recreate the bastion security group with its original rules, or restore it if a backup exists. Expected: the bastion's access rules are back.
- Verify bastion connectivity is restored. Expected: SSH through the bastion works again.
- Add exclusions to the agent: never delete security groups tagged as infrastructure, attached to bastions, or referenced by other groups. Expected: the deletion scope excludes them.
- Require human approval for any security-group deletion going forward. Expected: no automated group deletion without review.
When to use
- A cleanup deletes a security group that was in use.
- Administrative access is lost after a cleanup run.
- Scoping automated security-group deletion.
When not to use
- The group was intentionally decommissioned.
- The group was truly unused with no references.
- The lockout has another cause.
Tool compatibility
AWS EC2 security groups, Systems Manager (current 2026 releases).
Variant phrasings
bastion unreachable after the cleanup
The agent deleted its security group. Restore via Session Manager.
"unused" security group was referenced elsewhere
Check references (other groups, ENIs) before deleting.
automated sg deletion caused an outage
Require human approval for security-group deletes.
Why it happens
"Unused" is hard to determine for security groups: a group with no current attachments may still be referenced by other groups' rules, attached to stopped instances, or part of the access path (like a bastion). Agents that equate zero attachments with safe-to-delete miss these relationships. Security groups are access control, not just cost items; their deletion needs human judgment, which is why the durable fix is approval-gating, not better detection.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_obDJBuCDg4RRqr6QFNayuA