"Networking is the skeleton of your Azure architecture. Everything else — VMs, databases, app services — sits on top of it. Get the network wrong and nothing else works correctly."
The Business Analogy
VNet Fundamentals — What Architects Design
A Virtual Network (VNet) is your isolated private network in Azure. Everything deployed into a VNet gets a private IP address from the address space you define. VNets in different regions or subscriptions are isolated from each other by default — traffic between them requires explicit peering or VPN.
VNET ANATOMY
VNet: 10.0.0.0/16 (65,536 addresses -- your private building)
|
+- Subnet: 10.0.1.0/24 (WebTier -- 256 addresses)
| NSG: Allow HTTPS inbound from Internet
| Allow HTTP inbound from Internet
| Deny all other inbound
|
+- Subnet: 10.0.2.0/24 (AppTier -- 256 addresses)
| NSG: Allow 8080 inbound from WebTier subnet only
| Deny all inbound from Internet
|
+- Subnet: 10.0.3.0/24 (DataTier -- 256 addresses)
NSG: Allow 1433 inbound from AppTier subnet only
Deny ALL other inbound
SUBNETS RESERVED: First 5 IPs in each subnet reserved by Azure
.0 = network address
.1 = default gateway
.2 = DNS (Azure)
.3 = DNS (Azure)
.255 = broadcast
A /24 gives you 251 usable IPs, not 256
Hub-and-Spoke — The Enterprise Network Topology
For enterprises with multiple workloads, the Hub-and-Spoke topology is the standard pattern in Azure. It centralises shared network services in one Hub VNet and connects workload VNets as Spokes.
HUB-AND-SPOKE TOPOLOGY
Internet
|
+--------+--------+
| HUB VNet |
| |
| Azure Firewall | <- All traffic filtered here
| VPN Gateway | <- On-premises connectivity
| Azure Bastion | <- Secure RDP/SSH to all spokes
| Route Tables | <- Force traffic through Firewall
+-+-------------+-+
| VNet Peering | VNet Peering
+-------+---+ +---+-------+
| SPOKE VNet| | SPOKE VNet|
| (Dev) | | (Prod) |
+-----------+ +-----------+
| VNet Peering | VNet Peering
+-----+------+ +------+-----+
| SPOKE VNet | | SPOKE VNet |
| (Shared | | (DMZ) |
| Services) | | |
+------------+ +------------+
IMPORTANT: VNet Peering is NOT transitive.
Dev cannot talk to Prod directly -- traffic must go through Hub.
This is by design -- the Hub Firewall controls all cross-spoke traffic.
Why not just peer all VNets directly? Flat peering creates an N*(N-1)/2 mesh — with 10 workload VNets that is 45 peering connections. Hub-and-Spoke requires 1 peering per spoke. And all cross-spoke traffic passes through the centralised Firewall — one control point for the entire organisation.
NSG Rules — How Traffic Is Filtered
Network Security Groups are stateful firewalls at the subnet or NIC level. Every NSG has default rules you cannot delete — and custom rules you add.
Priority: lower number = higher priority. Rules are evaluated in ascending order. First match wins.
Application Security Groups (ASGs): Instead of writing NSG rules with individual IP addresses (which change when VMs are redeployed), assign VMs to named groups: WebServers, AppServers, DBServers. Write NSG rules using ASG names. When you add a new VM to the WebServers ASG, it automatically inherits all NSG rules targeting that group. No rule changes needed.
Load Balancing — Choosing the Right Tier
Azure has four load balancing services. The wrong choice is a common exam trap. The decision depends on: Layer 4 or Layer 7? Regional or global? HTTP or any protocol?
Private Endpoints vs Service Endpoints — A Critical Distinction
Both allow your VNet resources to communicate with Azure PaaS services. They work very differently. For regulated industries, the distinction is critical.
SERVICE ENDPOINT (older pattern):
App (in VNet) -> traffic leaves subnet -> Azure backbone
-> reaches Storage Account PUBLIC endpoint
The Storage Account still has a public endpoint.
Only VNet identity is allowed -- but the public endpoint still exists.
Your VNet ---------> Azure backbone ------> storage.blob.core.windows.net
PRIVATE ENDPOINT (current pattern):
App (in VNet) -> NIC in your subnet (10.0.2.5) -> Storage Account
The Storage Account now has a PRIVATE IP inside YOUR VNet.
Public endpoint can be DISABLED completely.
DNS: storage.blob.core.windows.net resolves to 10.0.2.5 (private)
Traffic never leaves your VNet.
Your VNet ---------> Private NIC (10.0.2.5) ------> Storage Account
VNet Integration for App Services: App Services are PaaS — they run outside your VNet by default. VNet Integration enables outbound traffic from an App Service to reach resources inside a private VNet (like a SQL Server on a private endpoint). This is about App Service reaching INTO your VNet, not exposing the App Service itself.
Architect Scenario — Bank Application
A bank's application runs on Azure App Service. The application connects to Azure SQL Database. The security team mandates: the SQL database must NEVER be accessible over the public internet, and all traffic between the application and database must stay on private network infrastructure. What is the correct design?
Show Answer + Reasoning
Azure SQL with a Private Endpoint + public access disabled + App Service VNet Integration.
Why not Service Endpoint? Service Endpoints still allow the Azure SQL public endpoint to exist. A misconfiguration or future change could re-enable public access. The security mandate says "NEVER accessible over public internet" — Service Endpoint cannot guarantee this absolutely.
Private Endpoint provides:
- Azure SQL gets a private IP (e.g., 10.0.3.10) inside the VNet
- Public access to Azure SQL can be disabled completely — no public endpoint exists
- DNS: azuresql.database.windows.net resolves to 10.0.3.10 inside the VNet
- Traffic: App Service → VNet Integration → VNet → Private NIC → SQL — entirely private
🎯 Quick Check — Module 3
Q1: When would you choose Azure Front Door over Application Gateway for a web application?
Show Answer
Choose Front Door when the application serves global users and needs: global routing with lowest latency via Anycast, CDN content caching, WAF at global scale, or multi-region active-active failover. Choose Application Gateway when the application is regional — serving users in one Azure region — and needs: URL-based routing, per-path backend pools, SSL termination, or WAF without global CDN. Key differentiator: Front Door = global HTTP; Application Gateway = regional HTTP.
Q2: What is VNet Peering and does it transitively allow Spoke-to-Spoke communication in a Hub-and-Spoke topology?
Show Answer
VNet Peering connects two VNets so resources in each can communicate using private IPs, traversing the Azure backbone. VNet Peering is not transitive. In Hub-and-Spoke: Dev Spoke is peered to Hub, Prod Spoke is peered to Hub — but Dev cannot talk to Prod directly through the Hub. For Spoke-to-Spoke communication, configure User Defined Routes (UDRs) in each Spoke to send cross-spoke traffic to the Hub Firewall IP, which then forwards it. The Firewall becomes the transit point, enabling inspection and control of all cross-spoke traffic.
Q3: A developer reports their App Service cannot reach an Azure SQL Server that has a Private Endpoint inside a VNet. What feature enables the App Service to reach inside the VNet?
Show Answer
VNet Integration for the App Service. App Services run outside VNets by default. VNet Integration connects the App Service's outbound network to a delegated subnet inside your VNet, allowing outbound connections to private resources — including resources accessed via Private Endpoints. Note: VNet Integration is outbound only. For inbound private access to the App Service itself, you would use a Private Endpoint on the App Service — a different feature.
Key Takeaways — Module 3
- Design subnets by workload tier (Web/App/Data) — each with its own NSG enforcing least-privilege traffic flow
- Hub-and-Spoke: centralise Firewall, VPN Gateway, and Bastion in Hub; VNet Peering is NOT transitive — all cross-spoke traffic routes through Hub Firewall
- NSG priority: lower number wins — first match terminates evaluation
- Load balancer tier: Azure LB (L4 regional), Application Gateway (L7 regional + WAF), Front Door (L7 global + CDN + WAF), Traffic Manager (DNS global)
- Private Endpoint puts PaaS service INSIDE your VNet with a private IP — public endpoint can be disabled; Service Endpoint does not provide this guarantee
- VNet Integration enables App Service outbound traffic to reach private VNet resources