Project sprawl is a GCP-specific problem with real cost implications
It starts innocently. Someone needs a sandbox. Someone else needs a separate environment for a new service. A contractor spins up a project for a proof of concept. A team creates a project for each major feature because that seemed like clean separation at the time
Two years later there are 30 projects. Eight of them have no clear owner. Five of them haven't had active resources for six months but still have a few things running that nobody is confident removing
The cost of the abandoned resources is real. The cost of the confusion is also real, just harder to measure
Managing 30 projects requires 30 sets of billing alerts, 30 sets of IAM reviews, 30 sets of security posture checks. Teams with good hygiene do this. Most teams don't, which means the 30 projects are effectively unmonitored
Project sprawl also creates a discovery problem. When something is wrong, which project is it in? When you need to understand your architecture, how do you get a coherent picture across 30 projects with inconsistent naming and labeling?
The consolidation work is genuinely hard. GCP doesn't make it easy to merge projects or move most resources between them. But there are approaches
Identify projects with no active resources by billing data: zero spend for 90 days is a reasonable threshold for a deletion candidate. Notify the listed owner. Wait 30 days. If no objection, delete
For projects with active resources that should be consolidated: document the migration required to move workloads to the target project. Treat it as a migration project with a deadline
For future projects: establish a project creation process. Require an owner, a purpose, and a planned retirement date. Review quarterly
The sprawl didn't happen in a day. It won't be fixed in a day
But each project you consolidate or delete reduces the surface area of the problem for every future optimization effort
Top comments (0)