Virtual Networks

A virtual network (VNet) is an isolated, private IP address space inside a single Azure region and subscription (or shared across subscriptions via peering, below). Nothing is directly reachable across VNets, or from the internet into a VNet, unless something explicitly allows it — a public IP, a load balancer, a VPN or ExpressRoute connection, or peering.

A VNet is assigned one or more address spaces in CIDR notation (private ranges such as 10.0.0.0/16 are typical, though any valid CIDR block —  including public-looking ranges Azure reserves the VNet’s exclusive use of — can be used internally). Every subnet carves out a contiguous sub-range of an address space and is where actual resources — VM network interfaces, Container Apps environments, AKS nodes, private endpoints — attach. Azure reserves the first four and the last address of every subnet (network address, default gateway, two addresses reserved for Azure DNS, and the broadcast address), so a /24 subnet — 256 addresses in total — has only 251 usable ones.

A handful of subnet names and shapes are reserved for specific services and cannot be reused for general workloads:

A network security group (NSG) is a stateful, layer 3/4 packet filter: a list of allow/deny rules, evaluated by priority (100-4096, lower runs first), that can be attached to a subnet, a network interface, or both. Traffic is matched against the lowest-priority rule that applies; once a connection is allowed, return traffic is allowed automatically (statefulness), which is why NSGs need no explicit "allow response" rules the way a stateless ACL would.

Every rule has a direction (inbound/outbound), a priority, source and destination (an IP range, an ASG, or a service tag), a protocol and port range, and an allow/deny action. Several built-in default rules always exist at the bottom of the priority range (65000-65500): allow VNet-to-VNet traffic, allow inbound from the Azure Load Balancer’s health-probe address, and deny everything else — a subnet or NIC with no custom rules is closed to the internet by default.

Service tags are Microsoft-maintained groups of IP prefixes for a category of traffic — Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql, AzureCloud, Storage.EastUS2, and dozens more — so a rule can say "allow from `Storage`" rather than tracking Azure’s storage IP ranges by hand; Microsoft updates the tags' contents as its own address ranges change, with no rule edit required.

Peering connects two VNets so resources in each can reach the other over the Microsoft backbone at private IP addresses, with no public internet hop and (for regional peering) no measurable added latency. Two properties matter most in practice:

Each side of a peering also independently controls allow forwarded traffic (whether to accept traffic whose source is not directly in the peered VNet — required for hub-spoke routing through a central firewall), allow gateway transit / use remote gateways (letting a spoke without its own VPN Gateway use the hub’s), and allow virtual network access (the base connectivity toggle).

Both mechanisms below let a subnet reach a PaaS service (Storage, Key Vault, PostgreSQL flexible server’s private-access mode, and so on) without the traffic crossing the public internet, but they work very differently and are not interchangeable.

Service endpoints remain useful for same-VNet, cost-sensitive scenarios (or storage account access from a subnet where a private endpoint would be overkill); private endpoints are the current recommendation whenever a private, addressable identity for the specific resource instance is needed — which is every Bookshelf case below, since pg-bookshelf, kv-bookshelf and stbookshelf all need to be reachable by name from both the app subnet and, for admins, over the VPN in VPN Gateway and Hybrid Connectivity.

Azure DNS hosts two kinds of zone, both independent of the private-endpoint DNS pattern above (which uses private zones but is otherwise a specialized case of the same service):

Azure DNS Private Resolver bridges the two worlds: it is a managed resolver, deployed with its own inbound and outbound endpoints into a subnet of a VNet, that lets on-premises DNS servers forward queries for Azure private zones into Azure (inbound endpoint) and lets Azure-side clients forward queries for on-premises names out to on-premises DNS servers via conditional forwarding rulesets (outbound endpoint) — replacing the older pattern of running a custom DNS VM for hybrid resolution. Each endpoint needs its own dedicated subnet, /28 to /24, delegated to Microsoft.Network/dnsResolvers and distinct from AzureBastionSubnet/GatewaySubnet/ AzureFirewallSubnet. An inbound endpoint resolves names using Azure DNS from inside its own VNet, so it answers for every private DNS zone linked to that VNet.

