Skip to content

Azure Virtual Network Footguns

Partial list

The source research for this page was cut off mid-item at #14 ("Delegated subnets have constraints..."). Items 1-13 below are complete and verified; the rest — plus the AWS-equivalent crosswalk table and quick-facts trivia page for this topic — are pending.

1. AWS public/private subnet assumptions do not translate cleanly

Azure subnets are not classified by an Internet Gateway route. Explicitly design ingress and egress.

2. Five addresses are reserved per IPv4 subnet

Tiny subnets run out faster than AWS-trained engineers expect.

3. Peering is non-transitive

Hub-to-spoke A and hub-to-spoke B does not automatically create spoke-A-to-spoke-B connectivity.

A single link remains "Initiated" rather than "Connected."

5. Overlapping CIDRs block peering and complicate mergers

Allocate centrally and reserve growth space.

6. NSG VirtualNetwork service tag is broader than one subnet

It can include peered or connected address spaces depending on effective topology. A default AllowVNet rule may permit more east-west traffic than expected.

7. NSGs at NIC and subnet are cumulative

Traffic must be allowed by both applicable NSGs; troubleshooting one object is insufficient.

8. NSGs are stateful

Tightening a rule may not terminate already-established sessions immediately.

9. UDRs are associated per subnet

Creating a route table alone changes nothing — it must be associated with the subnet.

10. Asymmetric routing through an NVA breaks stateful devices

Make return paths explicit and enable IP forwarding on appliance NICs.

11. Private endpoint creation does not disable public access

Public exposure remains unless the PaaS resource's network policy is changed separately.

Linking a private DNS zone to a VNet without records/forwarding for all required resources can blackhole access.

13. Service endpoints can change source identity

Enabling them may change the source address seen by the PaaS firewall and break existing IP rules.