Design Network Solutions — Lesson

This lesson integrates all five networking learning objectives tested in the AZ-305 exam: designing connectivity to the internet (LO45), on-premises connectivity (LO46), network performance optimizations (LO47), network security (LO48), and load-balancing strategies (LO49). Together, these form the backbone of every Azure architecture — a misconfigured network undermines every other design decision you make, no matter how elegant the compute or data layer. Reference: Ch. 4, §4.4, p. 165–175 of the AZ-305 exam book.

Why This Matters

Every Azure workload — from a single App Service to a multi-region Kubernetes fleet — sits on a virtual network. The AZ-305 exam expects you to design connectivity that is secure by default, performant under load, and cost-efficient across regions. In real projects, network design is the first decision that locks in constraints for everything else: an ExpressRoute circuit takes weeks to provision; a missing Private Endpoint can leave a storage account exposed to the public internet; choosing the wrong load-balancer tier can add hundreds of milliseconds of latency. Mastering these five LOs means you can walk into a whiteboard session, draw the topology, and defend every arrow.

Prerequisites

• TCP/IP fundamentals — Can you explain what happens at layers 3, 4, and 7 of the OSI model when a browser requests a web page?
• Azure VNet basics — Can you create a VNet with two subnets and explain the default routing behaviour?
• DNS resolution — Can you describe how a client resolves app.contoso.com to an IP address and why TTL matters?
• Public-key cryptography — Can you explain how TLS terminates a connection and why a certificate is needed?
• Azure RBAC and resource groups — Can you assign a Network Contributor role scoped to a resource group?

Learning Objectives

By the end of this lesson you will be able to:

1. Design an internet-connectivity architecture that balances public exposure against security using NAT Gateway, Azure Front Door, and Azure Bastion.
2. Evaluate hybrid-connectivity options — VPN Gateway, ExpressRoute, and Virtual WAN — and recommend the right one for a given latency, bandwidth, and compliance requirement.
3. Recommend performance optimizations including Accelerated Networking, VNet Peering, Private Link, and Service Endpoints for a multi-region topology.
4. Design a network-security posture using NSG, ASG, Azure Firewall, DDoS Protection, and WAF that follows the principle of least privilege.
5. Select the correct load-balancing service — Azure Load Balancer, Application Gateway, Traffic Manager, or Front Door — for a given traffic pattern and SLA.

Building Blocks

Virtual Network (VNet) — Analogy: Think of a VNet as a private office building where you control every hallway and locked door. Formal definition: A logically isolated network in Azure, scoped to a single region, with one or more address spaces (CIDR blocks). Why it matters: Every VM, App Service Environment, and most PaaS services that need private connectivity must attach to a VNet.

Subnet — Analogy: A floor in the office building — each floor can have its own security desk (NSG). Formal definition: A range carved from the VNet's address space; resources deployed into a subnet share its route table and NSG. Why it matters: Subnet design determines blast-radius isolation and how NSG rules are applied.

Network Security Group (NSG) — Analogy: A bouncer with a clipboard of allow/deny rules at each door. Formal definition: A stateful packet-filter applied to a subnet or NIC that evaluates rules by priority (lowest number = highest priority). Why it matters: NSGs are the first and most granular layer of network access control in Azure.

User-Defined Route (UDR) — Analogy: A custom detour sign you place in the hallway to redirect traffic through a checkpoint. Formal definition: A route-table entry that overrides Azure's default system routes, commonly used to force traffic through Azure Firewall or a network virtual appliance. Why it matters: Without UDRs, traffic between subnets flows directly — bypassing any central inspection.

Private Endpoint — Analogy: A private entrance built into your office that connects directly to a supplier's warehouse — no public street required. Formal definition: A NIC in your VNet that maps to a specific PaaS resource instance (e.g., a particular storage account), using Azure Private Link. Why it matters: It removes the PaaS resource's public endpoint from the data path, eliminating internet exposure.

