Cloud / Azure Virtual Network (VNet) Interview questions

Azure Virtual Network is the basic building block of a private network in Azure. It is a logically isolated, software-defined network where resources such as VMs, AKS nodes and private endpoints talk to each other, to the internet and to on-premises networks.

A VNet belongs to one region and one subscription, is defined by one or more CIDR address spaces, and is carved into subnets. The VNet itself costs nothing; you pay for the things attached to it, such as public IPs, gateways, firewalls and peering data transfer.

• Isolation: traffic is private unless you connect it to something else.
• Connectivity: internet, other VNets (peering), on-premises (VPN or ExpressRoute).
• Control: filtering with NSGs and firewalls, custom routing with route tables.

A VNet is made of an address space, subnets and the objects that sit inside or around them. Azure resources get a private IP from a subnet through a network interface (NIC).

Optional services such as NAT Gateway, Azure Firewall, Bastion and private endpoints are attached to subnets.

The address space is the set of private IPv4 (and optionally IPv6) ranges, written in CIDR notation, that a VNet owns. Every subnet must be carved out of it, so it defines the maximum number of addresses available to the VNet.

You can add more address ranges later. Choose ranges that do not overlap with other VNets you will peer with or with on-premises networks, because overlapping ranges cannot be peered or routed cleanly.

az network vnet create -g rg-demo -n vnet-demo \
  --address-prefixes 10.10.0.0/16 10.20.0.0/16

A subnet is a range of IP addresses inside the VNet's address space. You place resources in a subnet, and the subnet becomes the unit for applying NSGs, route tables, NAT gateways, service endpoints and delegations.

Subnets let you separate tiers such as web, app and database. By default all subnets in a VNet can reach each other through the system route, so isolation comes from NSG rules rather than from the subnet itself.

A subnet cannot span regions or VNets, but it does span all availability zones in the region.

Azure reserves five addresses in each subnet: the first four and the last one. These cannot be assigned to resources.

So a /24 gives 251 usable addresses, and the smallest IPv4 subnet, a /29, gives only 3. Remember this when sizing subnets for scale sets or services that consume many IPs.

This matters for sizing. A /27 gives only 27 usable addresses, and services such as Application Gateway, AKS with Azure CNI or scale sets can consume addresses quickly. Count the five reserved addresses before picking a prefix, because a subnet that already holds resources is hard to shrink.

Any valid IPv4 range works, but you should use the private RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Using public ranges you do not own risks routing conflicts with real internet addresses.

Azure blocks some ranges from being added to a VNet:

• 224.0.0.0/4 (multicast)
• 255.255.255.255/32 (broadcast)
• 127.0.0.0/8 (loopback)
• 169.254.0.0/16 (link-local)
• 168.63.129.16/32 (Azure DNS, DHCP and health probe address)

The 100.64.0.0/10 shared range can also be added to a VNet address space, but it is not RFC 1918, so use it only when private space runs out. Whatever you choose, keep ranges unique across Azure and on-premises so peering and VPN routing never conflict. Public ranges you do not own are risky because traffic meant for those real internet addresses would be routed into your VNet.

A VNet is a regional resource. It is created in one region and one subscription, and its address space and subnets cannot span regions.

Inside that region, subnets cover all availability zones automatically, so you do not create a subnet per zone. To connect VNets in different regions you use global VNet peering, a VPN gateway connection or Virtual WAN.

This also means you cannot move a VNet to another region; you recreate it there.

This drives design. A multi-region application needs one VNet per region, linked by global peering or a hub, and each VNet needs its own non-overlapping address space. Zone resilience comes from the zone setting on each resource, not from creating a subnet per zone.

VNet peering connects two VNets so resources in them communicate using private IPs, as if they were on the same network. Traffic stays on the Microsoft backbone and never crosses the public internet.

Peering offers low latency and high bandwidth because there is no gateway in the data path. It works across subscriptions and tenants, but the two address spaces must not overlap, and the link must be created from both sides (the portal does both when you have permission).

az network vnet peering create -g rg-a -n a-to-b \
  --vnet-name vnet-a --remote-vnet vnet-b \
  --allow-vnet-access

There are two types, based on where the VNets live:

Both can cross subscriptions and Microsoft Entra tenants. You are charged for inbound and outbound data on both sides of a peering, so chatty cross-region designs can get expensive.

