Nobody plans to waste money on AWS. It happens anyway, one forgotten resource at a time.
Someone spins up an instance to test a migration and never terminates it. A volume outlives the instance it was attached to. An Elastic IP sits unassociated after a redesign. A load balancer keeps running in front of a service that was decommissioned months ago. None of these decisions felt wasteful at the time. Together, they can add up to a meaningful slice of your monthly bill.
This guide covers the most common types of unused AWS resources, how to find them manually, and why teams that rely on one-off cleanups usually end up back where they started.
The usual suspects
When teams audit their AWS accounts for waste, the same categories show up again and again:
- Unattached EBS volumes. Deleting an EC2 instance does not always delete its volumes. Detached volumes keep billing every month.
- Old EBS snapshots. Snapshots accumulate quietly, especially when they are created by automation that nobody reviews.
- Unassociated Elastic IPs. AWS charges for Elastic IPs that are allocated but not attached to a running instance.
- Idle load balancers. A load balancer with no healthy targets still costs money every hour.
- Stopped instances with attached storage. The compute is paused, but the EBS volumes underneath keep billing.
- Forgotten test and staging resources. Instances, databases, and buckets created for an experiment that ended long ago.
- Orphaned NAT gateways. A NAT gateway in a subnet that no longer routes real traffic is one of the more expensive things to forget.
Individually, most of these are small. The problem is that they accumulate, and nothing in AWS actively tells you they exist.
Finding them manually
You can find all of the above with the AWS console or CLI, and it is worth knowing how.
In the EC2 console, filter volumes by the "available" state to see everything that is not attached to an instance. The Elastic IPs page shows which addresses have no associated instance. Trusted Advisor flags idle load balancers and underutilized instances on some support plans. Cost Explorer helps you spot services that are spending more than you expect, which is often the first clue that something forgotten is still running.
With the CLI, a command like "aws ec2 describe-volumes" with a status filter of "available" lists unattached volumes in a region. Similar queries exist for addresses, snapshots, and load balancers.
This works. But notice what it requires: you need to know each resource type to check, run the check in every region you use, repeat it for every account, and remember to do all of this on a regular schedule.
Why one-off cleanups do not stick
Most teams have done a cloud cleanup day at least once. It feels great. The bill drops, the inventory looks tidy, and everyone agrees to keep it that way.
Then normal work resumes. New resources get created under deadline pressure. Someone leaves the team and their experiments stay behind. Six months later the accounts look exactly like they did before the cleanup, because the cleanup was an event, not a process.
The underlying issue is visibility. If finding waste requires a manual audit, waste will grow at exactly the pace of the time between audits.
Turning cleanup into a continuous check
This is the problem Cloustral is built around. Instead of auditing your AWS accounts by hand, you connect them once and let a continuous inventory do the remembering.
Cloustral syncs your AWS resources across regions into one searchable inventory, so "what do we actually have running" stops being a research project. From there, rules turn your cleanup checklist into automated checks. A rule can flag volumes whose state is "available", Elastic IPs with no association, instances that have been stopped for too long, or resources missing the tags your team uses to track ownership.
When a rule matches, Cloustral creates a finding with a severity, a message, and a recommendation. Findings live on the Insights page, where you can filter by connection, severity, or resource type, and resolve each one as it is handled. If a flagged resource is intentional, you resolve the finding and move on. If it is genuine waste, you have a clear list of what to delete.
Tags are the difference between waste and work
The hardest part of any cleanup is not finding candidates. It is answering the question "can we delete this?" An unattached volume might be leftover junk, or it might hold data someone needs next quarter.
This is why tagging discipline pays for itself. If every resource carries an owner tag and an environment tag, an unused resource has an obvious person to ask. If it carries nothing, you are stuck doing archaeology.
Cloustral rules can enforce this too. A rule that flags resources missing an owner tag will not lower your bill this month, but it makes every future cleanup dramatically faster.
Keep the loop running
The final step is making sure the checks keep happening without anyone having to remember them. Cloustral syncs every connection daily on paid plans, evaluates rules after each sync or on their own schedule, and can email your team a daily digest of new findings.
That changes the shape of the problem. Instead of waste accumulating silently until the next big audit, a forgotten volume or an idle load balancer surfaces as a finding within a day of appearing. Cleanup stops being an event and becomes a small, steady part of how the team works.
Start with what already exists
If you suspect your AWS accounts have accumulated waste, the first step is simply seeing everything in one place. Connect an account to Cloustral, let the initial sync run, and browse the inventory. Most teams find something they forgot within the first ten minutes.
You can also explore with synthetic demo data first if you are not ready to connect a real account. Either way, the goal is the same: know what exists, know what changed, and stop paying for things nobody is using.