ExpressRoute — Analogy: A dedicated highway between your on-premises data centre and Azure — no sharing with public internet traffic. Formal definition: A private, high-bandwidth connection (50 Mbps to 100 Gbps) established through a connectivity provider, offering predictable latency and optional encryption. Why it matters: Compliance-heavy workloads often mandate that data never traverse the public internet.

Deep Dive

LO45 — Internet Connectivity

Designing internet connectivity means deciding how traffic enters and exits your Azure VNets.

Outbound: NAT Gateway vs. default SNAT. By default, VMs with no public IP use Azure's default SNAT, which shares a pool of ephemeral IPs and risks port exhaustion under load. NAT Gateway provides a dedicated, zone-redundant outbound path with up to 16 public IPs ($64,000 SNAT ports each), giving you a deterministic source-IP for firewall allow-listing.

Inbound: Azure Front Door, Application Gateway, or Public IP. For web workloads, Azure Front Door (global, anycast, layer-7) terminates TLS at the edge and routes to the closest healthy backend. Application Gateway (regional, layer-7) is the right choice when you need WAF + URL-based routing within a single region. A plain public IP on a VM is almost never the answer for production.

Secure management: Azure Bastion. Instead of exposing RDP/SSH ports to the internet, Azure Bastion provides browser-based access over TLS. The Standard SKU adds features such as native-client support, IP-based connection, and shareable links.

[!TIP] Pair NAT Gateway with Azure Firewall when you need both deterministic outbound IPs and FQDN-based egress filtering. The firewall applies rules; the NAT Gateway provides the public IPs.

LO46 — On-Premises Connectivity

Hybrid connectivity is about extending the on-premises network into Azure with the right trade-off between cost, bandwidth, latency, and privacy.

VPN Gateway uses IPsec/IKEv2 tunnels over the public internet. The VpnGw2AZ SKU supports up to $1.25 Gbps throughput and availability-zone deployment. Active-active mode with two tunnels provides 99.99% SLA (vs. 99.95% for single-instance).

ExpressRoute provides a private connection through a peering provider. Three peering types exist: Azure Private Peering (VNets), Microsoft Peering (Microsoft 365 and Dynamics 365), and the deprecated Azure Public Peering. The ExpressRoute Premium add-on unlocks cross-region VNet linking and increases route limits from $4,000 to $10,000.

Virtual WAN is Microsoft's managed hub-and-spoke service that simplifies multi-site, multi-region connectivity. A Standard Virtual WAN hub can aggregate VPN, ExpressRoute, and point-to-site connections into a single managed router with transit between all spokes.

[!WARNING] ExpressRoute circuits are not encrypted by default. If regulatory requirements demand encryption in transit over a private link, enable MACsec (ExpressRoute Direct) or layer an IPsec VPN tunnel on top of the ExpressRoute private peering.

LO47 — Network Performance

Accelerated Networking bypasses the host's software virtual switch (SR-IOV), reducing latency to under 25 microseconds and increasing throughput to up to 30 Gbps on supported VM sizes. It is free but must be enabled at NIC creation time.

VNet Peering connects two VNets with Microsoft-backbone bandwidth — no gateway, no internet hop. Global VNet Peering crosses regions but incurs inter-region data-transfer charges. Peering is non-transitive: if VNet A peers with VNet B, and VNet B peers with VNet C, A cannot reach C unless you also peer A↔C or route through a hub.

Private Link / Private Endpoint pulls PaaS traffic onto the Microsoft backbone and into your VNet's address space, eliminating the public-internet hop. Traffic to a Private Endpoint stays on the Azure backbone even when the client is in a different region.

Service Endpoint routes traffic from a subnet to the PaaS service over the Azure backbone but keeps the service's public IP. The PaaS resource can then restrict access to only the subnets that have the service endpoint enabled. Unlike Private Endpoint, the PaaS public endpoint remains reachable.

