Cloud Sprawl: Why Resources Outlive Their Purpose
Provisioning takes one call. Retiring takes an owner, a decision, and confidence nothing depends on it.
Cloud sprawl is the uncontrolled growth of cloud resources, accounts, and services beyond what anyone actively manages. It is not the same as growth. A platform can grow quickly and stay tidy; sprawl is specifically the part of the estate with no clear owner, no current purpose, or no record of why it exists. Its costs are financial, since everything provisioned bills, and operational, since every unmanaged resource is also an unpatched, unmonitored attack surface.
Where sprawl comes from
- Asymmetric effort. Creating a resource is fast and has an immediate benefit to the person doing it. Removing one has no benefit to that person and some risk.
- People move on. The engineer who launched a test cluster changes teams, and the cluster keeps its name but loses its owner.
- Side effects. Resources create other resources: instances leave volumes behind when terminated, since AWS preserves data volumes attached after launch by default; backups create snapshots; load balancers and public IPs outlive the services they fronted.
- Account and region spread. Each new account, project, subscription, or region is another place resources can hide from whoever is looking in the usual ones.
- Console changes. Resources created by hand sit outside infrastructure-as-code, so no pull request or state file records them.
Measuring it
Sprawl is measured by the gap between what exists and what is accounted for. Useful indicators:
| Indicator | What it reveals |
|---|---|
| Resources with no owner tag, by cost | Allocation gap |
| Resources whose creator has left | Ownership gap |
| Resources not declared in any IaC state | Change-control gap |
| Detached disks, unassociated IPs, old snapshots | Leftovers from deletions |
| Regions or accounts with spend but no known workload | Visibility gap |
Rank by cost. A thousand small snapshots can matter less than one forgotten GPU instance.
Reversing it
- Inventory everything, across every account, project, subscription, and region, before deciding anything. See cloud inventory.
- Assign owners, from tags where they exist and from activity history where they do not.
- Sort into keep, schedule, resize, and retire, and send each owner their list.
- Retire with a safety net: notice periods, backups where state matters, and approval for deletes.
- Prevent recurrence with tagging enforced at creation, expiry dates on temporary environments, and new infrastructure going through code review.
How ZopNight helps with sprawl
ZopNight discovers resources across connected AWS accounts, GCP projects, and Azure subscriptions, with periodic re-sync to pick up new and deleted resources. Its resource ownership detection derives the creator and last modifier of each resource from CloudTrail, Cloud Logging, and Azure Activity Log, and marks whether that person still appears in the cloud identity directory, which makes the “owner has left” indicator concrete. IaC governance scans link resources declared in Terraform or OpenTofu state to discovered inventory, separating managed from unmanaged resources. Orphan recommendations cover leftovers such as unattached volumes and old snapshots.
Related: resource lifecycle, resource ownership detection, and the idle resource problem.