An idle resource is running and doing no work; an orphaned resource was left behind when the thing it belonged to was deleted. Both appear on the invoice like any other line, except that nobody needs them. They are the simplest savings opportunity there is, because the change touches no architecture, and the one most often left alone, because no metric turns red and no team pays for it.

How it works

The distinction matters because the cause differs. Idle means the resource exists, bills hours or capacity, and receives no requests, no connections, no load. Orphaned means the object that used it no longer exists, and the resource survived the deletion because the provider keeps it as an object of its own. The same classes recur at all three providers:

  • stopped instances whose disks and static addresses keep billing;
  • unattached volumes and old snapshots that outlived their volume;
  • public IPv4 addresses with no resource behind them, which all three providers now charge for: AWS at the same rate for an in-use and an idle address, Azure for a static address irrespective of the associated resource, Google Cloud at a higher rate for a reserved address that is not assigned than for one in use;
  • load balancers with no backend and NAT gateways with no traffic, billed by the hour;
  • empty or unused databases and caches counting instance hours without connections;
  • development and test environments running at night and at weekends;
  • old container images, log retention without a limit and backups without an expiry.

In billing data they show by the shape of the line: cost without usage of the primary metric, hours without requests, gigabytes without reads, capacity without connections. The invoice alone does not say whether the resource is needed; it says only that it is doing nothing.

The providers surface these resources in their own tools, each with documented criteria. AWS Trusted Advisor checks, among others, Classic Load Balancers with fewer than 100 requests a day over seven days, EBS volumes that are unattached or had less than 1 IOPS a day over seven days, unassociated Elastic IP addresses, RDS instances with no connection in seven days, EC2 instances stopped for more than 30 days and NAT gateways that processed zero bytes in 30 days. AWS Compute Optimizer adds idle findings: an EC2 instance with peak CPU below 5 % and under 5 MB of network a day over 14 days, a volume unattached over a 32-day lookback, a NAT gateway with no active connection, databases without connections, plus DynamoDB tables, caches and endpoints. Azure Advisor lists among its cost recommendations disks not attached to a VM, empty App Service plans, Cosmos DB containers with no activity in 30 days, Data Explorer clusters stopped for 60 days and virtual network gateways with no connections. Google Cloud's Recommender offers the idle VM recommender with a default observation window of 14 days, whose CPU and network thresholds the documentation does not quantify, the idle persistent disk recommender, which proposes a snapshot and deletion for a disk detached for 15 days, and recommenders for unused IP addresses, unused images and unused Cloud SQL instances.

What none of these tools answers is whether the resource is needed. Only the person who created it or carries its cost knows that. That is why allocation precedes clean-up: a resource with no owner has nobody to approve the deletion and nobody to miss the snapshot. What prevents the recurrence is a set of lifecycle rules: an expiry date as a tag on everything temporary, schedules for environments needed only in working hours, and retention policies for snapshots, images and logs.

What it means for your cost

The saving is the full amount of the line from the moment the resource is gone, and it is realised only once the line is missing from the next invoice. Until then it is an estimate, which the tools derive from the list price or, at AWS with the savings estimation mode switched on, from the account's discounts. For a resource under a commitment the saving is smaller than the line: the reservation keeps running, and only the part it did not cover disappears.

In a cost report an idle resource appears as a line with cost and no usage of the metric that defines the service. That shape is the search: instance hours without CPU, load balancer hours without requests, storage without reads. Where the resource is stopped, a remainder stays: disks, snapshots, static addresses and reserved capacity keep billing, and that remainder is what to look for after switching something off. A reservation that runs empty after a deletion shows up as falling commitment utilisation in the report beside it and is the second thing to check after every clean-up; where a resource stays but is too large, rightsizing takes over.

Where it goes wrong

  • Deleting without an owner: the resource looked idle because the tool does not measure its kind of use; whoever needed it finds out at the outage.
  • The snapshot was the only backup: an old snapshot is not worthless because its volume is gone. Retention is the owner's decision, not a consequence of age.
  • An address released while a DNS record still points at it: the provider hands it to someone else, and the record then points at a stranger. The address goes only after the record does.
  • The dev environment nobody switched off because nobody paid for it: as long as it disappears into shared cost, no team has a reason. Allocation is what turns the line into a decision.
  • The saving is booked, the resource is still there: a ticket is not a deletion. The following month's invoice is the only proof.

Sources

Read on 2026-10-15. AWS Trusted Advisor cost optimization checks, Compute Optimizer idle resource recommendations, Amazon VPC pricing for public IPv4 addresses; Microsoft Azure Advisor cost recommendations, IP address pricing; Google Cloud idle VM recommendations overview, idle resources recommendations, list of recommenders, network pricing.