[!IMPORTANT] When you create a Private Endpoint for a PaaS resource, you almost always need a Private DNS Zone (e.g., privatelink.blob.core.windows.net) linked to your VNet so that the FQDN resolves to the private IP. Without this, clients will resolve the public IP and bypass the Private Endpoint.

LO48 — Network Security

Network security in Azure is a layered stack — the exam tests your ability to pick the right layer for a given requirement.

NSG — Stateful L3/L4 filter attached to a subnet or NIC. Rules reference IP ranges, ports, and protocols. Best practice: attach NSGs at the subnet level for broad policy and at the NIC level only for exceptions.

Application Security Group (ASG) — A logical grouping of NICs so you can write NSG rules like "allow web-tier ASG to talk to app-tier ASG on port 8080" without managing IP addresses.

Azure Firewall — A managed, stateful, centrally deployed firewall (L3–L7). The Premium SKU adds TLS inspection, IDPS, URL filtering, and web categories. Deploy in the hub VNet and force-tunnel spoke traffic through it via UDRs.

DDoS Protection — The Network tier (formerly Standard) provides per-public-IP, always-on detection and automatic mitigation with cost protection (credits for scale-out triggered by an attack). The IP tier protects a single public IP at lower cost.

Web Application Firewall (WAF) — Deployed on Application Gateway, Front Door, or Azure Front Door Standard. The OWASP $3.2 managed rule set catches the top-10 web vulnerabilities (SQLi, XSS, etc.). Custom rules let you block by geo, IP, or request body.

LO49 — Load Balancing

Azure has four load-balancing services. The decision tree depends on two axes: global vs. regional and HTTP(S) vs. non-HTTP.

Azure Load Balancer — Regional, layer-4 (TCP/UDP). The Standard SKU is zone-redundant and supports HA ports (all protocols, all ports on a single rule). Use for internal-tier traffic or non-HTTP protocols such as SQL, SMTP, or custom TCP.

Application Gateway — Regional, layer-7 (HTTP/HTTPS). Supports URL-based routing, cookie-based session affinity, SSL offload, and built-in WAF (v2 SKU). Use when you need content-based routing within a single region.

Azure Front Door — Global, layer-7. Anycast ingress across $190+$ edge locations, built-in WAF, SSL offload, and intelligent routing (latency, priority, weighted). Use for global web applications where you want the fastest path to the nearest healthy backend.

Traffic Manager — Global, DNS-based. Returns the IP of the best endpoint at DNS resolution time. Supports performance, priority, weighted, geographic, multivalue, and subnet routing methods. Because it works at DNS, it handles any protocol — not just HTTP. Use for non-HTTP global load balancing or as a secondary layer atop regional load balancers.

[!NOTE] A common architecture combines Traffic Manager (DNS-level global failover) with Application Gateway (regional L7 routing + WAF) in each region. Front Door replaces both when the workload is HTTP-only and you want edge-terminated TLS.

Worked Examples

Easy — Single-region web app with secure admin access

Scenario. Contoso is deploying a public-facing ASP.NET application on VMs in a single region. Admins need to manage the VMs without exposing RDP to the internet. Outbound traffic must use a known IP for a third-party API allow-list.

Solution.

1. Deploy an Application Gateway v2 with WAF in a dedicated AppGwSubnet. Configure a public frontend IP; backend pool targets the VM NICs.
2. Deploy Azure Bastion (Standard SKU) in an AzureBastionSubnet for browser-based RDP.
3. Attach a NAT Gateway with a single static public IP to the VM subnet so all outbound traffic uses a deterministic IP.
4. Create NSG rules: allow ports 80/443 from the Application Gateway subnet to the VM subnet; deny all other inbound from the internet.

[!NOTE] Key insight: Application Gateway requires its own /24 (or smaller) subnet with no other resources. Bastion similarly requires a subnet named exactly AzureBastionSubnet.

Medium — Hybrid connectivity with high availability

Scenario. Fabrikam's on-premises ERP pushes 800 Mbps of traffic to Azure SQL Managed Instance. Compliance requires data to never traverse the public internet. The architect must achieve 99.99% uptime on the connection.

