Resynchronize Azure peering after changing a member's address space

Source facts

Microsoft’s cross-subscription peering guidance requires resynchronizing a connection after changing a member network’s address space. The synchronization reflects the changed prefixes in the peering relationship.

The same procedure considers peering established when both networks show Connected. It supports peering Resource Manager virtual networks across different subscriptions and Entra tenants. Microsoft Learn.

Applicability

Identify the network being changed and every peering relationship that depends on its address space. Record the old and proposed ranges, the owner of each peer and the application paths that must use the new range.

DSE recommendation

DSE recommends making synchronization a named task with an owner in the address-change plan. Coordinate the two network owners before the change window and retain the original prefix map for comparison. Do not close the change solely because the VNet’s address-space field displays the intended value. Keep unrelated routing or access-policy changes separate so failures can be attributed accurately.

Verification

After an approved change and synchronization, inspect both peering states and compare the resulting configuration with the planned prefix map. Exercise a representative permitted connection using the changed range, as well as a path that should remain restricted. Record the addresses actually tested and any unresolved discrepancy. Treat Connected as one configuration check, not a substitute for validating the intended application path.

Official references

Microsoft Learn: Create Virtual Network Peering Between Different Subscriptions. Source retrieved September 9, 2026.