That EC2 instance you spun up for a quick test six months ago.
Still running.
Nobody remembers why it exists. But it is still there; quietly costing money every day.
Most teams treat this as a cost problem. Find idle resources; shut them down; save money.
But here is what gets missed.
That forgotten instance has an IAM role with permissions never reviewed since. An old AMI with unpatched vulnerabilities. A security group with rules nobody remembers adding.
Cost reports catch unused resources because someone is watching the bill.
Nobody is watching the security posture of something they forgot exists.
This is how breaches happen. Not through production systems everyone watches. Through the test environment that became permanent by accident.
What you forget does not disappear. It just stops being watched.
Top comments (1)
Good post — the IAM credential angle is underappreciated. Most people see the billing alert and stop there, but the metadata endpoint is the real blast radius multiplier.
One thing worth adding to your IMDSv2 enforcement advice: IMDSv2 is a great control, but it only helps if you're also watching for unexpected metadata calls. GuardDuty has a finding type (InstanceCredentialExfiltration.OutsideAWS) specifically for when temporary credentials from an EC2 role get used outside AWS — that's often the first signal you get that the metadata endpoint was abused.
The tagging + owner discipline point at the end is probably the highest-leverage thing here. The technical controls are all well-documented, but the actual root cause of most forgotten instances is cultural: no convention for "this is temporary, terminate it by date X." Even a single tag —
TerminationDateorOwner— fed into a weekly Config query changes the behavior more than any automation alone, because it forces the person spinning up the instance to think about lifecycle at creation time rather than cleanup time.Good framing overall. Most "cloud cost" posts stop at the dollar line. Leading with the security posture is the right angle.