Module 2 Beginner to Intermediate AZ-104 AZ-900 22 min read

Azure Networking

Azure Networking is the foundation that connects all your Azure resources together and to the outside world. Understanding networking is essential for every cloud professional — it's how you control who can talk to what, how traffic flows, and how you keep everything secure.

What you'll learn: Virtual Networks & Subnets · Network Security Groups · Public & Private IP addresses · VNet Peering · VPN Gateway · Azure Load Balancer · Application Gateway · Azure DNS · Azure Bastion · Network Watcher · Real world architectures · AZ-104 exam tips

In this tutorial

Azure Virtual Network (VNet)

Subnets

Network Security Groups (NSG)

Public and Private IP addresses

VNet Peering

VPN Gateway

Azure Load Balancer

Azure Application Gateway

Azure DNS

Azure Bastion

Network Watcher

Real world network architecture

AZ-104 exam tips

Azure Virtual Network (VNet)

An Azure Virtual Network (VNet) is the fundamental building block of networking in Azure. It's your own private, isolated network in the cloud — similar to a traditional on-premises network but without the physical hardware.

When you create a VNet, you define an address space using CIDR notation — for example, 10.0.0.0/16 gives you 65,536 IP addresses to use within your private network. Resources inside the VNet can communicate with each other privately without going over the public internet.

💡 Real world analogy: Think of a VNet like the private network inside your office building. Computers inside can talk to each other freely. To communicate with the outside world (internet), traffic goes through a controlled gateway. To connect two office buildings, you set up a dedicated link between them.

VNet is region-specific — A VNet exists in one Azure region. Resources in a VNet in Central India cannot directly communicate with resources in a VNet in East US without additional configuration (VNet Peering or VPN).

VNets are free — There's no charge for creating a VNet. You pay for the resources inside it (VMs, gateways etc.) and for data transfer out of Azure.

VNets are isolated by default — Traffic cannot flow between two VNets unless you explicitly configure it. This isolation is a fundamental security feature.

Azure CLI — Create a Virtual Network

        # Create a Virtual Network with address space 10.0.0.0/16

        az network vnet create \

          --name rkc-vnet \

          --resource-group rkc-network-rg \

          --location centralindia \

          --address-prefix 10.0.0.0/16

Subnets

A subnet is a subdivision of a VNet's address space. You segment your VNet into subnets to organise resources and apply different security policies to different groups of resources.

For example, in a typical 3-tier application you'd create three subnets:

        Typical 3-tier application subnet design:

        VNet              → 10.0.0.0/16

        Web subnet        → 10.0.1.0/24  (web servers, public-facing)

        App subnet        → 10.0.2.0/24  (application servers, internal)

        Database subnet   → 10.0.3.0/24  (databases, most restricted)

Azure reserves 5 IP addresses in every subnet — the first 4 and the last. For example, in a /24 subnet you get 251 usable addresses, not 256.

Service subnets — Some Azure services require a dedicated subnet. For example, Azure Bastion requires a subnet named exactly AzureBastionSubnet, and VPN Gateway requires GatewaySubnet.

Subnet delegation — You can delegate a subnet to a specific Azure service (like Azure App Service or Azure SQL Managed Instance) giving that service exclusive use of that subnet.

Network Security Groups (NSG)

A Network Security Group (NSG) is Azure's virtual firewall. It contains a list of security rules that allow or deny inbound and outbound network traffic to resources. NSGs can be associated with subnets or individual network interfaces.

NSG rules have 5 properties:
• Priority — Number from 100 to 4096. Lower number = higher priority. Rules are processed in priority order, lowest first.
• Source/Destination — IP address, CIDR range, service tag, or application security group
• Port — Single port (80), range (8000-8080), or * for all
• Protocol — TCP, UDP, ICMP, or Any
• Action — Allow or Deny

Default rules — Every NSG comes with default rules that you cannot delete. These allow VNet-to-VNet traffic and Azure load balancer traffic, and deny all other inbound traffic from the internet.

Service tags — Instead of specifying IP ranges, use service tags like Internet, VirtualNetwork, AzureLoadBalancer, Storage. Azure automatically manages the IP ranges behind these tags.