Bookshelf needs one, because of its point-to-site VPN admins. A laptop connected over P2S (VPN Gateway and Hybrid Connectivity) is not inside any VNet and cannot use Azure-provided DNS (168.63.129.16), so without help it resolves pg-bookshelf.postgres.database.azure.com to the public endpoint — which is disabled — instead of the private one. Bookshelf therefore deploys dnspr-bookshelf in the hub with a single inbound endpoint at the static address 10.0.0.68 (in snet-dns-inbound, 10.0.0.64/28), links the privatelink. zones to the hub (above), and sets vnet-hub-bookshelf’s *DNS servers to `10.0.0.68. VPN clients are handed the DNS servers configured on the gateway’s VNet, so the client profile downloaded after that change points the laptop at the resolver. The inbound endpoint forwards everything else to Azure DNS, so public names — including the ones vgw-bookshelf itself needs — keep resolving. The same inbound endpoint is also what an on-premises DNS server would conditionally forward privatelink.* queries to over the site-to-site tunnel.

Azure Bastion is a managed jump-host service: it publishes an RDP/SSH portal reachable over TLS 443 from the Azure portal or a native client, so admins reach VMs by private IP without those VMs ever needing a public IP or an internet-facing NSG rule. Bastion runs from its own AzureBastionSubnet (see the reserved-subnet table above), sized /26 or larger.

Four SKUs are available, each a superset of the one before, checked against current Microsoft Learn guidance:

Bookshelf’s bas-bookshelf in the diagram below is Standard, matching the plain single-hub scenario; Premium would be the natural upgrade if session recording became a compliance requirement.

Azure Firewall is a managed, stateful, highly available network firewall and threat-protection service, deployed into its own AzureFirewallSubnet and typically the single egress/inspection point for a hub in a hub-spoke design (spokes route 0.0.0.0/0 to it via a UDR). Rules are organized as network rules (layer 3/4: IP/port/protocol, including matching by service tag), application rules (layer 7: FQDN or FQDN-tag filtering for HTTP/S and MSSQL), and, on Premium, deep inspection.

Three SKUs, per current Microsoft Learn guidance:

Bookshelf’s diagram below uses Standard in the hub — enough for FQDN and threat-intelligence filtering on outbound traffic from both snet-apps and any hub-routed spoke, without needing Premium’s TLS inspection.

Azure NAT Gateway gives every VM/instance in an attached subnet a shared, static set of outbound public IPs for SNAT — an alternative to a Standard Load Balancer’s outbound rules or per-VM public IPs, with a much larger SNAT port budget (64,512 ports per attached public IP) and no risk of the load balancer’s connection-based SNAT port exhaustion pattern. A NAT gateway is a subnet’s default route for internet-bound traffic once attached; it cannot be combined with GatewaySubnet, and its public IPs cannot have DDoS Protection IP-level policies enabled directly.

Two SKUs currently exist, per current Microsoft Learn guidance: Standard, a zonal resource (resilient within one availability zone, IPv4-only), and StandardV2, zone-redundant by default (spans multiple zones in one resource, no separate zonal deployment needed), supporting both IPv4 and IPv6 public IPs/prefixes plus NAT64, at up to 100 Gbps and 10 million packets per second (versus Standard’s 50 Gbps split across in/out and 5 million PPS). StandardV2 requires StandardV2 public IPs specifically — Standard/Basic public IPs are not compatible with it — and there is no in-place upgrade path from Standard to StandardV2; replacing one with the other means re-IPing. For a new deployment, StandardV2 is the SKU to reach for unless a specific IPv4-only, single-zone design is intentional.

Historically, a VM (or VM Scale Set instance) deployed in a subnet with no explicit outbound method — no NAT gateway, no Standard Load Balancer outbound rule, no public IP on the NIC — still got outbound internet connectivity anyway, through an implicit default outbound access IP owned and rotated by Microsoft. That implicit IP is not customer-owned, can change without notice, does not support fragmented packets or ICMP pings, and behaves inconsistently across a scaled-out VM Scale Set — all reasons Microsoft has long recommended against relying on it.

Per current Microsoft Learn guidance, for API versions released after March 31, 2026, a subnet in a newly created virtual network defaults its defaultOutboundAccess property to false (a "private" subnet) — the Azure portal already defaults new subnets this way. A private subnet’s VMs get no default outbound IP at all and must use an explicit method: a NAT gateway attached to the subnet, a Standard Load Balancer with outbound rules, a public IP on the NIC, or a UDR pointing default traffic at a firewall/NVA. This change does not touch existing virtual networks or existing subnets — they keep whatever defaultOutboundAccess behavior they already had — and it can still be overridden explicitly (--default-outbound false/true on az network vnet subnet create/update, or the ARM defaultOutboundAccess property) regardless of which API version created the network.

Because snet-apps in Bookshelf’s own topology already gets an explicit outbound method (the NAT gateway above, or the hub firewall’s UDR), this change affects Bookshelf’s design not at all in practice — but it is the reason every subnet below is built with one of those explicit methods from the start, rather than depending on default behavior that new deployments increasingly do not have.

Azure’s system routes already send VNet-local traffic directly and internet-bound traffic out through the platform’s own default outbound path (or an explicit method, above). A user-defined route (UDR) overrides that default for a chosen address prefix, in a route table attached to one or more subnets. The most common next-hop types are Virtual appliance (an IP address — typically a firewall/NVA’s private IP, used to force 0.0.0.0/0 through inspection), VNet Gateway, None (a black hole, useful to explicitly deny a prefix), and Internet (bypass an otherwise-forced route, for example to exempt specific service-tag destinations from firewall inspection).

Bookshelf’s spoke routes its own default traffic to the hub firewall’s private IP so all outbound internet traffic from snet-apps is inspected and gets Firewall’s threat-intelligence filtering, while VNet-local and peered traffic (to `snet-data’s private endpoints, and across the peering to the hub) is left on system routes.

