Azure Networking Fundamentals
Virtual Network (VNet)An isolated, software-defined network environment in Azure. Resources within a VNet communicate securely via private IP addresses. Supports subnets for logical segmentation, peering for cross-VNet connectivity, and service endpoints/private endpoints for Azure service access. VNets do not span regions — each region has its own VNet.VNet PeeringDirect, low-latency connectivity between two VNets using Microsoft backbone (no internet traversal). Intra-region peering is free for ingress; cross-region (global peering) has egress charges. Foundation of hub-and-spoke topology — spoke VNets peer to hub for shared services access.Azure VPN GatewayA managed VPN endpoint for encrypted hybrid connectivity. Site-to-site VPN: connects on-premises networks via IPsec/IKE tunnel. Point-to-site VPN: individual clients to Azure. Throughput: 100 Mbps to 10 Gbps depending on SKU. Requires GatewaySubnet (/27 minimum).Azure ExpressRouteA dedicated private connection to Azure via a connectivity provider or direct partner edge location. No internet traversal — traffic goes over provider's MPLS network. Bandwidth: 50 Mbps to 100 Gbps. Provides consistent throughput and low latency. Required for mission-critical, high-bandwidth hybrid connectivity.Private EndpointA network interface with a private IP from your VNet that connects to a specific Azure PaaS service instance (SQL Database, Storage, Key Vault, etc.). Traffic flows entirely within the private network — the service is accessible without internet exposure. Replaces service endpoints for the highest security requirement.Azure FirewallA managed, cloud-native Layer 3–7 firewall with threat intelligence, FQDN filtering, intrusion detection, and application rules. Deployed in the hub VNet of a hub-and-spoke topology to centralize egress traffic filtering. Supports forced tunneling and integration with Azure Monitor for logs.Hybrid Connectivity Comparison
| Dimension | VPN Gateway | ExpressRoute |
|---|---|---|
| Bandwidth | 100 Mbps–10 Gbps | 50 Mbps–100 Gbps |
| Latency | Variable (internet path) | Consistent, low (private circuit) |
| Reliability | Internet-dependent | Dedicated SLA from provider |
| Cost | Low | High |
| Setup Time | Days | Weeks to months |
| Best For | Branch offices, dev/test, backup | Mission-critical, high bandwidth |
Recommended enterprise pattern: ExpressRoute as primary + VPN Gateway as backup for failover.
Network Architecture Patterns
Hub-and-Spoke Topology
Hub VNet contains shared services:
- Azure Firewall (centralized egress filtering and inspection)
- VPN/ExpressRoute Gateway (hybrid connectivity)
- Azure Bastion (secure VM administration without public IP)
- Azure Monitor (centralized log collection)
Spoke VNets contain workloads:
- Application-specific resources in isolated VNets
- NSGs for local segmentation
- Private endpoints for PaaS service access
- Route tables (UDR) to force traffic through hub firewall
Defense-in-Depth Network Layers
| Layer | Control | Tool |
|---|---|---|
| Edge / Global | WAF, DDoS, CDN filtering | Azure Front Door, Application Gateway WAF |
| Network perimeter | Firewall, FQDN filtering | Azure Firewall |
| Subnet | Stateful packet filtering | Network Security Groups (NSG) |
| VM/NIC | Per-NIC filtering | NSG at NIC level |
| Service | Private network only | Private Endpoints |
| Application | Input validation, auth | Application-level controls |
NSG Rule Design
NSG rules are processed in priority order (lower number = higher priority). Rules are stateful — return traffic is automatically allowed.
Best practice pattern:
Inbound:
- Priority 100: Allow HTTPS (443) from Internet
- Priority 200: Allow HTTP (80) from Internet (or redirect to HTTPS)
- Priority 300: Allow management ports (443, 22) from corporate IPs only
- Priority 4096: Deny all (implicit, always last)
Outbound:
- Priority 100: Allow HTTPS to Internet (or restrict to specific FQDNs via Azure Firewall)
- Priority 4096: Deny all (or allow all — depends on security posture)
Service tags simplify rules: Internet, AzureLoadBalancer, VirtualNetwork, AzureMonitor — avoid hardcoding IP ranges that change.
Private Endpoint vs. Service Endpoint
| Feature | Service Endpoint | Private Endpoint |
|---|---|---|
| Traffic path | Optimized route, still over Azure backbone | Private IP in your VNet |
| Service accessible from internet | Yes (unless firewall) | No (only via private IP) |
| DNS resolution | Public FQDN | Private DNS zone required |
| Compliance level | Moderate | Highest (zero public exposure) |
| Cost | Free | Per-endpoint charge |
For scenarios requiring maximum isolation (compliance, highly sensitive data) — always use Private Endpoints.
Hands-On: Configure Hub-and-Spoke Network
Step 1: Create Hub VNet
- Navigate to Virtual networks > Create
- Name:
hub-vnet, Address space:10.0.0.0/16 - Create subnets:
AzureFirewallSubnet:10.0.1.0/24(required name for Azure Firewall)GatewaySubnet:10.0.2.0/27(required for VPN/ER Gateway)AzureBastionSubnet:10.0.3.0/26(required for Azure Bastion)
- Review and create
Step 2: Create Spoke VNets and Peer to Hub
- Create spoke VNet:
spoke-aks-vnet, Address space:10.1.0.0/16 - Create subnet:
aks-subnet,10.1.1.0/24 - Navigate to hub VNet > Peerings > Add
- Configure bidirectional peering:
- Peering name:
hub-to-spoke-aks - Remote VNet:
spoke-aks-vnet - Enable: Allow gateway transit (hub) and Use remote gateway (spoke)
- Peering name:
- Repeat for each spoke VNet
Step 3: Deploy Azure Firewall in Hub
- Navigate to Azure Firewalls > Create
- VNet: Select
hub-vnet, Subnet:AzureFirewallSubnet - Tier: Standard or Premium (IDPS requires Premium)
- After creation, note the private IP (e.g.,
10.0.1.4) - Create Firewall Policy > add Application rules:
- Allow HTTPS to
*.microsoft.com,*.azure.com - Allow specific FQDNs for workload requirements
- Allow HTTPS to
Step 4: Configure Route Table for Spoke Traffic
- Navigate to Route tables > Create
- Name:
spoke-aks-rt, disable BGP route propagation - Add route: Address prefix
0.0.0.0/0, Next hop: Virtual appliance, IP:10.0.1.4(firewall IP) - Associate route table with
aks-subnet - All outbound traffic from spoke now routes through Azure Firewall
Step 5: Configure Private Endpoint for Azure SQL Database
- Navigate to Azure SQL Database > Networking > Private endpoint connections
- Click Add private endpoint
- Configure:
- VNet:
spoke-aks-vnet, Subnet:aks-subnet - Target sub-resource:
sqlServer
- VNet:
- Enable Private DNS integration: Creates
privatelink.database.windows.netDNS zone - Disable public access on SQL Database: Networking > Public access: Disabled
- SQL Database now accessible only from within the VNet via private IP
Step 6: Configure Network Security Group
- Navigate to Network security groups > Create
- Associate with
aks-subnet - Add inbound rules:
- Priority 100: Allow HTTPS (443) from AzureLoadBalancer service tag
- Priority 200: Allow AKS internal communication (port 443, 10250) from VirtualNetwork
- Priority 4096: Deny all inbound (implicit)
- Add outbound rules per workload requirements
AZ-305 Exam Focus
AZ-305 network questions test your ability to select the right connectivity option (VPN vs. ExpressRoute), topology (hub-and-spoke vs. flat), and security control (NSG vs. Azure Firewall vs. WAF vs. private endpoint) for a given scenario.
Exam Trap
VPN as Primary Hybrid Connectivity for Mission-Critical: VPN Gateway traverses the public internet — latency varies and reliability depends on internet path quality. For mission-critical workloads with consistent throughput and low latency requirements, ExpressRoute is required. VPN is appropriate for branch offices, dev/test, and as an ExpressRoute backup.
Exam Trap
Service Endpoints Provide Complete Isolation: Service endpoints optimize the network path to Azure services but the service can still have a public endpoint accessible from the internet. Private Endpoints create a private IP in your VNet for the service — the service can be completely disabled for public internet access. Use Private Endpoints for maximum isolation.
Exam Trap
NSG as a Complete Firewall: NSGs are stateful packet filters (Layer 3/4) — they filter by IP, port, and protocol but cannot inspect URLs, FQDNs, or application content. Azure Firewall provides Layer 7 filtering including FQDN rules, TLS inspection, and threat intelligence. Use NSGs for subnet segmentation; use Azure Firewall for centralized application-level filtering.
Exam Trap
Hub-Spoke Peering is Transitive: VNet peering is NOT transitive. Spoke A peered to Hub does NOT automatically communicate with Spoke B peered to Hub. For spoke-to-spoke communication, either peer spokes directly to each other, or route traffic through the hub Azure Firewall (recommended for inspection and logging).
Exam Tip
Azure Bastion for Admin Access: When scenarios involve secure VM administration without public IP addresses or VPN/RDP exposure to the internet — Azure Bastion is the answer. It provides browser-based RDP/SSH through the Azure portal over SSL, requiring only an Azure AD identity, with no VM public IP required.
Must Memorize
Private Endpoint DNS: Private Endpoints require a corresponding Private DNS Zone (e.g., privatelink.database.windows.net) linked to the VNet. Without the DNS zone, applications resolve the service FQDN to the public IP instead of the private endpoint IP. Always pair Private Endpoint creation with Private DNS Zone configuration.
Question — click to flip
Q: What is the difference between VPN Gateway and ExpressRoute for hybrid connectivity?
Question — click to flip
Q: What is the hub-and-spoke network topology and what goes in the hub?
Question — click to flip
Q: What is the difference between a Service Endpoint and a Private Endpoint for Azure PaaS services?
Question — click to flip
Q: When is Azure Firewall needed vs. Network Security Groups alone?
Question — click to flip
Q: Can VNet Peering be used for transitive routing between spoke VNets?
Question — click to flip
Q: What subnet name does Azure Firewall require, and what size is recommended?