Features such as gateway transit and forwarded traffic work with both types. A good rule: use regional peering inside a region for the cheapest transfer, and use global peering only when the workload truly needs private cross-region traffic, such as database replication or disaster recovery links.

An NSG is a stateful, rule-based packet filter that allows or denies network traffic to and from Azure resources in a VNet. You can attach it to a subnet, a NIC, or both.

Each rule has a priority (100-4096), source, source port, destination, destination port, protocol (TCP, UDP, ICMP or any) and an allow or deny action. Because NSGs are stateful, return traffic for an allowed flow is permitted automatically.

NSGs work at layers 3 and 4. They do not inspect URLs or payloads; for that use Azure Firewall or Application Gateway WAF.

Every NSG is created with six default rules you cannot delete, but you can override them with a lower-numbered (higher priority) rule.

The practical effect: inbound internet traffic is blocked until you add an allow rule, while outbound internet is allowed.

A private IP comes from the subnet range, is used for communication inside the VNet and over peering, VPN or ExpressRoute, and can be dynamic or static. A public IP is a separate Azure resource that makes a resource reachable from the internet.

Standard SKU public IPs are secure by default: inbound traffic is blocked until an NSG explicitly allows it. The Basic SKU has been retired.

A service endpoint extends your subnet's identity to supported Azure services such as Storage, SQL and Key Vault. Traffic from the subnet to the service travels over the Azure backbone, and the service's firewall can be set to accept only requests coming from that subnet.

The service still has its public endpoint and public IP; what changes is that the source of your traffic is now the subnet's private identity. Enabling it is free.

• Enabled per subnet, per service (for example Microsoft.Storage).
• Not reachable from on-premises through the endpoint.
• Protects the whole service type in a region, not one single resource.

A private endpoint is a network interface with a private IP from your subnet that maps to one specific Azure resource, for example a single storage account blob service or a SQL server. Private Link is the underlying platform that makes this mapping work.

Clients connect to the private IP, so traffic never leaves your network address space, and you can turn off the service's public access completely. It is reachable from peered VNets and from on-premises over VPN or ExpressRoute.

DNS matters here: the service name must resolve to the private IP, usually through a privatelink Private DNS zone such as privatelink.blob.core.windows.net.

Azure VPN Gateway sends encrypted traffic between a VNet and another network over the public internet using IPsec/IKE tunnels. It runs as a pair of managed VMs inside the GatewaySubnet.

Gateways are route-based or policy-based, and provisioning typically takes 30-45 minutes. Throughput depends on the chosen SKU, so size it for peak traffic.

Pick route-based gateways for nearly all new designs, because they support IKEv2, multiple tunnels, BGP and P2S. Policy-based is older and limited to a single tunnel. Enable active-active with BGP when you need failover, and size the SKU for peak throughput.

ExpressRoute is a private, dedicated connection between your on-premises network and Microsoft cloud, provided through a connectivity partner. Traffic does not cross the public internet, which gives more predictable latency, higher reliability and higher bandwidth than a VPN.

• Private peering: reaches VNets with private IPs.
• Microsoft peering: reaches Microsoft 365 and public Azure services over the private link.
• An ExpressRoute gateway in the GatewaySubnet connects the circuit to your VNet.

It costs more and takes longer to provision than a VPN, which is why many teams keep a VPN as backup.

Azure Bastion is a managed jump-host service that lets you RDP or SSH into VMs through the Azure portal over TLS on port 443, without giving the VMs public IPs or opening 3389 and 22 to the internet.

It is deployed into a dedicated subnet named AzureBastionSubnet (at least /26) and uses its own Standard public IP. The VMs only need a private IP that the Bastion subnet can reach, plus an NSG rule that allows RDP or SSH from the Bastion subnet.

A route table holds user-defined routes (UDRs) that override Azure's default system routes. Each route has an address prefix and a next hop type, and you associate the table with one or more subnets. A subnet can have only one route table.

az network route-table route create -g rg-demo \
  --route-table-name rt-spoke -n to-firewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.0.4

The GatewaySubnet is a dedicated subnet that hosts the VMs of a VPN or ExpressRoute gateway. It must be named exactly GatewaySubnet or Azure will not deploy the gateway into it.

• Use /27 or larger so you can support features like coexisting VPN and ExpressRoute gateways.
• Do not deploy other resources, such as VMs, into it.
• Avoid attaching an NSG; filtering can stop the gateway from working.
• A VNet can have only one GatewaySubnet.

