Post

Azure Networking Foundations

Posted
By Fábio Ferreira
6 min read
Azure Networking Foundations

Why Azure Networking Matters

Virtual networking is the backbone of cloud infrastructure it enables connectivity, ensures isolation, enforces security, and facilitates hybrid deployments. Mastering VNets, subnets, IP addressing strategies, NSGs, and egress patterns is essential for designing resilient Azure architectures and passing the AZ-104 exam.

Virtual Network (VNet)

A VNet is Azure’s core networking primitive: a regional, isolated private network containing one or more CIDR address spaces divided into subnets.

Key Characteristics

  • Regional Scope: Each VNet exists in a single region. Cross-region connectivity is achieved through peering or hybrid gateways.
  • Address Space: One or more CIDR blocks following RFC1918 standards (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Peered VNets must not overlap.
  • Subnets: Logical subdivisions of the address space, each with its own NSG, route table, and service endpoints.
  • Reserved IPs: Azure reserves 5 IPs per subnet (.0 network, .1 gateway, .2–.3 DNS, .255 broadcast). A /24 subnet yields 251 usable IPs.

Default Connectivity Behavior

  • ✅ Intra-VNet: Resources communicate freely across subnets via system routes.
  • ✅ Outbound Internet: Enabled by default using ephemeral Microsoft IP addresses.
  • ❌ Inbound: Blocked by default unless a Public IP is attached and NSG rules permit it.
  • Peering: Automatically creates routes to peer VNets (non-transitive by default).

Reserved Subnet Names

Azure reserves specific subnet names for dedicated gateway and service deployments:

Subnet Name Purpose Minimum Size
GatewaySubnet VPN Gateway or ExpressRoute Gateway /27
AzureBastionSubnet Bastion Host /26
AzureFirewallSubnet Azure Firewall /26
RouteServerSubnet Azure Route Server /27

⚠️ Modification Constraints: VNet and subnet address spaces cannot be modified if active resources would be affected. Plan carefully before deployment.

IP Addressing Strategy

Private IP Addresses

Private IPs are assigned to network interfaces via Azure DHCP (dynamic mode) or manually configured (static mode).

  • Dynamic: Default behavior; IPs may change after a VM stop/deallocate.
  • Static: Fixed assignment, recommended for domain controllers, firewalls, and internal DNS servers.
  • Placement: Typically on the NIC, but for load balancers and application gateways, configured as a front-end IP on the resource itself.

Public IP Addresses

Public IPs are standalone resources that associate with VMs, load balancers, VPN gateways, NAT gateways, Bastion hosts, and firewalls.

Modes:

  • Static: Recommended for production; persists even after disassociation.
  • Dynamic: Released upon resource dissociation.

SKU Comparison:

SKU Status Inbound Default Notes
Basic 🚨 Retired (Sept 30, 2025) Open No longer available; migrate to Standard.
Standard Active (recommended) Blocked Zero-trust model; requires explicit NSG rules. Zone-redundant or zonal.

Critical for AZ-104: Standard SKU Public IPs block inbound traffic by default—this enforces a zero-trust security posture.

Outbound Internet Connectivity

Azure provides four options for VMs to reach the internet, evaluated in this priority order:

  1. Public IP on the VM (highest priority)
  2. NAT Gateway on the subnet
  3. Public Load Balancer with outbound rules
  4. Azure Default Outbound IP (ephemeral; deprecated for new VNets—Microsoft recommends NAT Gateway)

Managing SNAT Port Exhaustion

When a private VM initiates an outbound connection, Azure performs Source NAT (SNAT), translating the private IP to a public IP so return traffic reaches the VM.

  • Each connection consumes 1 SNAT port (up to ~64k per public IP).
  • Exhaustion occurs with high connection volume, causing new outbound attempts to fail.

NAT Gateway Solution:

  • Deploys one or more public IPs attached to the subnet.
  • All subnet VMs exit through these IPs.
  • Scalable SNAT: up to 16 public IPs or a public IP prefix provides ~1M ports.
  • Eliminates SNAT exhaustion (vs. default ~1024 ports per VM).
  • Outbound-only; does not accept inbound connections.
  • For HA, deploy multiple public IPs (single IP is a potential SPOF).

Network Security Group (NSG)

An NSG is a stateful L3/L4 firewall that filters traffic based on source/destination IP, port, and protocol.

Rule Composition

Each NSG rule contains:

Element Details
Priority 100–4096; lower numbers apply first. First match wins.
Source/Destination IP address, CIDR, Service Tag, Application Security Group, or predefined values (Any, VirtualNetwork, Internet).
Protocol TCP, UDP, ICMP, or Any.
Port Range Single port, range (e.g., 80-90), comma-separated list (e.g., 80,443).
Action Allow or Deny.
Direction Inbound or Outbound.

Default Built-in Rules

NSGs have non-deletable default rules (priority 65000+):

Inbound:

  • AllowVNetInBound (65000): Allow internal VNet and peered VNet traffic.
  • AllowAzureLoadBalancerInBound (65001): Allow health probes.
  • DenyAllInBound (65500): Deny all other inbound traffic.

Outbound:

  • AllowVNetOutBound (65000): Allow internal VNet traffic.
  • AllowInternetOutBound (65001): Allow internet access.
  • DenyAllOutBound (65500): Deny all other outbound traffic.

NSG Association: Subnet vs. NIC

NSGs associate with subnets and/or NICs. When both apply:

  • Inbound Traffic Path: Subnet NSG → NIC NSG
  • Outbound Traffic Path: NIC NSG → Subnet NSG
  • Evaluation: Both are evaluated in series; the most restrictive rule wins (if either blocks, traffic is blocked).
  • Statefulness: Established connections automatically allow return traffic regardless of direction rules.

Limitations

  • No L7 Inspection: NSGs operate at L3/L4 only. Use Azure Firewall or Application Gateway WAF for deep packet inspection.
  • IP Traffic Only: System routes already permit certain east-west flows; NSGs apply only to IP-based flows.

Augmented Security: Service Tags and ASGs

Service Tags

Service Tags are Microsoft-managed IP sets representing Azure service ranges—automatically updated and regionalized.

Common Service Tags:

  • Internet, VirtualNetwork, AzureLoadBalancer
  • Storage, Storage.WestEurope (regionalizable)
  • AzureCloud, AzureActiveDirectory, AzureKeyVault, AzureBackup
  • Sql, AzureMonitor, EventHub

❌ Service Tags cannot be customized—all are managed by Microsoft.

Application Security Groups (ASG)

ASGs group NICs logically, allowing NSG rules based on role rather than IP addresses (e.g., web-asg, database-asg).

Key Rules:

  • ASGs attach to NICs, not VMs directly (though functionally equivalent).
  • All NICs in an ASG must reside in the same VNet.
  • When an ASG is both source and destination in a rule, all resources must be in the same VNet.
  • A single NIC can belong to multiple ASGs.

Best Practice: Replace IP-based NSG rules with web-asg → database-asg port 1433 Allow to simplify management and improve scalability.

Portal Deployment Examples

Creating a VNet

  1. Navigate to Virtual networks > Create.
  2. On the IP addresses tab, define the address space and at least one subnet (required before creation).
  3. To modify post-creation: VNet > Address space or Subnets > Add (impossible if overlap conflicts with active resources).

Setting Up Public IP and NAT Gateway

1
2
3
4
5
6

Public IP > Create
  SKU: Standard, Static, regional or zonal

NAT Gateway > Create
  Associate the Public IP
  Select subnets via the "Subnets" tab

For Production: A single public IP provides no SLA. Deploy multiple IPs or a /28 prefix (16 IPs) for redundancy.

Configuring a Basic NSG for RDP Access

  1. Network security groups > Create.
  2. Associate with the target subnet or VM NIC via the NSG’s Subnets or Network interfaces tabs (or vice versa from the resource’s Networking settings).
  3. Add Inbound Rule:
    • Source: Any (or restrict to your IP for security)
    • Destination: Any
    • Service: RDP (port 3389)
    • Action: Allow, Priority: 300

Security Best Practice: Restrict source to your IP, or better yet, use Azure Bastion to avoid exposing RDP/SSH to the public internet.

Combining NSG and ASG

  1. Create ASG: Application security groups > Create (regional; VNet assignment happens on first NIC attachment).
  2. Assign VMs to ASG: VM > Networking > Application security groups > Configure ASGs (ASG “locks” to the first NIC’s VNet).
  3. Add NSG Rule: Source: web subnet > Destination: ASG management-servers > Port 3389 Allow.
  4. Restrict Outbound Web Traffic (except Azure Backup):
    • Rule 1: Destination: Service Tag AzureBackup > Allow (lower priority).
    • Rule 2: Destination: Service Tag Internet, Ports 80,443 > Deny (higher priority).

Summary: Master VNets, subnets, NSGs, and egress strategies to design secure, scalable Azure architectures. Use Service Tags and ASGs to simplify rule management and enforce zero-trust principles from the start.

Cloud, Azure-104
azure networking vnet nsg security
This post is licensed under CC BY-NC-ND 4.0 by the author.