Cloud sprawl is the growth of accounts, services and resources that nobody tracks. Control it by discovering everything, assigning an owner to each resource, setting expiry dates, and reviewing the list on a schedule. The cause is structural: cloud makes creating things easy and removing them optional.
Why does sprawl happen?
NIST's definition of cloud computing lists "on-demand self-service" and "rapid elasticity" among its five essential characteristics. Both are the point of the cloud, and both are how sprawl starts. A developer can create a database in minutes without a ticket. A forgotten test environment keeps running and keeps accumulating exposure.
The UK NCSC's cloud security principles add a second source. They say the principles help you choose a provider, and that you "will separately need to consider how you configure your cloud services securely". Configuration is yours. Every unmanaged resource is an unconfigured one.
What does it cost besides money?
Sprawl is a security problem first. Each forgotten resource is something that is not patched, not monitored and not in your inventory. Old storage may still be public. An old test API may still hold real credentials. When an incident happens, responders lose time working out what a resource is and who owns it.
CISA's Cloud Security Technical Reference Architecture describes a shared risk model and monitoring the environment through cloud security posture management. That only works if you know which accounts and resources exist.
How do you find everything?
Start from the top. List every cloud account, subscription and project, using billing records and the identity provider as cross checks, since a card payment often reveals an account nobody registered. Then list resources inside each. Compare against what your inventory says. The gap is your sprawl.
Look for shadow sources too: accounts created by acquired companies, personal accounts used for work, and software as a service tools connected by employees.
How do you keep it from coming back?
Four rules do most of the work.
Every resource has an owner, recorded in a tag or metadata the platform enforces at creation.
Temporary things expire. Test and demo resources get an end date at creation, and a reaper process deletes or alerts.
Guardrails exist before creation. Organization level policies can block regions, services or public exposure you never intend to use.
Review is routine. A monthly list of untagged, idle and public resources goes to a named person.
Who should own the problem?
Put one person in charge of the account structure and the guardrails, usually in platform or cloud engineering, and make each team responsible for its own resources inside it. Security sets the rules and watches for drift. Finance helps by flagging spending that nobody can attribute. Shared ownership with no named lead is how sprawl returned in the first place.
A constructed example
A growing company finds 31 cloud accounts when it thought it had 12. Eleven belong to former projects, five to an acquisition, three are personal accounts used for experiments. It assigns owners, closes the abandoned ones after a thirty day warning, folds the acquired accounts under organization policies, and adds a required owner tag. Within a quarter the untagged resource count drops to near zero, and the monthly review takes fifteen minutes.
How to check or apply this
- List all accounts using billing data and the identity provider.
- List resources per account and compare against your inventory.
- Add required owner and expiry tags, enforced at creation.
- Delete or archive resources nobody claims after a warning period.
- Apply organization wide guardrails for regions, services and public exposure.
- Run a monthly report of untagged, idle and public resources.
Safeguard's asset discovery helps build the inventory side, and its compliance automation can test cloud accounts against framework controls.
Quick check
Is cloud sprawl mainly a cost problem?
Cost is the visible symptom. The security risk is unmanaged, unpatched and unmonitored resources that nobody owns.
What is the first step?
List every cloud account and subscription, using billing and identity records to catch the ones nobody registered.
Sources
- NIST Cloud Computing project
- NCSC cloud security principles
- CISA Cloud Security Technical Reference Architecture
Last reviewed: 18 October 2026.
