Tired of surprise cloud bills? Learn to identify and eliminate costly, orphaned resources like unattached EBS volumes and old snapshots with these battle-tested strategies from a senior cloud architect.

That’s Not a Glitch, That’s a Bill: Taming Your Cloud Spend

I still remember the Monday morning meeting from a few years back. The Director of Finance, who rarely spoke to engineering directly, was on our team call. He wasn’t happy. Our AWS bill for the dev account had spiked by nearly 30% over the weekend. Panic set in. Was it a breach? A runaway process? Nope. It was a junior engineer, a really sharp kid, who had been running performance tests on a new database cluster. He’d spun up a dozen massive, provisioned IOPS EBS volumes, attached them to his test instances, and then terminated the instances on Friday afternoon. The problem? He assumed the storage would go away with them. It didn’t. We were paying a premium for over 10TB of high-performance storage that was literally doing nothing. That’s when I learned a critical lesson: the cloud doesn’t clean up after you unless you tell it to, very specifically.

The “Why”: Digital Ghosts in the Machine

So, how does this even happen? It’s a side effect of how cloud providers try to protect you from yourself. When you create an EC2 instance, you can specify whether to delete its attached storage volumes on termination. For the root volume, this is usually the default. But for any additional volumes you attach, AWS and Azure often default to keeping them. The logic is, “This data might be important, so we won’t risk deleting it.”

This well-intentioned safety net becomes a cost trap. Automation scripts, Terraform states that get out of sync, or simple human error can lead to dozens of these “unattached” or “orphaned” volumes. They’re invisible until you look for them, silently racking up charges on your monthly bill. They are the digital ghosts of servers past.

The Fixes: From Band-Aid to Body Armor

Alright, so you suspect you’ve got some of these costly specters floating around. How do you exorcise them? We’ve got a few approaches at TechResolve, from the quick-and-dirty to the fully automated.

Solution 1: The Quick Fix (The Manual Sweep)

You need to stop the bleeding, now. This is the fastest way to find and eliminate the immediate problem. We’re going straight to the command line because it’s faster than clicking through a UI.

For AWS, open your terminal and make sure you have the AWS CLI configured. Run this command:

aws ec2 describe-volumes --filters Name=status,Values=available --query "Volumes[].VolumeId"

This command asks AWS for all EBS volumes in the ‘available’ state—meaning they aren’t attached to any running instance. It will spit out a list of Volume IDs. Review this list carefully. For each volume you’re sure is junk (like vol-01a2b3c4d5e6f7g8h from that long-forgotten PoC), you can then delete it:

aws ec2 delete-volume --volume-id vol-01a2b3c4d5e6f7g8h

Warning: This is permanent. There is no “undelete” button. If you delete prod-db-01-data-vol by mistake because it was temporarily detached for maintenance, you’re going to have a very, very bad day. Double-check your targets.

Solution 2: The Permanent Fix (The Automated Janitor)

Doing a manual sweep is great, but you’re a DevOps engineer, not a manual laborer. You need to automate this so it never becomes a fire drill again. My preferred method is a simple serverless function that acts as a janitor.

Here’s the high-level game plan:

1. Create a Lambda function (Python with Boto3 is perfect for this).
2. Give it an IAM Role with permissions to describe and delete volumes (ec2:DescribeVolumes, ec2:DeleteVolume, ec2:CreateTags).
3. Set up an Amazon EventBridge (formerly CloudWatch Events) rule to trigger this function on a schedule, say, every night at 2 AM.

The logic inside the function is a two-step “tag and sweep” process to prevent accidents:

1. The function runs and finds all ‘available’ volumes.
2. For each volume it finds, it first checks for a tag called `mark-for-deletion`.
3. If the tag doesn’t exist, it adds it with today’s date as the value. mark-for-deletion = 2023-10-27. It then does nothing else to that volume.
4. If the tag does exist, it checks the date. If the date is more than 7 days in the past, then and only then does it delete the volume.

This creates a 7-day grace period. If a volume was detached by mistake, an engineer has a week to notice it’s been tagged and either re-attach it or remove the tag. It’s the perfect balance of automation and safety.

Solution 3: The ‘Nuclear’ Option (Enforced Hygiene)

Sometimes, especially in sprawling dev and sandbox accounts, the problem isn’t just a few orphaned resources; it’s a systemic lack of hygiene. In these cases, you need a bigger hammer. This is where you enforce a strict “tag-or-die” policy.

This approach involves policies and tools that automatically delete any resource that doesn’t comply with your tagging standards. For example:

• AWS Config Rules: You can set up a rule that identifies any EC2 instance, EBS volume, or RDS database that is missing a required tag (e.g., `Owner`, `Project`, or `CostCenter`). You can then link this to a Systems Manager Automation document to automatically terminate the non-compliant resource.
• Third-Party Tools: Tools like `cloud-custodian` or even the more aggressive `aws-nuke` can be configured to run on a schedule and wipe out anything that doesn’t fit the rules.

Pro Tip: The ‘Nuclear’ option is NOT for production. I repeat, NOT FOR PRODUCTION. This is a scorched-earth policy designed to force developers to be responsible in ephemeral environments. It keeps costs low and teaches good habits, but it is unforgiving. Deploy it with extreme caution and clear communication to your teams.

At the end of the day, managing cloud cost isn’t about finding one magic bullet. It’s about building layers of visibility, accountability, and automation. Start with the manual sweep to understand the scope of your problem, build the automated janitor to handle the day-to-day cleanup, and save the big guns for the environments that truly need a lesson in discipline.

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