Azure CLI — Create an NSG rule to allow HTTP traffic

        # Create an NSG

        az network nsg create \

          --name rkc-web-nsg \

          --resource-group rkc-network-rg \

          --location centralindia

        # Add a rule to allow HTTP (port 80) from the internet

        az network nsg rule create \

          --nsg-name rkc-web-nsg \

          --resource-group rkc-network-rg \

          --name Allow-HTTP \

          --priority 100 \

          --protocol Tcp \

          --destination-port-range 80 \

          --access Allow

Public and Private IP addresses

Public IP addresses — Accessible from the internet. Assigned to resources that need to be reachable from outside Azure — like a VM running a web server or a Load Balancer. Available as Dynamic (changes when resource is stopped) or Static (never changes).

Private IP addresses — Only accessible within the VNet and connected networks. Every resource deployed in a VNet gets a private IP. Never accessible from the internet directly.

SKUs matter:
• Basic SKU — Older, being retired. Dynamic allocation, open by default, no Availability Zone support
• Standard SKU — Current recommended SKU. Static allocation, closed by default (requires NSG), supports Availability Zones. Always use Standard for new deployments.

VNet Peering

VNet Peering connects two Azure VNets so resources in both VNets can communicate with each other using private IP addresses — as if they were on the same network. Traffic between peered VNets stays on Microsoft's backbone network and never goes over the public internet.

Regional peering — Connect two VNets in the same region. Very low latency, free data transfer within the same region.

Global peering — Connect VNets in different regions. Traffic stays on Microsoft's global backbone. Small data transfer charge applies.

Peering is non-transitive — If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot communicate with VNet C automatically. You'd need to peer A with C directly or use Azure Virtual WAN.

VPN Gateway

Azure VPN Gateway enables encrypted connections between your Azure VNet and your on-premises network (or another VNet) over the public internet.

Site-to-Site VPN — Connect your entire on-premises network to Azure. Requires a VPN device on-premises. Used for hybrid cloud scenarios where you want Azure to feel like an extension of your own datacenter.

Point-to-Site VPN — Connect individual computers (like your laptop) to the Azure VNet. Used by developers and remote workers to securely access Azure resources without exposing them to the internet.

VNet-to-VNet VPN — Connect two Azure VNets in different regions using VPN tunnels. Alternative to Global VNet Peering when you need encrypted transit.

ExpressRoute — A premium alternative to VPN Gateway. Provides a private, dedicated connection between your on-premises network and Azure — not over the public internet. Offers higher bandwidth, lower latency, and more reliability than VPN. Used by large enterprises with strict compliance requirements.

Azure Load Balancer

Azure Load Balancer distributes incoming network traffic across multiple backend resources (like VMs) to ensure no single resource is overwhelmed. It operates at Layer 4 (Transport layer) of the OSI model — it understands TCP and UDP but not HTTP/HTTPS.

Public Load Balancer — Distributes internet traffic across VMs. Has a public IP address. Used for internet-facing applications.

Internal Load Balancer — Distributes traffic within a VNet using private IP addresses. No public IP. Used for internal applications and database tier load balancing.

Health probes — Load Balancer regularly checks if backend VMs are healthy. If a VM fails the health probe, Load Balancer stops sending traffic to it automatically.

SKUs: Basic (free, limited features) and Standard (recommended, supports Availability Zones, HTTPS health probes, outbound rules). Always use Standard for production.

Azure Application Gateway

Azure Application Gateway is a web traffic load balancer that operates at Layer 7 (Application layer). Unlike Azure Load Balancer which only understands TCP/UDP, Application Gateway understands HTTP/HTTPS and can make routing decisions based on URL paths, hostnames, and other HTTP attributes.

