Home/Azure/Orphaned Resources
Cost Optimization · Orphaned Resources

Nobody provisions an orphan. They are what is left behind.

Orphaned resources are the disks, addresses, snapshots, and gateways that outlive the workloads they were attached to. A virtual machine is deleted but its managed disk persists and keeps billing. A load balancer is removed but its public IP stays reserved. None of it was provisioned on purpose, which is exactly why none of it shows up in a capacity review. On a mature Azure estate that has never run a sweep, orphaned resources routinely account for three to eight percent of monthly spend, and the recovery is pure margin because nothing in production depends on them.

Contact Us Azure pillar →
The categories

Where the spend hides.

Orphans cluster into a small number of resource types that bill independently of any compute. Each accumulates through a different lifecycle gap. Knowing the categories tells the detection sweep exactly what to look for.

Category 01
Storage

Unattached managed disks

When a virtual machine is deleted, its data disks are not always removed with it. Unattached managed disks bill at full provisioned capacity indefinitely. On large estates this is the single largest orphan category by spend, because premium disks are expensive and accumulate quietly across years of VM churn.

  • Signal. Disk state shows unattached with no owning VM.
  • Caution. Confirm the disk holds no data needed for forensics or recovery before deletion.
Category 02
Network

Reserved public IPs

Standard public IP addresses bill whether or not they are associated to a resource. A gateway or load balancer is torn down and its address sits reserved and billing, often for years, because removing the parent resource does not release the address.

  • Signal. Public IP with no associated resource.
  • Caution. Confirm the address is not whitelisted downstream before release.
The full inventory

Four more that compound.

Beyond disks and addresses, four further categories accumulate across the estate. Individually small, collectively material, and all invisible to a workload level review because none of them attach to a running service.

Category 03

Stale snapshots

Disk snapshots taken for a migration or a one off backup and never deleted. Each bills for its captured capacity. A governance gap on snapshot retention produces years of accumulation that no one is watching.

Category 04

Idle gateways and NICs

Network interfaces detached from any VM, and gateways left running after a connectivity project ended. Gateways in particular carry a meaningful hourly rate that continues long after the workload they served is gone.

Category 05

Empty app service plans

App service plans provisioned at a paid tier with no apps deployed, or with all apps long since removed. The plan continues to bill at its tier rate regardless of whether anything runs on it.

The sweep

Detect. Quarantine. Delete.

Orphan cleanup is dangerous done carelessly, because a resource that looks abandoned may be a deliberate cold standby. The safe sweep runs in three stages, and the quarantine stage is what separates a clean recovery from an outage.

Stage 01

Detect by resource graph

Query the resource graph for each orphan signature across every subscription. Unattached disks, dissociated IPs, ownerless NICs, empty plans. The query produces a candidate list with monthly cost attached, ranked by recoverable spend so the work targets the biggest wins first.

Stage 02

Quarantine before delete

Tag every candidate, move it to a holding resource group, and wait one full billing cycle. If nothing breaks and no owner claims it, it is safe to remove. The quarantine window is the insurance against deleting a deliberate standby that simply looked idle.

Stage 03

Delete with a record

Remove the confirmed orphans and log the recovered spend. The record matters for two reasons: it proves the saving to finance, and it documents what was removed in case a recovery question arises later.

The governance

Stop them coming back.

A one time sweep recovers the standing orphan inventory. Without governance the inventory rebuilds within a year. Two controls keep the estate clean between sweeps so the recovery holds.

Control 01

Cascade delete policy

Configure deletion so that removing a virtual machine also removes its attached disks and interfaces by default, rather than leaving them behind. Most orphan disks are created the moment a VM is deleted without its dependents. Closing that default closes the largest source.

Control 02

Scheduled monthly scan

Automate the detection query to run monthly and report new orphans to the cost owner. A standing report converts orphan management from an annual cleanup project into a routine that catches each orphan within a cycle of its creation, before it accumulates a year of charges.

The orphaned resource sweep kit.

The six category signatures, the resource graph detection queries, the three stage quarantine workflow, and the two governance controls that keep the estate clean between sweeps. Sent on request.

$420M+ recovered · 340+ engagements
Engage the practice

Recover the spend nothing depends on.

Orphaned resources are the cleanest recovery in the Azure portfolio because production never touches them. The risk is in the deletion, not the saving. We run the detection sweep across every subscription, manage the quarantine window so nothing live is removed, and install the governance that keeps the estate clean after we leave.

Contact Us 79% audit exposure cut · 20+ years practice depth