Deleting a VM in Azure doesn't automatically delete everything associated with it. Disks, NICs, public IPs -- they all get left behind, still billing. Most engineers know this. But there's a more insidious version that catches even seasoned teams: Azure Site Recovery replicas.
We see this in almost every assessment on estates using ASR. An engineer decommissions a VM -- workload moved, rebuilt, project ended. Source VM gone. Job done. Except over in the DR target region, a full set of replica managed disks is still spinning, still billing, and nobody knows they exist.
How ASR Creates Hidden Cost
When you protect a VM with ASR, it creates replica managed disks in your target recovery region -- same size, same tier as the source. A Standard_D4s_v5 with a 128GB OS disk and two 1TB data disks? Three replica managed disks in your DR region.
Those disks are real resources, billed identically to any other managed disk of that size and tier.
If those source disks were Premium SSDs -- and in production they often are -- you're paying premium rates for replicas serving no purpose. A P30 (1TB Premium SSD) costs roughly £100/month. Three replica disks from a single decommissioned VM: £200-300/month.
Scale that up. Ten VMs decommissioned over the past year without ASR cleanup? £2,000-3,000/month in pure waste. We've seen larger estates where the figure is considerably higher.
Why This Keeps Happening
ASR doesn't automatically clean up replicas when you delete the source VM. The replica resources remain in the target region. ASR may flag the replication as unhealthy, but it won't remove the disks.
This creates a perfect storm. Replication is broken, so nobody monitors it. Source VM is gone, so nobody thinks about it. Replica disks sit in a DR resource group that engineers rarely open. Costs accumulate quietly, buried among hundreds of line items.
It gets worse without a formal decommissioning process. Engineers do what makes sense -- delete the VM, clean up obvious resources in the same resource group, move on. The DR target region doesn't cross their mind.
Where the Waste Hides
ASR typically creates resources in a resource group following the pattern yourResourceGroup-asr. Look for managed disks, NICs, and availability sets with asr prefixes.
Your Recovery Services vault tells the story too. Replicated items in an error state or showing critical health for VMs that no longer exist? The replica resources are almost certainly still billing.
The naming conventions are consistent -- -ASRReplica, asr- prefixes, -asr resource groups -- which makes them findable if you know to look. Don't forget the orphaned NICs, public IPs, and cache storage accounts that ASR creates alongside the replica disks.
Prevention: Update Your Runbooks
The most effective fix is adding "disable ASR replication" as a mandatory step in your VM decommissioning checklist. If you use runbooks or change management processes, ASR cleanup needs to be in there.
The correct order matters: disable replication in the vault first, wait for cleanup to complete, verify replica resources are actually removed, then delete the source VM. Reversing this order is exactly how orphans get created.
If replication is already broken -- source VM long gone, replication showing errors -- you'll need to clean up the replica disks, NICs, and vault entries manually.
A quarterly audit of your DR resource groups takes fifteen minutes and can save thousands. Cross-reference replicated items against your current VM estate. Any mismatch is worth investigating.
A Common Pattern, An Easy Fix
This isn't a niche edge case. We find orphaned ASR replicas in the majority of our assessments for organisations running DR in Azure. The costs are real, the fix is straightforward, and prevention is a single line item in a checklist.
The broader lesson: Azure doesn't clean up after itself. Any resource that creates dependents in another region or resource group is a potential source of hidden cost. ASR is one of the worst offenders because replica resources are designed to be invisible during normal operations. Out of sight, out of mind, and very much still on your bill.
Wondering what else is hiding in your Azure bill? Request a FinOps assessment -- we analyse your environment and identify exactly where you're overspending, ASR replicas included.