URL-based routing — Route requests to different backend pools based on URL path. For example, requests to /images/* go to an image server pool and requests to /api/* go to an API server pool.

SSL termination — Application Gateway handles SSL/TLS decryption, reducing CPU load on backend servers. Traffic between Application Gateway and backends can be HTTP (encrypted by internal network) or HTTPS.

Web Application Firewall (WAF) — Application Gateway v2 includes an optional WAF that protects your web applications against common attacks like SQL injection, cross-site scripting (XSS), and the OWASP Top 10 vulnerabilities.

When to use Load Balancer vs Application Gateway:
• Non-HTTP traffic (TCP/UDP, gaming, IoT) → Load Balancer
• HTTP/HTTPS web traffic needing URL routing or WAF → Application Gateway

Azure DNS

Azure DNS allows you to host your DNS zones in Azure and manage your DNS records using the same Azure tools, credentials, and billing as your other Azure resources.

Public DNS zones — Host DNS records for internet-facing domains. When you host a domain in Azure DNS, your DNS queries are answered from Azure's global network of DNS servers.

Private DNS zones — Provide DNS resolution within your VNet using private domain names. For example, you can resolve myapp.internal.company.com to a private IP address — only accessible within your VNet.

Azure DNS does not support domain registration — You buy domains from a registrar (like Namecheap or Spaceship) and then host the DNS zone in Azure DNS. Azure DNS only manages DNS records, not domain ownership.

Azure Bastion

Azure Bastion is a fully managed PaaS service that provides secure RDP and SSH access to your VMs directly through the Azure Portal browser — without exposing your VMs to the public internet.

No public IP needed on VMs — Your VMs don't need a public IP address. All access goes through Bastion's public IP, which acts as a secure jump box.

Browser-based access — Connect to any VM in your VNet directly from the Azure Portal. No RDP client, no SSH client, no VPN needed.

Dedicated subnet required — Bastion requires a dedicated subnet named exactly AzureBastionSubnet with a minimum size of /26.

Cost consideration — Bastion is not free. It's charged per hour plus data transfer. For learning, you can use just SSH/RDP with a public IP and NSG rule. Use Bastion for production environments.

Network Watcher

Azure Network Watcher is a suite of monitoring and diagnostic tools for Azure networking. It helps you understand, diagnose, and gain insights into your network in Azure.

IP Flow Verify — Check if a specific packet is allowed or denied to/from a VM. Invaluable for troubleshooting "why can't my VM reach this IP address?"

NSG Flow Logs — Log all traffic flowing through an NSG to Azure Storage. Used for security auditing, compliance, and forensic analysis.

Connection Monitor — Continuously monitor connectivity between Azure resources and external endpoints. Get alerts when connectivity fails or latency increases.

Topology — Generate a visual diagram of your entire network topology in a region — VNets, subnets, VMs, NSGs, and their connections — all in one view.

Real world network architecture

Here's how a typical production web application is architected in Azure using networking components:

        Typical production 3-tier Azure network architecture:

        Internet

            ↓

        Application Gateway + WAF  (Layer 7 load balancing, SSL termination)

            ↓

        Web Subnet (10.0.1.0/24)    (Web servers — NSG allows 80/443 inbound)

            ↓

        Internal Load Balancer      (Distributes to app servers)

            ↓

        App Subnet (10.0.2.0/24)    (App servers — NSG allows only from web subnet)

            ↓

        DB Subnet (10.0.3.0/24)     (Databases — NSG allows only from app subnet)

            ↓

        Bastion Subnet              (Admin access — no public IPs on VMs)

            ↓

        VPN Gateway                 (Connects to on-premises datacenter)

AZ-104 exam tips

✅ Know that VNet Peering is non-transitive — A peers B, B peers C, A cannot reach C
✅ Understand NSG rule priority — lower number = higher priority, processed first
✅ Know that Azure reserves 5 IPs in every subnet (first 4 + last)
✅ Understand Load Balancer (Layer 4) vs Application Gateway (Layer 7)
✅ Remember AzureBastionSubnet must be named exactly this and minimum /26
✅ Know that ExpressRoute is a private connection — not over public internet
✅ Understand Standard vs Basic SKU for Public IP and Load Balancer
✅ Remember Azure DNS cannot register domains — only hosts DNS zones
✅ Know that VNet Peering traffic stays on Microsoft backbone — never public internet
✅ Understand Service tags in NSG rules — Internet, VirtualNetwork, AzureLoadBalancer
✅ Remember GatewaySubnet is required for VPN Gateway deployment