A frequent deployment error is a gateway subnet with a custom name or one that is too small, which fails validation. If you start with a /29 and later want VPN and ExpressRoute gateways side by side, you may have to enlarge the subnet first.

An ASG lets you group NICs by application role, such as WebServers or DbServers, and use that group as the source or destination in an NSG rule instead of listing IP addresses.

When a VM is added or removed, you only change its ASG membership; the NSG rules stay untouched. All NICs in one ASG must be in the same VNet.

az network nsg rule create -g rg-demo --nsg-name nsg-app -n allow-web-to-db \
  --priority 200 --access Allow --protocol Tcp --destination-port-ranges 1433 \
  --source-asgs asg-web --destination-asgs asg-db

NAT Gateway is a managed service that provides outbound-only internet connectivity for a subnet. All VMs in the subnet share the NAT gateway's static public IP address or prefix, so external services see a predictable source IP.

• Attached to the subnet, not to individual VMs.
• Supports up to 16 public IPs, each providing 64,512 SNAT ports.
• Idle timeout defaults to 4 minutes and can be raised up to 120.
• Does not allow inbound connections initiated from the internet.

Compared with default outbound access, NAT Gateway gives a stable source IP you can allow-list at partners. For the subnet it is attached to, it takes precedence over load balancer outbound rules and instance-level public IPs. It can be deployed zonally, so match the zone to your workloads.

Create a resource group, then the VNet with its first subnet, then add further subnets. The address prefix of every subnet must fit inside the VNet's address space.

az group create -n rg-demo -l eastus

az network vnet create -g rg-demo -n vnet-demo \
  --address-prefixes 10.10.0.0/16 \
  --subnet-name snet-app --subnet-prefixes 10.10.1.0/24

az network vnet subnet create -g rg-demo \
  --vnet-name vnet-demo -n snet-db \
  --address-prefixes 10.10.2.0/24

Verify with az network vnet show -g rg-demo -n vnet-demo. In production, define the same thing in Bicep or Terraform so it is repeatable.

Accelerated networking uses SR-IOV to let a VM's network traffic bypass the host's virtual switch and go straight to the physical NIC. That cuts latency, jitter and CPU usage on the host.

You enable it on the VM's NIC, and it requires a supported VM size and guest OS. It is free to enable. It is most useful for high packet-rate workloads such as databases, NVAs and big-data clusters.

az network nic update -g rg-demo -n nic-vm1 \
  --accelerated-networking true

A NIC connects a VM to a subnet. It holds the VM's private IP, optional public IP, MAC address, DNS settings, NSG association and accelerated networking setting.

A VM can have several NICs, depending on its size, but all of them must be in the same VNet (they can be in different subnets). The NIC is a separate resource; it outlives the VM if you delete only the VM.

Secondary IP configurations let one NIC carry multiple private IPs, useful for hosting several services or certificates on one VM.

Both connect two VNets privately, but they differ in the data path, cost and limits. Peering is direct over the Microsoft backbone; a VNet-to-VNet VPN builds an encrypted IPsec tunnel through a VPN gateway in each VNet.

Choose peering by default. Choose the VPN when you explicitly need IPsec encryption between the VNets or want to use features such as VPN NAT for overlapping ranges.

Peering is a direct one-to-one relationship between two VNets, and Azure does not propagate peering routes through a VNet to its other peers. So if A is peered with B and B is peered with C, A still cannot reach C.

flowchart LR
  A["VNet A"] <--> B["VNet B"]
  B <--> C["VNet C"]
  A -. no path .- C

This keeps blast radius small and routing predictable, but you must decide how spokes talk to each other. Options:

1. Peer A and C directly (full mesh, grows fast).
2. Route through a hub: put Azure Firewall or an NVA in B and add UDRs with next hop Virtual appliance.
3. Use Azure Virtual Network Manager connected groups, or Virtual WAN, for managed transit.

A common pattern is a firewall in the hub with each spoke sending the other spokes' ranges to it. The peering links involved need Allow forwarded traffic enabled, otherwise packets the firewall forwards on behalf of another spoke are dropped at the peering.

Gateway transit lets spoke VNets use the VPN or ExpressRoute gateway that lives in a hub VNet, so you pay for and manage one gateway instead of one per spoke.

