# Azure VNet Peering Disconnected

> A VNet peering in the Disconnected state moves no traffic, and since peering is billed per GB transferred, its standing cost is $0. ZopNight surfaces these as fix-or-remove findings: the remote VNet was usually deleted, or only one side of the pair was ever created.

Source: https://zop.dev/integrations/azure/recommendations/azure-vnet-peering-disconnected
Updated: 2026-08-19

---

## 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

```bash
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.