Solution.

1. Provision an ExpressRoute circuit with a 1 Gbps Premium SKU through a peering provider in the same metro as the on-premises data centre.
2. Enable ExpressRoute Azure Private Peering to reach VNets.
3. For 99.99% SLA, deploy two circuits in different peering locations, or use a single circuit with a VPN Gateway in active-active mode as a backup path (sometimes called ExpressRoute with VPN failover).
4. Place Azure SQL Managed Instance in a delegated subnet inside the VNet connected to the ExpressRoute gateway.
5. Validate that the on-premises route table advertises the correct prefixes and that the AS path prefers the primary circuit.

[!NOTE] Key insight: A single ExpressRoute circuit offers 99.95% SLA. To reach 99.99%, Microsoft recommends redundant circuits in two distinct peering locations — not just two connections from the same location.

Hard — Global multi-region architecture with zero-trust

Scenario. Woodgrove Bank runs a banking portal in East US and West Europe. Requirements: sub-100-ms latency for users worldwide, WAF protection against OWASP top 10, east-west traffic inspection between tiers, all PaaS services accessed over private networks, and DDoS protection.

Solution.

1. Global ingress: Azure Front Door Premium with WAF (managed OWASP $3.2 rule set + custom geo-block rules). Front Door's anycast terminates TLS at the nearest edge POP and routes to the closest healthy backend.
2. Regional load balancing: In each region, an internal Application Gateway v2 (private frontend) receives traffic from Front Door's Private Link origin.
3. East-west inspection: Azure Firewall Premium deployed in a hub VNet per region. Spoke VNets (web tier, app tier, data tier) route all inter-subnet traffic through the firewall via UDRs. TLS inspection enabled for east-west flows.
4. PaaS isolation: Private Endpoints for Azure SQL, Storage, and Key Vault in each region. Private DNS Zones linked to hub and spoke VNets. Public network access disabled on every PaaS resource.
5. DDoS: DDoS Protection Network tier enabled on the VNet containing public IPs (Front Door handles most volumetric attacks at the edge, but the DDoS plan covers any residual public IPs on the Application Gateways or other services).
6. Cross-region connectivity: Global VNet Peering between the two hub VNets for DR replication traffic, with NSG rules limiting to the replication port range.

[!NOTE] Key insight: Front Door Premium supports Private Link origins, meaning the backend Application Gateways do not need public IPs. This eliminates a significant attack surface.

Visual Explanations

1. Load-Balancer Decision Tree (Mermaid)

Caption: Start with the protocol, then the scope. This two-axis decision tree is the fastest way to choose the right Azure load balancer on exam day.

2. Hub-and-Spoke Topology with Firewall (TikZ)

Caption: Traffic from on-premises enters through the VPN/ExpressRoute gateway in the hub, flows through Azure Firewall, and reaches spoke VNets via user-defined routes.

3. Hybrid Connectivity Comparison Table

4. Private Endpoint vs. Service Endpoint Flow (Mermaid)

Caption: With a Private Endpoint, the VM reaches the storage account via a private IP inside the VNet. The storage account's public endpoint is never used.

Caption: With a Service Endpoint, traffic still targets the public IP but is routed over the Azure backbone. The storage account firewall restricts access to the VNet's subnet.

5. Network Security Layering (TikZ)

Caption: Azure network security is a defence-in-depth stack. Each layer stops a different class of attack — deploy all five for a zero-trust posture.

6. Azure Load Balancer Comparison

Common Mistakes

❌ Myth: "Service Endpoints and Private Endpoints do the same thing — just pick the cheaper one." ✅ Reality: Service Endpoints keep the public IP and can only be used from within the VNet; Private Endpoints assign a private IP and are reachable from on-premises via VPN/ExpressRoute. If your on-premises clients need to reach the PaaS resource privately, only Private Endpoints work. Why it's tricky: Both improve security over a raw public endpoint, so candidates conflate them. The on-premises reachability difference is the exam's favourite distractor.