Every public IP in Azure already has DDoS Protection Basic, free and always on: platform-level mitigation of common network-layer volumetric attacks, with no configuration and no SLA guarantee. DDoS Protection (Standard tier) is an opt-in, billed resource, associated with one or more VNets, that adds adaptive tuning based on the VNet’s own traffic patterns, attack analytics and alerting, a cost-protection SLA for scaled-out resources during a mitigated attack, and access to Microsoft’s DDoS rapid-response team during an active attack. It protects public IPs attached to resources inside the protected VNet — load balancers, Application Gateway/WAF, VMs with public IPs, and (with the caveat under NAT Gateway) not NAT gateway public IPs. Bookshelf’s own scenario does not enable it — Standard’s per-VNet pricing is aimed at internet-facing production workloads at real DDoS risk, which is a judgment call each real deployment makes for itself, not something this teaching scenario needs.

Network Watcher is Azure’s regional network diagnostics and monitoring service, enabled automatically per region the first time a VNet is created there. Two of its tools cover most day-to-day troubleshooting for the topology on this page:

Bookshelf’s network is deliberately a lite hub-spoke: one small hub VNet for shared perimeter services, one spoke VNet for the actual workload, peered together — enough to teach the pattern without the multi-spoke, multi-region scale a real enterprise landing zone would add.

This is intentionally not a full landing-zone design — there is no separate identity or management spoke, no Virtual WAN, and a single region — but every mechanism a larger design would add (peering, a central firewall with UDR-forced routing, private endpoints with shared DNS, Bastion) is already present in miniature.

Bastion, Firewall, and VPN Gateway are deleted explicitly first because each holds a Standard public IP and, for Firewall and the gateway, takes several minutes to tear down — deleting the resource group alone eventually removes everything, but doing so here avoids the confusing intermediate state where the group delete is still in progress.