VNet peerings stuck in the Disconnected state

Half a bridge is not a bridge

VNet peering is a paired object: each side holds a peering resource pointing at the other. When the remote VNet is deleted, or the far side of the pair was never created, the surviving half drops to the Disconnected state and stays there indefinitely, visible in every network diagram and doing nothing. The discoverer reads the peeringState property and flags only an explicit Disconnected verdict; Connected, Initiated, and unknown states all pass untouched.

Zero dollars, stated as zero dollars

Peering is data-priced: a per-GB charge on traffic crossing it, higher across regions. A Disconnected peering carries no traffic, so there is genuinely nothing to reclaim, and the finding hardcodes $0 rather than reading the pricing map at all. An earlier version emitted whatever number happened to collide onto the peering’s identifier; the current rule cannot, by construction. What you get is a cleanup task, honestly labeled.

Fix is as likely as delete

Unusually for an orphan finding, the remediation genuinely forks. If the peering should exist (the remote VNet was rebuilt, or the pair was half-configured during a migration), recreate the far side and the link comes back. If the remote VNet is gone for good, remove the surviving peering object so routing intent stays legible. A peering that was never fully established deserves fixing, not deleting.

List every disconnected peering you own

az network vnet list --query "[].id" -o tsv | while read -r vnet; do
  az network vnet peering list --ids "$vnet" \
    --query "[?peeringState=='Disconnected'].{vnet:'$vnet', peering:name}" -o table
done

Why cleanup matters at $0

Disconnected peerings mislead humans and tooling: address-space planning treats the peered range as claimed, dependency maps show links that cannot carry a packet, and incident responders waste minutes on a red herring. Network hygiene is the entire value here, which is why the finding survives ZopNight’s minimum-savings filter through the orphan exemption.

Reproduction requirements

Reader on the subscription is the only permission involved. Peering state is plain resource metadata, with no metrics and no write access. Deleting or recreating peerings remains a manual, change-controlled action.