❌ Myth: "ExpressRoute is encrypted by default because it's a private connection." ✅ Reality: ExpressRoute is private (not routed over the public internet) but is not encrypted unless you add MACsec (ExpressRoute Direct) or tunnel IPsec over the circuit. Why it's tricky: "Private" and "encrypted" feel like synonyms, but in networking they are distinct properties. The exam specifically tests this distinction.

❌ Myth: "Azure Front Door and Traffic Manager are interchangeable for global HTTP load balancing." ✅ Reality: Front Door operates at layer 7 with anycast, terminates TLS at the edge, and supports WAF. Traffic Manager operates at DNS layer, never sees the actual HTTP traffic, and cannot terminate TLS or apply WAF rules. For HTTP workloads, Front Door is almost always superior; Traffic Manager shines for non-HTTP protocols. Why it's tricky: Both are "global" and both route traffic to the best endpoint, so the distinction collapses if you forget the layer they operate at.

❌ Myth: "VNet peering is transitive — if A peers with B, and B peers with C, A can talk to C." ✅ Reality: VNet peering is non-transitive. You must either peer A↔C directly or route through a hub (Azure Firewall or NVA in VNet B) with UDRs. Virtual WAN automates transit, which is one of its key value propositions. Why it's tricky: Peering feels like connecting a wire, and wires are transitive. Azure's implementation is not.

Practice Exercises

🟢 Easy — Choose the outbound service. Contoso's VMs need a static, predictable outbound IP for a third-party allow-list. They do not need egress FQDN filtering. Which service provides the simplest solution?

▶💡 Hint

Look for the service that provides deterministic outbound IPs without full L7 inspection.

▶✅ Solution

NAT Gateway with a static public IP. Azure Firewall could also provide a deterministic IP, but the requirement explicitly excludes FQDN filtering, making NAT Gateway the simpler (and cheaper) choice.

🟢 Easy — NSG vs. Azure Firewall. Fabrikam wants to block all inbound SSH except from a single management subnet. Which is the most appropriate service?

▶💡 Hint

Is this a per-subnet rule or a centralised policy?

▶✅ Solution

An NSG rule on the target subnet: deny inbound TCP/22 from all sources, then allow inbound TCP/22 from the management subnet CIDR (lower priority number = higher priority, so the allow rule wins). Azure Firewall is overkill for a simple L4 rule scoped to one subnet.

🟡 Medium — Hybrid connectivity selection. Woodgrove Bank must connect their on-premises trading floor to Azure with sub-10-ms latency and 5 Gbps bandwidth. Regulatory policy forbids data traversing the public internet. Which connectivity option should the architect recommend?

▶💡 Hint

Which option guarantees private transport and supports multi-Gbps bandwidth?

▶✅ Solution

ExpressRoute with a 10 Gbps circuit. VPN Gateway maxes out at 10 Gbps but traverses the public internet, violating the compliance requirement. ExpressRoute provides both the bandwidth and privacy needed.

🟡 Medium — Private Endpoint vs. Service Endpoint. Adatum Corp has VMs in Azure and an on-premises application server connected via ExpressRoute. Both need to access an Azure Storage account without using the public endpoint. Which approach should the architect recommend?

▶💡 Hint

On-premises clients cannot use Service Endpoints. Think about which option provides a private IP reachable over ExpressRoute.

▶✅ Solution

Private Endpoint. Service Endpoints only work for resources within the VNet — on-premises clients connected via ExpressRoute cannot use them. A Private Endpoint creates a private IP in the VNet that is reachable from on-premises through the ExpressRoute private peering. Configure a Private DNS Zone so both Azure VMs and on-premises DNS resolve the storage FQDN to the private IP.

🔴 Hard — Multi-region zero-trust design. Contoso runs a global e-commerce platform in three regions. Requirements: OWASP WAF protection, sub-100-ms latency worldwide, east-west traffic inspection, all PaaS services private, 99.99% availability on the frontend. Design the networking layer.

