Automating Detection of Unused AWS Resources

Every AWS estate has unused AWS resources, and almost every team that runs one knows it. The suspicion is usually specific: the volumes left behind when instances were terminated, the Elastic IPs that have billed since 2024 for addresses nothing uses, the snapshots nobody has looked at, the staging database on Multi-AZ, the load balancer in front of a service retired last spring. The figure most teams put on it, 20 to 30 percent of the bill, is about right. What never happens is the audit, because auditing forty accounts across a dozen regions and twenty services by hand takes a week, finds last quarter's waste after it has billed for three months, and has to be repeated every month to stay true.

This page is about replacing the audit with an inventory: what the common categories of waste are and what each costs, why finding them is a continuous problem rather than a periodic one, and how Opslyft's Atlas finds idle and orphaned resources across every account with an owner and a cost attached, and routes the cleanup as tickets. The general pattern is in our guide to where cloud waste hides; the address charge that turned forgotten IPs into a line item is in our guide to Elastic IP charges.

What Is Idle, and What It Costs

US East list prices, October 2026.

Why the Audit Never Happens

• It is spread across every account, region, and service. Unattached volumes are in the EC2 console per region, addresses in VPC, snapshots in EBS, idle databases in RDS, load balancers in ELB, across forty accounts. The native tools, Trusted Advisor and Compute Optimizer, each see part of it and report per account.
• Findings have no owner. A list of 300 unattached volumes is a list nobody can safely delete, because any one of them might be a backup someone needs, and the audit does not say whose it is.
• It expires immediately. New orphans appear every week as instances are terminated and tests finish. A quarterly audit is wrong by the time it is read.
• It competes with feature work. The engineer who could do the audit is also the engineer shipping the roadmap, and the audit loses.

The consequence is that waste is removed once, in a cleanup sprint, and grows back, which is why the figure stays at 20 to 30 percent year after year.

How Opslyft Solves It

Step 1: One inventory, every account, every region

Atlas keeps a live inventory of every resource across every connected AWS account and region, and every other cloud, with an owner and a cost on each. The volume, the address, the snapshot, the database, and the load balancer are rows in one list with the same columns, which is the thing the console cannot give you and the audit was trying to build by hand.

Step 2: Every finding has an owner and a price

Ownership comes from tags where they exist and is inferred from account structure, naming, and resource relationships where they do not, using the same rules Dimension Studio uses for allocation: an unattached volume last mounted by a payments instance is the payments team's volume. Every finding carries its monthly cost, so a list of 300 volumes is a list of 300 owned items sorted by what they are worth.

Step 3: Idle and orphaned resources are flagged continuously

Atlas flags unattached volumes, unassociated addresses, snapshots with no surviving source, load balancers with no healthy targets, NAT Gateways with negligible traffic, RDS instances with no recent connections or low utilization, EC2 at single-digit usage, and clusters with no workloads, as they become idle rather than at the next audit. Its recommendations weigh purpose and criticality and draw on memory, storage, and query-time metrics, so the low-utilization database that is a production primary and the one that is a forgotten staging copy get different advice.

Step 4: Cleanup is a ticket, not a spreadsheet

Tickets turns each finding, or a batch of them per team, into an assigned item in Jira, ServiceNow, or Asana with the evidence and the expected saving, posted to the team's Slack channel, and tracks it to closure with the realized saving recorded. The owning engineer sees their own orphans in their own backlog and deletes or justifies them in minutes; Opslyft does not delete anything itself.

Step 5: The change history explains how it got there

Each resource's change history shows when the instance was terminated and the volume stayed, when the address was last associated, when the snapshot policy lost its expiry, so the fix is not only the deletion but the template or policy that created the orphan, which is what stops it growing back.

Step 6: Waste is a number leadership can see

Explorer shows idle and orphaned cost by account and team over time, Canvas puts it on one screen with realized cleanup savings by month, Monitor flags a jump in orphaned cost with its cause, and Iris answers which teams have the most unused resources and what they are worth in plain English.

A Worked Example

A company with 38 AWS accounts and a $610,000 monthly bill suspects waste but has not audited since a cleanup sprint two years ago. Connecting the accounts read-only, Atlas inventories 41,000 resources in the first day and flags: 1,420 unattached EBS volumes totaling 96 TB ($8,100 a month); 310 unassociated or idle public IPv4 addresses ($1,130); 61 TB of snapshots whose source volumes no longer exist ($3,050); 27 load balancers with no healthy targets ($740 with addresses); 14 NAT Gateways in VPCs with no running instances ($510); nine RDS instances with no connections in 30 days and eleven non-production instances on Multi-AZ ($6,400); 3.1 TB of orphaned RDS snapshots ($295); and 118 non-production EC2 instances running around the clock ($14,000 against $3,300 if scheduled).

Each finding has an owner. 290 tickets go out across 22 teams, batched by category. Within three weeks the volumes, addresses, snapshots, load balancers, and gateways are gone or justified, the idle databases are deleted, the staging databases are Single-AZ, and the non-production instances are on schedules. Realized savings, measured on the next month's allocated actuals: about $31,000 a month, 5 percent of the bill, from resources that were doing nothing, with the rightsizing and commitment work still to come. Detection stays on, and the next orphaned volume is a ticket the week it appears.

Proof: Purplle, more than $200,000 in one month. Purplle, India's largest online beauty and wellness store, connected its cloud projects to Opslyft and, within minutes, saw the idle and underutilized resources no audit had found: unattached disks, low-CPU VMs, and unused compute clusters, each with its cost impact. More than $200,000 was saved in a single month with zero engineering bandwidth spent finding the waste. Read the full story: Purplle saves $200K in one month

Use Opslyft If

• You suspect 20 to 30 percent waste and the audit keeps not happening.
• You run more than a handful of AWS accounts or regions and nobody has one list of what is running.
• Findings from Trusted Advisor and Compute Optimizer sit unactioned because they have no owner.
• Cleanup sprints find the waste once and it grows back.
• You want cleanup routed to engineers as tickets, with the saving measured, not a spreadsheet.
• The same problem exists on Azure, GCP, or Kubernetes and you want one inventory across them.

If you run a few accounts that one engineer reviews monthly, Trusted Advisor and a checklist will serve. The platform earns its place when the estate is larger than anyone can audit.

The Bottom Line

Unused AWS resources are not hard to find; they are hard to find continuously, across every account, with an owner attached and a price on each, which is the only form in which they get deleted. Opslyft's Atlas is that form: a live inventory of everything running, with the idle and orphaned flagged as they appear, priced, assigned, and routed as tickets the owning team closes. The first pass typically returns 5 to 10 percent of the bill from resources doing nothing; detection that stays on keeps it from growing back. That is what Opslyft's cost control is built for; for the inventory itself across every cloud, see our walkthrough of cloud asset inventory.