We regularly find $5,000 to $10,000 per month in abandoned infrastructure during our first few weeks with a new client.
That's also a finance finding. And it's one of the most concrete returns you'll see from cloud security hygiene.
The Discovery Problem
Cloud infrastructure accumulates. Dev teams spin up environments for projects. Those projects end or change direction. The infrastructure stays.
The pattern is predictable:
- Engineers focus on building new things
- Legacy environments aren't anyone's explicit responsibility
- Nobody has visibility into what's actually running vs. what's needed
- Monthly AWS bills grow, and everyone assumes the growth is justified
Meanwhile, you're paying for EC2 instances nobody uses. Databases with no connections. Storage buckets holding forgotten data. Load balancers routing traffic to services that were deprecated years ago.
This is the natural result of cloud economics meeting normal organizational dynamics. Spinning things up is easy. Tracking what's still needed is hard.
When Security Alerts Surface Cost Savings
Sometimes the discovery comes from an unexpected direction.
We had a security alert fire in an old AWS account, something that brought it to the security team's attention. As we dug in with the engineer, we realized the account wasn't actually being used anymore. The whole thing could be shut down.
But it was still running. Large EC2 instances, costing serious money every month. Nobody had thought to look at it because nobody was actively working in it.
Tracing the vulnerabilities, getting the business context, and shutting down that account was a win on both fronts. Security risk eliminated, significant cost savings recovered. Security investigation surfaces things that nobody else is looking at.
The Kitchen Sink Server
One pattern we see repeatedly is what we call the "kitchen sink" server.
A technical founder or early CTO built it in the company's early days. It started as one thing, maybe the SSH gateway or the build server. Over time, it accumulated more and more. Websites, cron jobs, random utilities, things that were supposed to be temporary. Now it's the box that does everything.
It was never set up with Terraform or proper infrastructure as code. Nobody documented what it does. It's embedded in client workflows and whitelists, so extracting it means going to talk to customers and telling them to change things on their end.
Nobody wants to deal with it. Not on the tech side, not on the business side. It becomes a security problem to go figure out. Figuring it out feels like an archaeological dig: tracing who's responsible for what, determining if things are still used, understanding what breaks if you touch it.
So it keeps running. Costing money. Accumulating risk.
Build Infrastructure Nobody Owns
Another archetype: the abandoned CI/CD system.
Engineers set up Jenkins or whatever build system as part of getting things running. You can't ship product without it. But maintaining build infrastructure isn't their job. There's no dedicated DevOps person responsible for it. It's deep in the environment, and once it's working, nobody wants to mess with it.
Then it sits there for years. Unpatched. Unmaintained. Critical to everything but owned by nobody.
We had a client discover their Jenkins box was actually reverting to insecure AWS configurations every month during scheduled updates. The security fixes they kept trying to enforce would mysteriously disappear. The broader engineering team had no idea this was happening because nobody was looking at the build infrastructure. It just ran.
That's what accumulation looks like. Layers of forgotten infrastructure creating problems nobody can see.
The Ownership Void
The common thread in all of these is unclear ownership.
That kitchen sink server? It's had multiple tech owners over the years, including periods with no tech owner at all. People leave, roles change, knowledge walks out the door. Nine years later, you're staring at a system that nobody fully understands.
And it's not just tech ownership that's missing. Who's the business owner? What revenue does this thing generate? What happens to the business if it gets destroyed or hacked?
Nobody knows. Nobody wants to find out. The cost is organizational debt that compounds over time, not just the infrastructure bill.
Real Numbers
What does $5-10K per month actually look like in practice?
Forgotten dev environments: Three or four development environments that were "temporary" but never got torn down. Each runs multiple instances, a database, and supporting services. Easily $2-3K per month.
Oversized production resources: Services running on larger instances than they need because someone picked a size during initial setup and never revisited it. Rightsizing can cut 30-40% off specific workloads.
Redundant storage: Data stored in multiple places "just in case." Backups of backups. Logs retained far longer than needed. Storage costs add up.
Unused reserved capacity: Reserved instances or savings plans purchased for workloads that have since changed. Commitments that no longer match actual usage.
Zombie accounts: Entire AWS accounts running infrastructure for projects that ended. Nobody thought to look because nobody was actively working there.
These numbers aren't theoretical. We find them repeatedly across different organizations, different industries, different sizes.
The Security-Cleanup Connection
This connects directly to security work.
Every resource in your cloud environment is attack surface. Abandoned infrastructure is attack surface nobody's watching. That EC2 instance from 2022 probably hasn't been patched since 2022. That database backup sitting in S3 contains sensitive data nobody remembers exists.
From a security perspective, you want the smallest viable footprint. Everything running should be running for a reason. Everything stored should be stored for a reason. Anything else is risk without benefit.
The cost savings are almost a side effect of good security hygiene. When you actually look at what's in your environment--really look, with fresh eyes--you find things that shouldn't be there. Shutting them down reduces both cost and risk.
The Process
Identifying waste requires actually understanding what's running and why. That's harder than it sounds.
Inventory: What resources exist? Cloud provider tools give you lists, but lists don't tell you purpose. Tags help if they're consistently applied--they usually aren't.
Business context: What is this thing? Who uses it? What does it support? This requires conversations with people, not just looking at dashboards.
Utilization analysis: Is this thing actually being used? CPU metrics, connection counts, request logs. Zero utilization for weeks is a strong signal.
Dependency mapping: What breaks if we shut this down? Understanding connections before making changes.
Cleanup execution: Actually decommissioning resources, properly. Backups if needed. Documentation of what was removed and why.
This isn't glamorous work. It's methodical, detail-oriented, and essential.
Beyond Direct Savings
The ROI isn't just monthly spend reduction.
Reduced attack surface: Fewer things running means fewer things to patch, monitor, and defend. Security posture improves when you eliminate the forgotten corners of your infrastructure.
Simplified compliance: Less infrastructure means less scope for compliance audits. Fewer systems handling sensitive data means fewer systems requiring strict controls.
Better visibility: When you actually know what's in your environment, monitoring becomes meaningful. Alert fatigue decreases because you're not seeing noise from irrelevant resources.
Engineering focus: Your team can focus on what matters instead of maintaining things nobody needs.
The Takeaway
Cloud security hygiene means understanding what you have, questioning whether you need it, and eliminating what you don't.
The infrastructure cleanup that follows is often the most immediate, tangible return on cloud security investment. Real money, every month, that you can point to in a budget meeting.
Security improvements are harder to quantify. Cost savings aren't.
Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.