1. On the hub-side peering, enable Allow gateway transit.
2. On the spoke-side peering, enable Use remote gateways.
3. Make sure the spoke has no gateway of its own; it cannot use remote gateways if it does.
4. Update the on-premises side (BGP or local network gateway prefixes) so it learns the spoke ranges.

Spokes then learn on-premises routes automatically. Also enable Allow forwarded traffic on the peering if traffic arrives from a different network than the peer itself.

If the on-premises side does not learn the spoke prefixes, traffic works in one direction only. With BGP this is automatic; with static routes you must add the spoke ranges to the local network gateway. A spoke can use only one remote gateway at a time.

Both keep traffic to PaaS services on the Microsoft backbone, but they work differently. A service endpoint changes the source identity of your traffic; a private endpoint gives the service a private IP in your VNet.

Pick private endpoints for strict isolation and hybrid access; service endpoints are fine for simple, free subnet-level restriction.

A practical difference is provable isolation. With a private endpoint you can disable the storage account's public network access and show that no internet path exists. With a service endpoint the public endpoint stays up and you rely on the firewall rule. Service endpoints also add routes to the subnet, so check effective routes when forced tunneling is in use.

NSG rules are processed in priority order, from 100 (first) to 4096, then the default rules at 65000 and above. The first rule that matches the traffic decides the result and processing stops.

A rule matches on source, source port, destination, destination port and protocol. Because NSGs are stateful, you only write the rule for the initiating direction.

If both a subnet NSG and a NIC NSG exist, both must allow the traffic:

flowchart TD
  P["Packet arrives"] --> S{Subnet NSG allows?}
  S -- No --> X[Dropped]
  S -- Yes --> N{NIC NSG allows?}
  N -- No --> X
  N -- Yes --> V["Delivered to VM"]

An NSG is a free, distributed layer 3/4 filter attached to subnets or NICs. Azure Firewall is a managed, centralized, stateful firewall service that understands application-layer details like FQDNs.

They complement each other: NSGs segment inside each spoke, while a firewall in the hub controls internet egress and spoke-to-spoke traffic.

Use NSGs for cheap, fine-grained east-west segmentation, and add Azure Firewall where you need a single choke point with central logs. As a rule of thumb: NSG answers who may talk to whom inside a VNet, firewall answers what may leave to the internet.

Azure first applies longest prefix match: the most specific prefix wins, regardless of the source of the route. A /24 route beats a /16 route.

If prefixes are identical, the source decides, in this order:

1. User-defined route (UDR)
2. BGP route (from VPN or ExpressRoute)
3. System route

Example: with a system route 0.0.0.0/0 -> Internet and a UDR 0.0.0.0/0 -> Virtual appliance, the UDR wins for internet-bound traffic. But a system route for 10.1.0.0/16 (peering) would still win over that UDR for 10.1.x.x, since it is more specific, unless you add a more specific UDR.

Longest prefix match is applied first, so adding a more specific route is the usual way to carve out an exception. To send only 10.2.0.0/16 to a firewall, add a /16 UDR instead of replacing the broader peering route. The effective route table on a NIC confirms which route actually wins.

System routes are default routes Azure creates in every subnet so basic connectivity works without any configuration.

More system routes appear automatically when you add VNet peering (next hop VNet peering), a gateway (BGP routes) or a service endpoint (next hop VirtualNetworkServiceEndpoint). You can see them per NIC with the effective routes view.

You cannot delete system routes, only override them with a UDR of the same or a more specific prefix. If you add a private range to the VNet address space, the matching None route is replaced by a virtual network route. The effective route table on a NIC shows exactly which routes are active.

By default VMs use Azure-provided DNS at the virtual IP 168.63.129.16. It resolves public names and gives VMs in the same VNet name resolution through their internal hostnames.

It does not resolve names across VNets or for on-premises servers. For that you have three options:

• Azure Private DNS zones linked to one or more VNets, with optional VM auto-registration.
• Custom DNS servers set in the VNet (your own DNS VMs or a forwarder).
• Azure DNS Private Resolver for inbound and outbound hybrid forwarding.

After changing VNet DNS servers, VMs need a restart or lease renewal to pick up the new settings.

Azure-provided DNS also has limits: it does not support custom records or conditional forwarding, and each VM has a query rate limit. If you need custom zones or forwarding rules, use Private DNS zones or a Private Resolver. Each VNet has its own DNS setting, so keep it consistent across peered VNets.

On-premises DNS cannot query Azure's 168.63.129.16 address directly, so you need a resolver in Azure that on-premises DNS can forward to.

1. Create the private endpoint and a Private DNS zone such as privatelink.blob.core.windows.net, linked to the hub VNet.
2. Deploy Azure DNS Private Resolver with an inbound endpoint in the hub, or a DNS forwarder VM.
3. On-premises DNS sets a conditional forwarder for the service's public zone (for example blob.core.windows.net) to the inbound endpoint IP.
4. Reach the hub over VPN or ExpressRoute.

sequenceDiagram
  participant C as On-prem client
  participant D as On-prem DNS
  participant R as Private Resolver (inbound)
  participant Z as Private DNS zone
  C->>D: mystore.blob.core.windows.net?
  D->>R: Conditional forward
  R->>Z: Query linked zone
  Z-->>R: 10.1.4.5
  R-->>D: 10.1.4.5
  D-->>C: 10.1.4.5

Forward the public zone name, not the privatelink name, because the client queries the public name first and gets a CNAME into the privatelink zone.

Hub-and-spoke is a network design with a central hub VNet holding shared services, and several spoke VNets for individual workloads, each peered only to the hub.

flowchart TB
  OP[On-premises] --- GW
  subgraph Hub
    GW["VPN/ER gateway"]
    FW["Azure Firewall"]
    BA[Bastion]
  end
  Hub --- S1["Spoke: Prod"]
  Hub --- S2["Spoke: Dev"]
  Hub --- S3["Spoke: Data"]

• Centralized security: one firewall and one gateway for all spokes.
• Cost sharing: shared services are paid once.
• Isolation: spokes cannot reach each other unless the hub routes it.
• Scale: add a spoke by adding one peering.

The trade-off is that spoke-to-spoke traffic needs UDRs pointing to the hub firewall, and the hub is a critical shared component.

In the hub, link the Private DNS zones to the hub VNet and point spokes at the hub resolver, so names are managed in one place. For traffic control, attach a route table to each spoke subnet with the hub firewall as next hop, and keep NSGs on spoke subnets for local segmentation.

Each outbound connection from a private IP to the same destination IP and port consumes one SNAT port on the public IP it is translated to. If ports run out, new connections fail or time out intermittently.

Ways to avoid it:

• Use NAT Gateway with multiple public IPs: each gives 64,512 ports and ports are allocated on demand across the subnet.
• Reuse connections with pooling and keep-alive in the application instead of opening a new one per request.
• Use private endpoints so traffic to Azure PaaS never needs SNAT.
• If using Load Balancer outbound rules, manually allocate enough ports per instance.
• Watch the SNAT connection count and failed connection metrics for early warning.

To confirm exhaustion, check the SNAT connection metrics on the load balancer or NAT gateway and compare allocated with used ports. Failures to one destination at peak time while others work is the classic sign. Fixing connection reuse in the app is usually cheaper than adding public IPs.

Azure will reject a peering between VNets whose address spaces overlap, and gateway-based connections cannot route to the overlapping range correctly because the destination is ambiguous.

Fixes, from cleanest to workaround:

1. Renumber one VNet. Cheapest to do early, painful once many resources exist.
2. Expose only the needed service across the boundary using Private Link service, which does not need routable ranges.
3. Use VPN Gateway NAT to translate one side's range when connecting over VPN.

Prevent this with a central IP address plan before creating VNets.

In hub-and-spoke designs overlap hurts most, because the hub cannot route to two networks with the same prefix. Treat non-overlap as a governance rule and enforce it with an IPAM tool or Azure Policy so a new team cannot create an overlapping VNet by accident.

Azure now lets you add or change address ranges on a peered VNet without deleting its peerings. After the change, the remote side must learn the new prefix, so you sync the peering.

az network vnet update -g rg-hub -n vnet-hub \
  --address-prefixes 10.0.0.0/16 10.50.0.0/16

az network vnet peering sync -g rg-spoke \
  --vnet-name vnet-spoke -n spoke-to-hub

Check that the new range does not overlap with the peer or any other connected network first, and update on-premises routes or BGP advertisements if the VNet is connected through a gateway.

If the VNet is also connected by VPN with static routes, the on-premises device needs the new prefix too. Azure Virtual Network Manager can automate the sync when peerings are managed centrally. Always test connectivity to the new range after syncing.

Choose ExpressRoute when you need predictable performance and a connection that avoids the public internet. Choose VPN when you want something quick and cheap, or as a backup.

A common pattern is ExpressRoute as primary with a VPN as failover over the same VNet gateway subnet pair.

Pricing differs too: ExpressRoute has a monthly circuit fee plus metered or unlimited outbound data, while VPN cost is mostly gateway hours. For critical workloads, teams often use two circuits in different peering locations to remove a single point of failure and keep a tested VPN as a lower-bandwidth fallback.

Bastion sits in the VNet in AzureBastionSubnet with its own public IP. You open the VM in the Azure portal, the browser connects to Bastion over HTTPS (443), and Bastion then opens RDP or SSH to the VM's private IP inside the VNet.

sequenceDiagram
  participant U as User browser
  participant B as Bastion (public IP)
  participant V as VM (private IP)
  U->>B: HTTPS 443 via Azure portal
  B->>V: RDP 3389 or SSH 22 (private)
  V-->>U: Session streamed through Bastion

Your VM NSG must allow 3389 or 22 from the Bastion subnet. Bastion also works across peered VNets with Standard SKU or higher, so one Bastion in the hub can serve spokes.

With the Standard SKU you can also connect from your local RDP or SSH client through Bastion using the Azure CLI. Bastion needs free addresses in its /26 to scale out, and its own subnet NSG must allow inbound 443 from the internet and from the GatewayManager service tag.

Subnet delegation gives a specific Azure service permission to create its own resources and network rules inside your subnet. The service injects what it needs (NICs, policies) and manages them on your behalf.

It is required by services such as App Service VNet integration (Microsoft.Web/serverFarms), SQL Managed Instance and Azure Container Instances. A delegated subnet normally hosts only that service's resources, and a subnet can be delegated to one service type.

az network vnet subnet update -g rg-demo --vnet-name vnet-demo \
  -n snet-appsvc --delegations Microsoft.Web/serverFarms

If you try to place unrelated VMs in a delegated subnet, deployment fails with an error saying the subnet is delegated. Create a separate subnet per delegated service and size it for that service's scaling needs, since a subnet holding delegated resources is hard to resize.

Regional VNet integration lets an App Service app make outbound calls into your VNet, so it can reach private databases, peered VNets and on-premises systems over private IPs.

• The app is integrated with a dedicated subnet delegated to Microsoft.Web/serverFarms; a /26 is recommended.
• By default only private-range traffic goes through the VNet; enable route all to send internet-bound traffic through it too (then NSG, UDR and NAT apply).
• It does not make the app reachable privately; for inbound private access add a private endpoint for the app.

The two features solve different directions and are often used together.

For name resolution the app uses the VNet's DNS settings, so private endpoint names resolve only if the matching Private DNS zone is linked to that VNet. Also, an App Service plan integrates with one subnet at a time, and all apps in the plan use it.

AVNM is a central management service for networks at scale across subscriptions. Instead of configuring each VNet individually, you group VNets and apply configurations to the whole group.

• Network groups: static members or dynamic membership using Azure Policy.
• Connectivity configurations: build hub-and-spoke or mesh topologies without hand-creating peerings.
• Security admin rules: organization-wide rules evaluated before NSG rules; NSGs cannot override them.
• Routing configurations: manage UDRs centrally.

It is scoped to a management group or subscription, which makes it a good fit for governance teams.

A common use is a platform team applying baseline rules, such as blocking inbound RDP and SSH from the internet, across hundreds of VNets owned by different teams. Configurations are deployed per region, so you must deploy them to the target regions before they take effect.

Work from the bottom up: check the route, the filters, DNS, then the guest OS. Azure Network Watcher has a tool for each layer.

1. Next hop - is the traffic going where you expect?
2. IP flow verify - does an NSG rule allow or deny that exact 5-tuple, and which rule?
3. Effective routes and security rules on the NIC - what actually applies after UDRs, peering and NSGs combine.
4. Connection troubleshoot or Connection Monitor - end-to-end test with latency and hop details.
5. Check DNS resolution, then the guest firewall and whether the app is listening.

az network watcher show-next-hop -g rg-demo --vm vm1 \
  --source-ip 10.0.1.4 --dest-ip 10.1.1.4

az network watcher test-ip-flow -g rg-demo --vm vm1 \
  --direction Outbound --protocol TCP \
  --local 10.0.1.4:50000 --remote 10.1.1.4:443

Flow logs record information about IP traffic going through your network, stored as JSON in a storage account and optionally analyzed with Traffic Analytics.

Microsoft announced the NSG flow logs retirement for September 30, 2027 and blocked creation of new ones, so new designs should use VNet flow logs. Use them for audits, troubleshooting denied traffic and finding top talkers.

Add Traffic Analytics on top of flow logs for dashboards of top talkers, geographic traffic and blocked flows. Storage cost grows with traffic volume, so set a retention period and enable logs only on the VNets or subnets you really need to audit.

Add a UDR on the workload subnets that sends 0.0.0.0/0 to the firewall's private IP as a Virtual appliance. The firewall then inspects the traffic and forwards it out.

az network route-table create -g rg-hub -n rt-spokes

az network route-table route create -g rg-hub \
  --route-table-name rt-spokes -n default-to-fw \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

az network vnet subnet update -g rg-spoke \
  --vnet-name vnet-spoke -n snet-app --route-table rt-hub

• If the appliance is an NVA, enable IP forwarding on its NIC.
• Keep the firewall subnet itself on a route to the internet to avoid a routing loop.
• Make return paths symmetric, or stateful firewalls will drop the asymmetric traffic.

A common mistake is forgetting the route table on the firewall's own subnet or adding a 0.0.0.0/0 route that loops traffic back to itself. If on-premises also advertises 0.0.0.0/0 over BGP, a UDR for the same prefix takes precedence, so check the effective route table when traffic does not take the path you expect.

Virtual WAN is a managed networking service that creates Microsoft-managed hubs with built-in transit routing between branches, VNets and users. A self-built hub-and-spoke gives you the same shape, but you build and operate every part.

Pick Virtual WAN for large, multi-region, branch-heavy networks; pick a custom hub for small to mid-size or highly customized designs.

Virtual WAN also supports routing intent and policies that send internet and private traffic to a firewall or NVA inside the hub without hand-written UDRs. Spokes join through hub virtual network connections instead of peerings, and the hub address space must not overlap any spoke.

A VNet is a regional resource, and its subnets and attached resources depend on that region's fabric, so Azure does not support a direct move. You recreate the network in the target region.

1. Export the VNet definition (ARM template) or, better, deploy from Bicep or Terraform to the new region.
2. Pick address space: reuse it if the old VNet will be deleted, otherwise choose a non-overlapping range.
3. Recreate dependent pieces: NSGs, route tables, NAT gateways, private endpoints, peerings and DNS links.
4. Move or redeploy the workloads, then update peerings, DNS and on-premises routes.
5. Cut over and remove the old VNet.

Azure Resource Mover can automate parts of this for supported resource types, but plan for dependencies and downtime.

Do a dry run in a test subscription, because private endpoints, DNS zones and service connections hold references to the old VNet. Lowering DNS TTLs before cutover shortens the time clients keep resolving old addresses.

A service tag is a named group of IP prefixes for an Azure service that Microsoft maintains and updates automatically. You use the tag name in an NSG, Azure Firewall or UDR instead of tracking IP ranges yourself.

az network nsg rule create -g rg-demo --nsg-name nsg-app -n allow-storage-out \
  --priority 300 --direction Outbound --access Allow --protocol Tcp \
  --destination-address-prefixes Storage.EastUS --destination-port-ranges 443

Regional variants such as Storage.EastUS keep rules tighter, and when a service adds IP ranges your rule keeps working. Tags do not replace scope thinking, though: the Storage tag covers every storage account in Azure, not only yours, so combine it with private endpoints or storage firewalls for tighter control.

Plan it before creating anything, because renumbering later is expensive. Start from what already exists and leave room to grow.

1. Inventory on-premises and existing Azure ranges so nothing overlaps.
2. Use RFC 1918 space, and allocate a block per region or environment.
3. Size subnets for growth, remembering Azure reserves five addresses per subnet.
4. Reserve dedicated subnets for platform services.
5. Document the plan, or use a central IPAM such as the one in Azure Virtual Network Manager.

Avoid making every VNet a /16 by habit; wasted space makes later peering and hybrid connections harder.

Leave unallocated space between subnets for growth, and keep one block per environment so firewall and NSG rules can use summarized prefixes. For AKS with Azure CNI, count pod IPs as well as node IPs, since each pod can take an address from the subnet unless you use overlay networking.