Cloud cost waste isn’t just a technical problem; it’s a human one driven by a lack of ownership and fear. Learn why your AWS bill is a nightmare and how to fix it with three battle-tested strategies from the trenches.

So, You’re Bleeding Money in the Cloud? Here’s Why Nobody’s Fixing It.

I still remember the Monday morning email from Finance. The subject was just “AWS Bill – Urgent” and the body was a screenshot of a cost explorer graph that looked like a rocket launch. A single, untagged `p4d.24xlarge` EC2 instance—one of those absolute monster GPU machines—had been running for 18 days straight in a dev account. Someone had spun it up for a quick ML model test, got distracted by a production fire, and completely forgot about it. The cost? More than my first car. That day, I stopped thinking about cloud cost as a “Finance problem” and started treating it like the critical bug it is.

The Root of the Rot: It’s Not About the Tech

I was browsing a Reddit thread the other day asking this exact question: “Why is cloud waste so hard to reduce?” The answers were painfully familiar. We all know the tools exist—Cost Explorer, Trusted Advisor, third-party platforms. The problem isn’t the tooling; it’s the culture. It boils down to a few core human issues:

• Diffused Responsibility: When a developer can spin up a resource with a few clicks, who owns the cost? The developer? Their manager? The DevOps team that built the pipeline? When everyone is responsible, no one is. It’s the “tragedy of the commons,” but with virtual machines.
• The Fear Factor: You find an un-tagged S3 bucket the size of a small moon, last modified in 2019. Or a mysterious `m5.4xlarge` instance named `legacy-etl-processor-dont-touch`. Is it critical? Is it junk? Nobody knows, and nobody wants to be the person who deletes it and brings down a silent-but-critical quarter-end report.
• Incentive Misalignment: Developers are rewarded for shipping features, not for saving 50 bucks on an EC2 instance. The pressure is always “go faster,” and cleaning up is an afterthought. The bill lands on a different department’s desk, completely disconnected from the teams racking up the charges.

The tech is just the enabler. The real problem is we haven’t built the guardrails and ownership models to manage it.

Solution 1: The Quick Fix (aka “The Screaming Test”)

Okay, you need to stop the bleeding now. You don’t have time to get buy-in for a six-month FinOps cultural transformation. This is the hacky, “in the trenches” solution that works.

The idea is simple: you write a script that finds resources that violate a very basic policy (e.g., no “owner” tag, or running for more than 24 hours in a dev account). But instead of terminating them, you just stop them (for EC2) or apply a deny policy (for S3). Then you wait.

If someone screams, you’ve found the owner. You can have a conversation, help them tag it properly, and restart the resource. If nobody says a word for a week? You can probably terminate it safely. It’s a blunt instrument, but it forces the ownership conversation to happen.

Here’s a simple AWS CLI example to find untagged, running EC2 instances you could target:

aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" --query "Reservations[*].Instances[?Tags==null].InstanceId" --output text

Pro Tip: Before you run this, communicate! Send an email to the engineering org saying, “Heads up, we’re starting a cleanup process. Any untagged dev instances will be automatically stopped starting Friday. Please ensure your resources have an ‘owner’ tag with your email.” This turns it from a surprise attack into a shared responsibility.

Solution 2: The Permanent Fix (Policy as Code and Forced Ownership)

The screaming test is a band-aid. The real fix is building a system where waste can’t be created in the first place. This means getting serious about governance.

Mandatory Tagging is non-negotiable. You need to define a clear, simple tagging policy and then enforce it programmatically. Don’t just ask people to do it; make it impossible for them not to.

Our Minimum Tagging Policy at TechResolve

How do you enforce this? In AWS, you use Service Control Policies (SCPs) at the Organization level. You can write a policy that literally denies the `ec2:RunInstances` action if the required tags aren’t present in the request. The developer’s Terraform apply or console click will simply fail until they tag their resources correctly.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2CreationWithoutOwnerTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "aws:RequestTag/owner": "true"
        }
      }
    }
  ]
}

This moves the responsibility to the point of creation. It’s no longer DevOps’ job to clean up the mess; it’s the creator’s job to be a good cloud citizen from the start.

Solution 3: The ‘Nuclear’ Option (The Automated Janitor)

Sometimes, even with policies, things slip through. Or maybe you have years of existing, untagged mess to clean up. This is where you unleash the janitor—a scheduled Lambda function or script that actively seeks and destroys non-compliant resources.

This is a step beyond the “Screaming Test.” The janitor doesn’t stop resources; it terminates them.

Here’s the logic for a common “Dev Environment Janitor”:

1. Runs every night at 7 PM.
2. Scans all resources in accounts tagged with `environment=dev`.
3. Looks for any EC2 instance, RDS database, or ECS cluster that does NOT have a special `persistence: true` tag.
4. If found, it terminates the resource.

The philosophy here is that dev environments should be ephemeral. If you need something to stick around, you must explicitly justify it by adding the persistence tag. This simple automation has saved us tens of thousands a month by eliminating forgotten test servers that run 24/7.

Warning: This is a powerful and dangerous tool. You start this in one non-critical dev account. You run it in dry-run mode for weeks. You over-communicate what it’s going to do. If you unleash this on a production account without thinking, you’re going to have a very, very bad day. But when used correctly, it fundamentally changes behavior and enforces a culture of cost-consciousness like nothing else.

At the end of the day, taming cloud costs is an ongoing battle. It’s not a project you finish; it’s a practice you build. Start small, show value with a quick win, and use that momentum to build the lasting cultural changes that truly make a difference.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions