We regularly find $5,000 to $10,000 per month in abandoned infrastructure during our first few weeks with a new client running our managed cloud security services.

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 over time. Dev teams spin up environments for projects. Those projects end or change direction, but 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; however, tracking what’s still needed? That’s the hard part. 

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 investigated with the engineer, we realized that 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 on 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 inadvertently go neglected. 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 with cron jobs, random utilities, and 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 talking to customers and telling them to change things on their end.

Nobody wants to deal with it; nobodyon the tech side and nobody on the business side. It then becomes a security problem to figure out. Figuring it out feels like an archaeological dig: tracing who’s responsible for what, determining if things are still used, and understanding what breaks if you touch it.

So it keeps running all the while costing

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 a product without it. But maintaining built 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, going unpatched and 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 create problems that 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, and 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, and 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, and logs are retained far longer than needed. Storage costs subsequently went up.

Ignored Security Tooling: That Macie trial you started 3 years ago but never stopped and never operationalized, or Security Hub that isn’t configured or reviewed, just costing more and more money. 

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 organizations, industries, and sizes.

The Security-Cleanup Connection

This connects directly to security work.

Every resource in your cloud environment is an attack surface. Abandoned infrastructure is an attack surface nobody’s watching. That EC2 instance from 2022 probably hasn’t been patched since the day it was launched. That data 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 have a reason. Anything else is a risk without a 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 the purpose. Tags help if they’re consistently applied, they usually aren’t.

Business context: What is this thing? Who uses it and what hat 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, and request logs. Zero utilization for weeks is a strong signal.

Dependency mapping: What breaks if we shut this down? Understanding connections before making any changes.

Cleanup execution: Properly decommissioning resources, and taking Backups if needed. Documentation of what was removed and why.

This isn’t glamorous work, but it is. It’s methodical, detail-oriented, and essential.

Beyond Direct Savings

The ROI isn’t just monthly spend reduction. Here are some other things that will pay off:

Reduced attack surface: Fewer running services mean 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. That’s real money, every month, that you can point to in a budget meeting.

Security improvements are harder to quantify. Cost savings aren’t.