Cloud platforms make it trivial to spin up resources, and equally trivial to forget you ever did. EC2 instances from a project that ended two years ago, S3 buckets created during a hackathon, Lambda functions deployed by a developer who has since left, Azure resource groups that nobody is sure about. Over time, every cloud account accumulates this layer of forgotten infrastructure, and each piece carries quiet risk that nobody is actively managing.
Why Forgotten Resources Are Dangerous
An asset that nobody owns receives no patches, no monitoring, no security review, and no cleanup when something changes around it. The original developer documented none of it, the team that uses it has long since moved on, and the service principal it runs as still has the elevated permissions it was granted in 2020. When attackers find such resources, they find soft targets with valid credentials and trust relationships that the rest of the environment still respects. AWS penetration testing that performs proper asset discovery surfaces the resources that the inventory has stopped tracking.
How They Accumulate
Cloud resources accumulate through ordinary work. A proof of concept never gets cleaned up. A team gets reorganised and ownership of their resources falls through the cracks. An acquisition brings in another organisation’s cloud accounts that take years to fully integrate. A vendor handles infrastructure on your behalf and the contract ends without a clean handover. Each pattern produces orphaned resources, and the longer they sit unmanaged, the harder they become to clean up safely.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: When I run a cloud assessment for a new client, the resources nobody can fully account for typically outnumber the ones they can. Not because the team is incompetent, but because cloud platforms make creation easy and decommissioning hard. The findings always include at least a few orphaned items with valid credentials and elevated rights.
Tagging Discipline Helps but Is Not Enough
Strong tagging policies are the obvious answer: every resource carries owner, project, environment, and review-by tags. In practice, tagging compliance drops over time, exceptions accumulate, and resources created through automation often inherit incomplete tag sets. Enforcement through admission controllers, infrastructure-as-code patterns, and periodic compliance scans helps but rarely produces perfect coverage. Treat tagging as one input to discovery rather than the only mechanism.
Cost as a Discovery Signal
Finance teams often spot orphaned resources before security teams do. A persistent line item nobody can explain, a sudden spike in a region where the business does not operate, or a billing tag that does not match any active project all serve as useful signals. Closer cooperation between finance and security around cost anomalies turns the billing system into a discovery tool. The two teams rarely talk regularly, but they should.
Cleanup Has to Be Safe
Killing a forgotten resource sometimes turns out to be a bad idea. The function nobody remembers may still get called occasionally by another system. The bucket nobody owns may contain data that someone else relies on. Deletion has to follow a discovery and validation process: identify the resource, attempt to find an owner, observe its access patterns, and only then decide what to do. Azure penetration testing on the Azure side, paired with parallel work on AWS, helps surface the dependencies before any deletion happens.
Building It Into the Calendar
Set a quarterly cadence for cloud cleanup activities. Run discovery, compare to the active inventory, identify candidates for review, and work through them systematically. Treat the exercise as part of normal operations rather than a special project. Over a few cycles, the accumulated debt comes down, the inventory becomes more reliable, and the attack surface contracts to something the team can actually defend.