▶💡 Hint

Global L7 load balancing with WAF at the edge + regional hub-and-spoke with centralised firewall + Private Endpoints for PaaS.

▶✅ Solution

1. Azure Front Door Premium (anycast, WAF, 99.99% SLA) for global ingress. Private Link origins connect to internal Application Gateways in each region.
2. Hub-and-spoke per region: Azure Firewall Premium in the hub for east-west and egress inspection with TLS inspection enabled.
3. Private Endpoints + Private DNS Zones for Azure SQL, Storage, Key Vault, and any other PaaS service in each region.
4. DDoS Protection Network tier on VNets with any residual public IPs.
5. Global VNet Peering between hub VNets for cross-region replication, with NSG rules scoping traffic to replication ports only. This layered design satisfies zero-trust (no implicit trust between tiers), global performance (anycast edge), and compliance (all PaaS private).

🔴 Hard — Failover and SLA calculation. Fabrikam uses a single ExpressRoute circuit (99.95% SLA) connecting their primary data centre to Azure. The CTO demands 99.99% connectivity SLA. What changes must the architect make, and what is the composite SLA of the recommended design?

▶💡 Hint

One circuit in one peering location cannot exceed 99.95%. Think about redundancy at the peering-location level.

▶✅ Solution

Deploy two ExpressRoute circuits in different peering locations (e.g., Equinix Washington DC and Megaport Dallas). Each circuit independently offers 99.95%. The probability of both failing simultaneously is $(1 - 0.9995)^2 = 0.00000025$, yielding a composite SLA of $\approx 99.99997\%$ — well above 99.99%. As a belt-and-suspenders measure, add a VPN Gateway in active-active mode as a third failover path. The VPN's SLA (99.99% in active-active) further reduces single-point-of-failure risk.

Summary & Concept Map

• Internet connectivity comes down to three decisions: outbound IP strategy (NAT Gateway), inbound traffic entry point (Front Door / Application Gateway), and secure management plane (Bastion).
• On-premises connectivity is a trade-off triangle: cost (VPN), privacy + bandwidth (ExpressRoute), and managed simplicity (Virtual WAN). Combine them for resilience.
• Performance gains come from removing hops: Accelerated Networking at the NIC, VNet Peering between VNets, and Private Endpoints for PaaS — each eliminates an unnecessary detour.
• Security is defence in depth: NSG/ASG at the subnet, Azure Firewall at the hub, WAF at the edge, DDoS Protection over public IPs, and Private Endpoints to shrink the attack surface.
• Load balancing follows a two-axis grid: layer (L4 vs. L7 vs. DNS) and scope (regional vs. global). Pick the intersection that matches your protocol and geography.
• For the exam, practice the decision trees — the questions test whether you can pick the right tool for a set of constraints, not whether you can configure every field.

Connections & Next Steps

This topic's five LOs should be studied in the following order for the most logical progression:

1. LO45 — Internet Connectivity — Establishes how traffic enters and exits Azure. See the LO-level lesson for deep coverage of NAT Gateway, Front Door, and Bastion.
2. LO46 — On-Premises Connectivity — Extends the network to hybrid. See the LO-level lesson for ExpressRoute circuit design and VPN failover patterns.
3. LO47 — Network Performance — Optimises the paths you built in LO45–46. See the LO-level lesson for Private Link DNS integration and peering topologies.
4. LO48 — Network Security — Locks down every path. See the LO-level lesson for Azure Firewall rule-collection hierarchies and DDoS tier comparison.
5. LO49 — Load Balancing — Distributes traffic across the secured paths. See the LO-level lesson for composite SLA calculations and multi-tier LB architectures.

After mastering this topic, circle back to Unit 4, Topic 3 (Compute) — many networking decisions (load-balancer choice, subnet sizing) depend on the compute model (VMs vs. AKS vs. App Service), and vice versa. The Unit 4 lesson provides the overarching integration across all infrastructure topics.