Skip to content

Portal | Level: L1: Foundations | Topics: Azure Virtual Network, Cloud Deep Dive | Domain: Cloud

Azure Virtual Network - Primer

Accuracy note: Azure changes quickly. Limits and defaults below were checked against Microsoft Learn documentation as of July 2026. Items marked verify for region/SKU are intentionally not presented as universal because Azure capabilities, quotas, and rollout status can differ by region, subscription, API version, and resource SKU.

Why This Matters

Azure Virtual Network is the closest equivalent to an AWS VPC, but the resource hierarchy and routing/security defaults differ enough that direct translation causes production mistakes.

A VNet is a regional Layer-3 overlay network with one or more IPv4/IPv6 address spaces. It contains subnets, and Azure resources attach through network interfaces or service-specific VNet integration. Azure does not expose customer VLANs or normal Layer-2 broadcast/multicast semantics. (Microsoft Learn: VNet FAQ)

Address Spaces and Subnets

  • A VNet can contain multiple non-overlapping address prefixes.
  • Subnets carve ranges from the VNet address space.
  • Subnets are regional because the VNet is regional.
  • Azure reserves five IPv4 addresses in every subnet: the first four and the last. (Microsoft Learn: Private IP addresses)
  • The smallest supported IPv4 subnet is /29; IPv6 subnets are /64.

Unlike AWS, Azure does not have a concept named "public subnet" determined by a route to an Internet Gateway. A subnet's internet behavior depends on public IPs, load balancers, NAT Gateway, firewall/NVA routes, and the newer private subnet setting that disables implicit default outbound access.

For API versions after March 31, 2026, new VNets default toward private-subnet behavior requiring an explicit outbound method. Treat implicit outbound access as legacy and nondeterministic for architecture. (Microsoft Learn: Default outbound access)

Network Interfaces and IP Addresses

A VM NIC attaches to one subnet in one VNet and can hold multiple IP configurations. VM size controls how many NICs and aggregate network throughput are supported. Public IP addresses are separate resources and can be attached to NICs or load balancer frontends.

Dynamic private IP means Azure allocates the address; it normally persists while the NIC exists. It is not equivalent to DHCP churn on every reboot. Static private IP is a reservation in the NIC configuration, not a manually configured guest address.

Routing

Azure automatically creates system routes for:

  • VNet address spaces.
  • Internet (0.0.0.0/0).
  • Special platform/service routes.
  • Peering and gateway propagation when configured.

A route table contains user-defined routes (UDRs) and is associated with subnets, not the entire VNet. Azure routes between subnets in the same VNet by default; there is no need for a per-subnet local route table entry. (Microsoft Learn: VNet traffic routing)

Typical next hops include:

  • Virtual appliance.
  • Virtual network gateway.
  • Internet.
  • None (drop/blackhole).

Azure selects longest prefix first, then applies route-source preference rules where prefixes tie. Troubleshooting should use effective routes on the NIC, not just inspect the configured route table.

Network Security Groups

An NSG is a stateful Layer-3/Layer-4 filter associated with a subnet, NIC, or both. Rules have priorities from 100 through 4096; lower numbers win and processing stops on first match. Azure adds default rules at lower precedence, including allowing VNet traffic, allowing Azure Load Balancer probes, denying other inbound, allowing outbound VNet/internet, and denying other outbound according to the current rule set. (Microsoft Learn: NSG overview)

NSGs are stateful: return traffic for an allowed connection is automatically permitted. Changing a rule affects new flows; existing established flows may persist until flow state expires or connections reset.

Application Security Groups (ASGs) group NICs by application role so NSG rules can refer to logical groups rather than IP lists. ASGs are not cross-VNet identity groups.

VNet Peering

VNet peering connects VNets over the Microsoft backbone. Peering can be regional or global and can cross subscriptions and, with permissions, tenants.

Important properties:

  • Peering links are configured in both directions.
  • Address spaces cannot overlap.
  • Peering is not transitive.
  • Gateway transit must be explicitly configured.
  • NSGs and UDRs still apply.
  • Peering traffic is billable even though creating the peering object is not.

A VNet supports up to 500 peerings by default and up to 1,000 with Azure Virtual Network Manager connectivity configuration, subject to current platform limits. (Microsoft Learn: VNet peering)

Service Endpoints versus Private Endpoints

  • Service endpoint: Extends subnet identity to a supported Azure PaaS service while traffic uses the service's public endpoint over the Microsoft backbone. You must enable the endpoint on the subnet and configure the service firewall/ACL. It does not create a private IP for the service.
  • Private endpoint: A NIC with a private IP in your subnet representing a specific PaaS resource/subresource through Private Link. DNS normally maps the service's public hostname to the private endpoint address for clients in the private DNS scope.

Private endpoints solve on-premises/private-address access more naturally but create DNS, IP-consumption, approval, and per-endpoint cost/management overhead.

Outbound Connectivity

Explicit outbound options include:

  • NAT Gateway.
  • Standard Load Balancer outbound rules.
  • Public IP on the resource.
  • Azure Firewall or third-party NVA.
  • Certain service-specific egress mechanisms.

NAT Gateway attaches to subnets and provides predictable SNAT. Each public IP contributes 64,512 SNAT ports; a gateway can use up to 16 public IP addresses, yielding over one million ports. (Microsoft Learn: NAT Gateway SNAT)

DNS

Azure-provided DNS is sufficient for basic same-VNet hostname resolution but is not a full enterprise DNS service. Common production components:

  • Azure Private DNS zones.
  • Azure DNS Private Resolver inbound/outbound endpoints.
  • Custom DNS servers or Active Directory DNS.
  • Conditional forwarding for Private Link zones.

The VNet DNS server setting is delivered to attached resources, but changing it does not necessarily refresh every guest immediately. DHCP lease renewal or restart may be required.

See Also

Content status: This topic pack is partial. Footguns beyond item 13, the AWS-equivalent crosswalk table, and the quick-facts trivia page have not been added yet — the source research was cut off mid-list. See footguns.md for the note on what's pending.

Wiki Navigation

Prerequisites

Related Content

  • AWS CloudWatch (Topic Pack, L2) — Cloud Deep Dive
  • AWS Devops Flashcards (CLI) (flashcard_deck, L1) — Cloud Deep Dive
  • AWS EC2 (Topic Pack, L1) — Cloud Deep Dive
  • AWS ECS (Topic Pack, L2) — Cloud Deep Dive
  • AWS General Flashcards (CLI) (flashcard_deck, L1) — Cloud Deep Dive
  • AWS IAM (Topic Pack, L1) — Cloud Deep Dive
  • AWS Lambda (Topic Pack, L2) — Cloud Deep Dive
  • AWS Networking (Topic Pack, L1) — Cloud Deep Dive
  • AWS Route 53 (Topic Pack, L2) — Cloud Deep Dive
  • AWS S3 Deep Dive (Topic Pack, L1) — Cloud Deep Dive