Blog ENG - MS Azure - Post 7 2025
There’s a familiar feeling when you’re shepherding a change window at 02:00: coffee cooling on the desk, dashboards glowing, and a stubborn security exception waiting to be closed. For years, “just peer the VNets” has been the easy button, but it often grants more reachability than the architecture actually needs. Azure Subnet Peering finally gives us the fine scalpel: connect only the subnets that should talk, and keep everything else in the dark. It’s a small control with big consequences.
What Subnet Peering is (and isn’t)
Classic VNet peering wires up all address spaces and subnets between two VNets (convenient, but blunt).
Subnet peering turns that into a targeted connection: you explicitly list the participating subnets on each side and everything else remains isolated. Operationally, you configure it with the same tooling you already use (CLI, PowerShell, ARM/REST, or Terraform) and, at least for now, it sits behind a subscription allowlist. For dual‑stack shops, there’s a welcome twist: peering can be IPv6‑only for selected subnets, which is perfect if you want to validate IPv6 behavior without reopening IPv4 paths.
Why architects should care
1) IPv4 conservation without contortions
Large estates (and post‑merger environments) frequently reuse overlapping ranges. Subnet peering lets you connect only the unique, non‑overlapping subnets that must communicate (no readdressing marathons required).
2) Security that matches intent
Exposing an entire VNet through hub gateways or to on‑prem is rarely necessary. Subnet peering limits that exposure to the precise subnets that need it, reducing lateral movement and shrinking blast radius.
3) Dual‑stack flexibility
Run IPv6‑only peering for chosen subnets to test and observe v6‑prefer scenarios while keeping v4 segmentation intact. It’s clean, reversible, and great for staged adoption.
How it works (the nuts and bolts)
Peering remains unidirectional, so you create it in both directions for bidirectional connectivity. The shift to subnet scoping is simple:
– Set “peer-complete-vnet” to “false” to enable subnet peering.
– List participating subnets on each side via “local-subnet-names” and “remote-subnet-names”.
– For dual‑stack subnets, enable IPv6‑only peering with “enable-only-ipv6 true”.
Design patterns that work
– Selective hub exposure: Separate “front‑end” and “back‑end” into different spoke subnets. Peer only the back‑end to the hub (gateways, shared services), so front‑end workloads never gain implicit reachability to on‑prem or other spokes.
– Overlap‑aware peering (post‑M&A): When two VNets have overlapping /16s, peer just the distinct /24s hosting shared services. The rule is strict: participating subnets must be unique and belong to unique address spaces across the VNets.
– IPv6‑only islands: Peer specific dual‑stack subnets over IPv6 only to validate app behavior, firewall rules, and observability pipelines (useful for teams pushing IPv6 adoption without touching IPv4 at first).
Guardrails, gotchas, and scale limits
– One peering link per VNet pair. You can’t stack multiple exclusive links. To add or remove subnets, update the existing link. Switching link type (VNet ↔︎ subnet peering) requires deleting and recreating the peering.
– Scale constraints. Up to 200 participating subnets per side on a single link (local 200 + remote 200). The total number of subnets peered across all links for a given VNet should be ≤ 1,000.
– Forward‑route quirk (early behavior). Non‑peered subnets may still see forward routes to peered subnets. Packets won’t be delivered, but you should enforce intent with NSGs (“allow only what’s intended”). This behavior is slated to be removed post‑GA.
– AVNM interactions. Azure Virtual Network Manager may not distinguish subnet peering from full VNet peering; it can assume “a peering already exists” and skip creating another. Be deliberate when combining AVNM connectivity with subnet peering.
– Virtual WAN. Not supported with subnet peering at the time of writing.
– Compute SKU advisory. For production, use Intel V5 (or AMD Genoa / Cobalt 100 generation) VM SKUs to avoid a known issue on older generations.
Security & operations tips
– Express intent with NSGs. Treat NSGs on participating subnets as your final “contract.” Even with scoped peering, make the allow/deny list explicit.
– Service‑chain deliberately. If you require inspection, continue to steer through NVAs in the hub using UDRs; peering keeps traffic on the private backbone with low latency and high bandwidth.
– Observe and test. Use effective routes and connectivity checks to verify that peering and NSGs align with your intent; then capture baselines for drift detection.
A quick, practical checklist
1. Enable access: request subscription allowlisting for the feature.
2. Define scope: write down the exact subnets that must communicate (and those that must not).
3. Create reciprocal peerings with “peer-complete-vnet=false” and explicit “local/remote-subnet-names”.
4. For dual‑stack scenarios, consider “enable-only-ipv6=true” on selected links.
5. Lock it down with NSGs; validate effective routes and run connectivity checks.
6. Document limits (200 per side, ≤ 1,000 total per VNet) and plan governance around peering updates.
Final thoughts
Subnet peering is one of those small, surgical controls that quietly change how we design. It doesn’t replace solid segmentation, good identity, or thoughtful egress strategies, but it does let the network reflect intent with far less compromise. In my experience, that’s where resilience and simplicity come from.
If you’re adopting it in a mature estate, treat subnet peering as an architectural contract: name it clearly, codify it, and test it like you would a firewall rule. Don’t use it to avoid much‑needed readdressing forever; use it to buy time and reduce risk while you sequence proper IP hygiene work.
I also see it as a catalyst for dual‑stack pragmatism. IPv6‑only peering on select paths lets you build confidence where it matters, measure real user impact, and tune observability without reopening every IPv4 door in the house.
A few closing takeaways from the trenches:
– Design for intent, then enforce it. Subnet scoping narrows the blast radius; NSGs make that intent explicit. Keep both.
– Automate everything. Express peering as code, add unit tests for allowed subnets, and gate changes through CI/CD.
– Start small, prove value. One spoke, one service chain, one inspection path, then scale.
– Document ownership. Every peering should have a clear owner and a simple change path.
– Plan for tomorrow. Use subnet peering to conserve IPv4 today, but keep a realistic renumbering and IPv6 roadmap.
Most of all, remember that the best network is the one that’s boringly predictable at 02:00. Subnet peering helps you get there: less noise, fewer exceptions, and connectivity that behaves exactly the way you intended when you drew it.