AZ-104 · Configure & Manage Virtual Networks Concept map + module map for the networking path.

3-networking-moc

Configure & Manage Virtual Networks — MOC

MS Learn path: Configure and manage virtual networks for Azure administrators · Largest skill area on the AZ-104 exam.

Map / Canvas

The core idea

Virtual networks are Azure’s software-defined networking. You design IP space (CIDR), segment it into subnets, connect VNets to each other (vnet-peering) and to on-premises (vpn-gateway/expressroute), secure traffic (nsg/asg/azure-firewall), route it (route-table/bgp), resolve names (azure-dns/private-dns), and balance load (load-balancer/application-gateway/traffic-manager). One network, many layers — this MOC ties them together.

Concepts (linked from here)

Core topology

Connectivity

Security

Name resolution

Load balancing & traffic

Modules in this path

Hybrid connectivity is covered conceptually here via vpn-gateway and expressroute (no dedicated module in this path; see the associated hybrid-networking learn path).

Skills measured (exam blueprint)

  1. Configure and manage virtual networks
  2. Configure and manage virtual network peering
  3. Configure and manage virtual network routing & DNS
  4. Configure and manage network security
  5. Configure and manage Azure load balancing / traffic

Practice questions

configure-virtual-networks

Module 1 · Configure Virtual Networks

MS Learn: Configure Virtual Networks · learn.wwl.configure-virtual-networks Module note for Path MOC

Overview

This is the foundation module of the networking path. It covers designing and implementing the IP address space (CIDR/IP addressing) and creating a Virtual Network segmented into subnet, then assigning IP addresses to resources. Everything else in the path (peering, routing, security, DNS) builds on these core objects.

Learning objectives (from Microsoft Learn)

In this module, you learn how to:

  • Describe Azure virtual network features and components.
  • Identify features and use cases for subnets and subnetting.
  • Identify use cases for private and public IP addresses.
  • Create a virtual network and assign IP addresses.

Units

  1. Introduction
  2. Plan virtual networks
  3. Create subnets
  4. Create a virtual network
  5. Plan IP addressing
  6. Create public IP addressing
  7. Associate public IP addresses
  8. Associate private IP addresses
  9. Lab: Configure and design Azure Virtual Networks
  10. Knowledge check
  11. Summary and resources

Concepts introduced

Key terms & commands (Azure CLI)

# Plan: private range (e.g. 10.0.0.0/16), subnets within it
az vnet create -g <rg> -n <vnet> --address-prefixes 10.0.0.0/16     --subnet-name snet-frontend --subnet-prefixes 10.0.1.0/24
az vnet subnet create -g <rg> --vnet-name <vnet> -n snet-app     --address-prefixes 10.0.2.0/24
az network public-ip create -g <rg> -n <pip> --allocation-method static     --sku Standard

Hands-on

  • Create a VNet + subnets in the portal and confirm reserved addresses.
  • Assign a static public IP and note private vs public address widths for a VM NIC.

Exam focus

  • VNet is regional; subnets must lie within and not overlap.
  • Reserved addresses in each subnet (~5 per subnet).
  • Private RFC1918 vs public IP; dynamic vs static allocation.
  • One NIC = one private IP; NIC in one subnet/VNet.

Path MOC · vnet · subnet · cidr-ip-addressing · configure-vnet-peering · control-network-traffic-flow-with-routes

configure-vnet-peering

Module 2 · Configure Virtual Network Peering

MS Learn: Configure Azure Virtual Network Peering · learn.wwl.configure-vnet-peering Module note for Path MOC

Overview

Connect separate VNets so they can talk to each other with near-LAN performance via the Microsoft backbone. The module covers when to peer, how to enable gateway transit, and how to do hub-and-spoke / service chaining with UDRs.

Learning objectives (from Microsoft Learn)

In this module, you learn how to:

  • Identify usage cases and product features of Azure Virtual Network peering.
  • Configure your network to implement Azure VPN Gateway for transit connectivity.
  • Extend peering by using a hub and spoke network with user-defined routes and service chaining.

Units

  1. Introduction
  2. Determine Azure Virtual Network peering use cases
  3. Determine gateway transit connectivity
  4. Create peering
  5. Determine service-chaining use cases
  6. Interactive lab: Configure VNet peering
  7. Knowledge check
  8. Summary and resources

Concepts introduced

Key terms & commands (Azure CLI)

az network vnet peering create -g <rg1> --name peer-1to2     --vnet-name <vnet1> --remote-vnet <vnet2-id>     --allow-vnet-access
az network vnet peering create -g <rg2> --name peer-2to1     --vnet-name <vnet2> --remote-vnet <vnet1-id>     --allow-vnet-access

Hands-on

  • Create two VNets with non-overlapping ranges, peer them (both directions), and verify VM connectivity.
  • Enable gateway transit on the hub and use remote gateways on a spoke; confirm spoke→on-prem path.
  • Add a UDR on a spoke to force traffic through the hub’s Firewall/NVA (service chaining).

Exam focus

  • Peering is non-transitive — the classic gotcha.
  • Each VNet needs its own peering link (both sides).
  • No overlapping address spaces between peered VNets.
  • Gateway transit (hub) + use remote gateways (spoke) settings.

Path MOC · vnet-peering · vnet · route-table · vpn-gateway · virtual-wan

configure-network-security-groups

Module 3 · Configure Network Security Groups

MS Learn: Configure Network Security Groups · learn.wwl.configure-network-security-groups Module note for Path MOC

Overview

Add the security layer: filter inbound/outbound traffic at the subnet and/or NIC boundary using Network Security Groups, and group workloads by role using Application Security Groups to keep rules readable and portable.

Learning objectives (from Microsoft Learn)

In this module, you learn how to:

  • Determine when to use network security groups.
  • Create network security groups.
  • Implement and evaluate network security group rules.
  • Describe the function of application security groups.

Units

  1. Introduction
  2. Implement network security groups
  3. Determine NSG rules
  4. Determine effective (NSG) rules
  5. Create NSG rules
  6. Implement application security groups (ASGs)
  7. Interactive lab: implement network security groups
  8. Knowledge check
  9. Summary and resources

Concepts introduced

Key terms & commands (Azure CLI)

az network nsg create -g <rg> -n nsg-web
az network nsg rule create -g <rg> --nsg-name nsg-web -n r1     --priority 100 --source-address-prefixes Internet --destination-port-ranges 80 443     --access Allow --direction Inbound --protocol Tcp
az network vnet subnet update -g <rg> --vnet-name <vnet> -n snet-web     --network-security-group nsg-web

Hands-on

  • Create an NSG, associate to a subnet; watch effective rules combine subnet+NIC.
  • Build an ASG, assign VMs, and write an NSG rule using the ASG as source/destination.
  • Use Network Watcher → IP Flow Verify to confirm a specific flow is allowed/denied.

Exam focus

  • Priority order (lower number wins); default rules (vnet-internal allow, deny internet inbound) can be overridden, not deleted.
  • Effective rules = subnet rules then NIC rules.
  • NSG = filter; route table = path.
  • ASG lets NSG rules reference roles/names instead of IPs.

Path MOC · nsg · asg · subnet · configure-virtual-networks

control-network-traffic-flow-with-routes

Module 4 · Manage & Control Traffic Flow with Routes

MS Learn: Manage and control traffic flow in your Azure deployment with routes · learn.control-network-traffic-flow-with-routes Module note for Path MOC

Overview

Steer where traffic actually goes. Azure provides automatic system routes; this module shows how to override them with user-defined routes (UDRs) and deploy a network virtual appliance (NVA) — a VM acting as a firewall/router — to inspect or force traffic through a chosen path.

Learning objectives (from Microsoft Learn)

In this module, you will:

  • Identify the routing capabilities of an Azure virtual network.
  • Configure routing within a virtual network.
  • Deploy a basic network virtual appliance.
  • Configure routing to send traffic through a network virtual appliance.

Units

  1. Introduction
  2. Azure Virtual Network route tables
  3. Exercise: create custom (user-defined) routes
  4. Network virtual appliances (NVAs)
  5. Exercise: create an NVA VM
  6. Exercise: route traffic through the NVA
  7. Summary

Concepts introduced

  • Route tables & UDRs — override system routes at the subnet level.
  • BGP — dynamic route exchange for hybrid connectivity (contrast to static UDRs).
  • Azure Firewall — the managed alternative to a self-run NVA.
  • VNet / subnet — the scope where routes apply.

Key terms & commands (Azure CLI)

az network route-table create -g <rg> -n rt-none
az network route-table route create -g <rg> --route-table-name rt-none -n to-internet     --address-prefix 0.0.0.0/0 --next-hop-type Internet
az network vnet subnet update -g <rg> --vnet-name <vnet> -n snet-app --route-table rt-none

Hands-on

  • Create a route table, add a UDR, associate to a subnet, and use Network Watcher → Next Hop to confirm the applied next hop.
  • Deploy an NVA VM, add a UDR pointing 0.0.0.0/0 (or specific prefix) at the NVA’s IP, and verify traffic is steered through it.

Exam focus

  • Precedence: UDR > BGP > system; longest-prefix-match always wins.
  • A route table does nothing until associated to a subnet.
  • Next hop types: VirtualNetwork, Internet, VirtualAppliance, VirtualNetworkGateway, None, VNet peering.
  • UDR + peer = service chaining (hub-and-spoke routing).

Path MOC · route-table · azure-firewall · bgp · vnet · subnet

host-domain-azure-dns

Module 5 · Host Your Domain on Azure DNS

MS Learn: Host your domain on Azure DNS · learn.azure.host-domain-azure-dns Module note for Path MOC

Overview

Use Azure DNS as the authoritative DNS service for your public domains. Create DNS zones, manage record sets, and use alias records to keep resources (like a Load Balancer) reachable without manual IP edits. (Private name resolution inside VNets is the Azure Private DNS service._)

Learning objectives (from Microsoft Learn)

In this module, you will:

  • Configure Azure DNS to host your domain.

Units

  1. Introduction
  2. What is Azure DNS?
  3. Configure Azure DNS to host your domain
  4. Exercise: create a DNS zone and an A record
  5. Resolve names with an alias record
  6. Exercise: create alias records
  7. Summary

Concepts introduced

Key terms & commands (Azure CLI)

az network dns zone create -g <rg> -n contoso.com
az network dns record-set a add-record -g <rg> -z contoso.com     -n www --ipv4-address 20.x.x.x
az network dns record-set a create -g <rg> -z contoso.com -n www     --alias-target-resource-id <resource-id>    # alias record

Hands-on

  • Create a public DNS zone, add an A record, and associate the zone’s NS records at your registrar (delegation).
  • Create an alias record pointing at an Azure LB/front-end IP; change the resource IP and confirm the alias follows automatically.

Exam focus

  • Alias records auto-resolve changes for Azure resources (no manual IP updates).
  • Azure DNS zone → record sets (type+name) → records; TTL matters.
  • Azure DNS = public; Private DNS = within VNets.
  • Delegation = point registrar NS at Azure zone NS.

Path MOC · azure-dns · private-dns · load-balancer · azure-front-door

intro-to-azure-load-balancer

Module 6 · Introduction to Azure Load Balancer

MS Learn: Introduction to Azure Load Balancer · learn.azure.intro-to-azure-load-balancer Module note for Path MOC

Overview

Azure Load Balancer is a Layer-4 (TCP/UDP) load balancer that distributes traffic across a backend pool of VMs/VMSS instances, with health probes and (on Standard) outbound connectivity and zone/region awareness.

Learning objectives (from Microsoft Learn)

In this module, you will:

  • Learn what Azure Load Balancer is and the functionality it provides.
  • Determine whether Load Balancer meets the needs of your organization.

Units

  1. Introduction
  2. What is Azure Load Balancer?
  3. How Azure Load Balancer works
  4. When to use Azure Load Balancer
  5. Knowledge check
  6. Summary

Concepts introduced

Key terms & commands (Azure CLI)

az network lb create -g <rg> -n lb-web --sku Standard --public-ip-address <pip>
az network lb probe create -g <rg> --lb-name lb-web -n probe80 --protocol Http --port 80
az network lb rule create -g <rg> --lb-name lb-web -n rule443     --frontend-port 443 --backend-port 443 --backend-pool-name <pool> --protocol Tcp

Hands-on

  • Create a public LB + backend pool + health probe + rule; add two VMs and verify failover when one is stopped.
  • Note Standard vs Basic differences (zones, outbound, SLA).

Exam focus

  • L4 only — no HTTP routing, no SSl (that’s App Gateway).
  • Public (internet) vs internal (VNet-private) editions.
  • Health probe governs backend availability.
  • Standard SKU adds zones/regions/outbound rules/SLA.

Path MOC · load-balancer · intro-to-azure-application-gateway · vnet

intro-to-azure-application-gateway

Module 7 · Introduction to Azure Application Gateway

MS Learn: Introduction to Azure Application Gateway · learn.azure.intro-to-azure-application-gateway Module note for Path MOC

Overview

Azure Application Gateway is the Layer-7 (HTTP/HTTPS) load balancer: URL/host-based routing, SSL/TLS termination, cookie session affinity, and optional WAF (web application firewall). Where Load Balancer forwards raw TCP/UDP, Application Gateway routes web content.

Learning objectives (from Microsoft Learn)

In this module, you’ll:

  • Learn what Azure Application Gateway is and the functionality it provides.
  • Determine whether Application Gateway meets the needs of your organization.

Units

  1. Introduction
  2. What is Azure Application Gateway?
  3. How Azure Application Gateway works
  4. When to use Azure Application Gateway
  5. Knowledge check
  6. Summary

Concepts introduced

Key terms & commands (Azure CLI)

az network application-gateway create -g <rg> -n appgw     --sku Standard_v2 --capacity 2 --vnet-name <vnet>     --subnet snet-appgw --priority 100

Hands-on

  • Deploy an App Gateway into a dedicated subnet, define a listener + backend pool + HTTP health probe.
  • Add a path-based routing rule (/api/ vs /) and note the behavior.
  • Enable the WAF SKU and observe managed rule set.

Exam focus

  • L7 vs L4 distinction with Load Balancer.
  • SSL termination and cookie session affinity are App GW strengths.
  • URL-path / multi-site routing; needs its own subnet.
  • WAF_v2 protects web apps (OWASP rules).

Path MOC · application-gateway · intro-to-azure-load-balancer · vnet · subnet

intro-to-azure-network-watcher

Module 8 · Introduction to Azure Network Watcher

MS Learn: Introduction to Azure Network Watcher · learn.azure.intro-to-azure-network-watcher Module note for Path MOC

Overview

Azure Network Watcher is the regional monitoring + diagnostics service for networking. Use its tools (Topology, IP Flow Verify, Next Hop, Packet Capture, Connection Monitor, flow logs, VPN troubleshoot) to find why traffic works or doesn’t.

Learning objectives (from Microsoft Learn)

In this module, you will:

  • Learn what Azure Network Watcher is and the functionality it provides.
  • Determine whether Azure Network Watcher meets the needs of your organization.

Units

  1. Introduction
  2. What is Azure Network Watcher?
  3. How Azure Network Watcher works
  4. When to use Azure Network Watcher
  5. Knowledge check
  6. Summary

Concepts introduced

  • Network Watcher — monitoring/diagnostic toolset.
  • Uses NSG + route knowledge to explain flows (IP Flow Verify / Next Hop).

Key terms & commands (Azure CLI)

az network watcher configure -g <rg> --locations <region> --enabled true
az network watcher test-ip-flow-verify -g <rg> --vm <vm> --local-ip <ip>     --remote-ip 20.x.x.x --direction Inbound --protocol Tcp --local-port 80 --remote-port 443
az network watcher show-next-hop -g <rg> --vm <vm> --source-ip <ip> --dest-ip 20.x.x.x

Hands-on

  • Enable Network Watcher for your region.
  • Use Topology to view a VNet; use IP Flow Verify to confirm an NSG allows/denies a specific flow; use Next Hop to confirm routing.

Exam focus

  • Network Watcher is regional — enable per region.
  • IP Flow Verify → “which NSG rule blocks my traffic?”
  • Next Hop → “which route does my packet take?”
  • Topology / Connection Monitor / Packet Capture / flow logs round out the toolbox.

Path MOC · network-watcher · nsg · route-table · configure-network-security-groups

Core topology

Connectivity

Security

Name resolution

Load balancing & traffic

vnet

Virtual Network (VNet)

What it is

An Azure Virtual Network (VNet) is Azure’s software-defined networking fabric — an isolated, customer-controlled private network in the cloud. It is the top-level container that hosts your subnets, NICs, and the majority of Azure networking services (VMs, load balancers, firewalls, DNS).

Why it exists

Physical networks were constrained by hardware and on-premises cabling. A VNet gives you the same segmentation, routing, name resolution, and security primitives as an on-prem LAN, but delivered as an isolated slice of Azure’s shared cloud — provisioned in seconds and fully API-managed.

Key ideas

  • Bound to a region and a subscription (a VNet can span multiple availability zones in its region, but not regions).
  • Defined by a private IP address space (e.g. 10.0.0.0/16) using CIDR; it does not create routes to the internet by default — a public IP + route is needed.
  • Split into one or more subnet.
  • Traffic to the internet, to on-premises, and between VNets is governed by routes and network security groups.
  • VNets are linked to each other via vnet-peering and to on-premises via vpn-gateway or expressroute.

How it fits

vnet.svg

Internet │  On-premises
   │      │      │
   ▼      ▼      ▼
[ public IP ][ VPN Gateway / ER ]
   ┌────────────── VNet (10.0.0.0/16) ──────────────┐
   │  Subnet A (10.0.1.0/24)    Subnet B (10.0.2.0/24) │
   │  [VM][LB]                   [VM][ASG]            │
   │  NSG / route tables / Azure Firewall             │
   └───────────────────────────────▲──────────────────┘
                                   │ vnet-peering
                          ┌────────┴────────┐
                          │  other VNet     │
                          └─────────────────┘

Exam notes

  • VNet is regional; a VNet cannot span regions. Create one VNet per region per tier to isolate at region granularity.
  • A VNet without a default outbound route can’t reach the internet — note the modern default-outbound-access changes; rely on explicit public IP/NAT unless using default outbound.
  • VNets are free; you pay for the resources inside (gateways, public IPs, etc.), and peering data transfer.
  • Deleting a VNet requires all dependent resources (subnets, NICs, peering links) to be removed first.

Home · subnet · cidr-ip-addressing · vnet-peering · route-table · nsg · azure-dns

📘 Source: Microsoft Learn — Vnet

subnet

Subnet

What it is

A subnet is a contiguous segment of a Virtual Network’s address space. It is a CERN-scoped boundary (from CIDR-block subdivision) within which resources get their private IPs and to which security and routing rules are attached.

Why it exists

Segmenting a large address space into subnets lets you organize, isolate, and control traffic: place web, app, and DB tiers in separate subnets, apply different NSGs/routes to each, and reserve ranges for specific service types.

Key ideas

  • Each subnet has exactly one address range that must fall entirely within the parent VNet’s range and not overlap other subnets (Azure reserves the first 4 and last 1 addresses of each subnet).
  • Delegation — a subnet can be delegated to a service (e.g. App Service, Azure SQL Managed Instance, AKS virtual nodes) that then manages it.
  • Service endpoints and private endpoints each attach at the subnet level.
  • Some subnets are service-specific (a “gateway subnet” must be exactly GatewaySubnet for gateways; AzureFirewallSubnet, AzureBastionSubnet).
  • Allowed services/hosting: subnets can host VMs (each NIC gets one private IP), ILBs, firewalls, bastions.

How it fits

VNet address space 10.0.0.0/16 is divided:

10.0.0.0/16  VNet
├── 10.0.0.0/24  snet-frontend    [VM][LB][NSG]
├── 10.0.1.0/24  snet-app         [VM][ASG]
├── 10.0.2.0/24  snet-data        [DB]
├── 10.0.3.0/24  GatewaySubnet    [VPN Gateway]
└── 10.0.4.0/24  AzureFirewallSubnet [Firewall]

Exam notes

  • Reserved addresses: Azure always reserves the first 4 IPs (network, default gateway x.x.x.1, DNS x.x.x.2, future, broadcast) and the last IP of each subnet — usable range is 2^(host bits)-5.
  • Subnet ranges cannot overlap within a VNet; contiguous or not, they must be distinct.
  • One NIC = one private IP per subnet; a NIC can only belong to one subnet.
  • Up to 1000 VMs per subnet (default limit), and a subnet can be in at most one VNet.
  • You can’t change a subnet’s address range if it contains resources.

Home · vnet · cidr-ip-addressing · nsg · route-table · vnet-peering

📘 Source: Microsoft Learn — Subnet

cidr-ip-addressing

IP Addressing & CIDR

What it is

Classless Inter-Domain Routing (CIDR) is the notation Azure uses for all IP ranges (10.0.0.0/24), and IP addressing is how a VNet and its subnet carve up and assign IPv4/IPv6 addresses. Azure resources get both private addresses (inside a VNet) and optionally public addresses (reachable from the internet).

Why it exists

You need a convention to state how big a network is and which addresses a resource may use. CIDR compresses “netmask + network” into one string so Azure can validate that subnets fit inside a VNet and don’t overlap.

Key ideas

  • CIDR /N — /value = number of fixed (network) bits. /24 = 256 addresses, of which ~251 usable in Azure after reserved gateway/DNS/broadcast.
  • Private (RFC 1918) ranges commonly used: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Azure allows any private range, including custom ones like 192.168.0.0/24; VMs inherit from there.
  • Public IP — assigned by you (static/standard) or Azure (dynamic/basic SKU), tied to a NIC/PIP/load balancer.
  • IPv6 — Azure supports IPv6 on VNets/subnets (dual-stack) for public and some private scenarios.
  • IP address types: public (internet) vs private (VNet-internal); dynamic vs static IP allocation.

Key facts (memorize)

  • Default subnet usable range = 2^(32-N) − 5 (Azure reserves 5 per subnet: 4 first + 1 last).
  • A VNet can have at most 1 default (and up to ~400 total) address ranges; subnets must fit within one range.
  • Private IP addresses can be static (reserved) or dynamic; a dynamic private IP reassigned on VM restart unless it’s a NIC-level static.

How it fits

cidr-ip-addressing.svg

Exam notes

  • Always confirm no overlap between VNet ranges and peered VNets / ExpressRoute/corporate ranges — overlap breaks peering and routing.
  • Use the smallest subnet that fits to conserve address space (exam likes subnet sizing questions, e.g. how many /24s fit in a /16 → 256).
  • Public IP SKUs: Basic vs Standard; Standard requires explicit outbound and works with load balancers.

Home · subnet · vnet · azure-dns · network-watcher

📘 Source: Microsoft Learn — Cidr Ip Addressing

route-table

Route Tables & User-Defined Routes (UDR)

What it is

A route table is a collection of route entries that override Azure’s default system routes for a subnet. Routes you author are called user-defined routes (UDRs), and they let you force traffic through an appliance (Azure Firewall or a network virtual appliance/NVA) instead of Azure’s implicit paths.

Why it exists

Azure chooses the next hop for traffic automatically (0.0.0.0/0 → internet, VNet-local → local, peered/on-premises → as configured). Admins often need to steer or inspect traffic (send all egress through a firewall, route between spokes through a hub), so UDRs override the default next hops.

Key ideas

  • Route table is a regional object associated with one or more subnets; a route table does nothing until associated with a subnet.
  • Each route: address prefix + next hop type (VirtualNetwork, VNet peering, Internet, VirtualAppliance, VirtualNetworkGateway, None — drop).
  • Route precedence (lowest-priority wins): UDR > BGP (bgp) route > default system routes, and longest prefix match is always applied first.
  • Local VNet traffic can’t be forced to an NVA unless you use 0.0.0.0/0 or the appliance (same-tier) pattern carefully; forcing through via UDR is the “service chaining” technique used with peering.
  • Used to implement hub-and-spoke and forced tunneling topologies.

How it fits

route-table - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: virtual-network/virtual-networks-udr-overview

Customer VM (snet-app) ──► route table UDR: 0.0.0.0/0 next hop Azure Firewall
                                        │
                                        ▼
                              Azure Firewall (inspect/filter)
                                        │
                                   to internet

Exam notes

  • System routes are created automatically; you see them in the Effective routes tab of a NIC.
  • Longest-prefix-match overrides everything: a more-specific UDR beats a broader system route.
  • UDR precedence: user-defined > BGP > system (for same prefix).
  • Deleting a subnet deletes its associated route-table association but not the table itself; deletion order matters.
  • Can’t see on-premises routes in a VNet unless connected via gateway/BGP.

Home · subnet · vnet · bgp · azure-firewall · vnet-peering · network-watcher

📘 Source: Microsoft Learn — Route Table

bgp

Border Gateway Protocol (BGP)

What it is

Border Gateway Protocol (BGP) is the standard exterior routing protocol that exchanges routing information between autonomous systems (ASes). In Azure it’s how your on-premises edge and ExpressRoute/VPN infrastructural peers advertise routes to (and receive routes from) Azure networks.

Why it exists

Static routes must be manually updated whenever the network changes. BGP automates route exchange and failover: each side advertises the networks it can reach, and the path metric (AS path) decides the best route. This keeps hybrid connectivity resilient without human edits.

Key ideas

  • eBGP is used between Azure virtual network gateways and on-premises BGP peers (VPN gateway or ExpressRoute).
  • BGP peers advertise routes; Azure learns what to route to your on-premises prefixes and announces your VNet prefixes back.
  • AS numbers (ASN) — each side configures a peer ASN (Azure gateway uses a private ASN you specify; on-prem peer has its own).
  • BGP is optional for VPN gateways (you can use Policy-Based/static instead) but is a primary mechanism for ExpressRoute.
  • BGP-learned routes coexist with route tables; BGP routes take precedence over system routes but not over UDRs (User-defined > BGP > system).

Key facts

  • If you’re advertising a default route (0.0.0.0/0) via BGP, it can force all internet traffic on-prem (forced tunneling) — preview official behavior.
  • VPN Gateway + BGP gives active-active / failover and dynamic route updates on topology changes.
  • Azure private ASN range for gateways is typically 64512–65534 (private ASN).

How it fits

[on-prem router ASN 65000]                     [Azure gateway ASN 64512]
        │  BGP session (eBGP over IPsec/ER)          │
        │  advertise corp prefixes <────>            │
        │  receive VNet prefixes                     │
        ▼                                             ▼
   on-prem network                               VNet routes

bgp - Microsoft diagram Diagram courtesy of Microsoft Learn / Azure docs: expressroute/expressroute-optimize-routing

Exam notes

  • BGP is most relevant to hybrid connectivity (ExpressRoute and site-to-site VPN with dynamic routing).
  • Not needed for VNet peering or internal Azure routing.
  • Remember precedence: UDR > BGP > system, with longest-prefix-match always resolved first.

Home · expressroute · vpn-gateway · route-table · virtual-wan

📘 Source: Microsoft Learn — Bgp

network-watcher

Azure Network Watcher

What it is

Azure Network Watcher is the regional diagnostics and monitoring service for Azure networking. It gives tools to inspect connectivity, packet flows, topology, and logs across your VNets and subnets.

Why it exists

When traffic “doesn’t work,” administrators need fast, visual answers: is the route right? is the NSG blocking? can VM A reach VM B? Network Watcher centralizes these connectivity/protocol diagnostics instead of you poking NIC/protocol state manually.

Key ideas (core tools)

  • Topology — visual interactive graph of your VNet resources and their connections.
  • IP Flow Verify — tests whether a packet from a source IP/port to a destination IP/port is allowed or denied, applying NSG rules + routes to explain the result.
  • Next Hop — shows the next hop (and which route drove it) for a packet, great for debugging UDRs.
  • Effective security rules — lists the applicable NSG rules for a NIC/subnet combined (classic Association + effective).
  • VPN troubleshoot — diagnoses gateway/connection issues.
  • Packet capture — captures traffic to/from a VM NIC (agent-free snapshot).
  • Connection monitor — end-to-end, recurring connectivity/performance testing between resources.
  • NSG/network flow logs — record allowed/denied flows for SIEM/NSG analysis.

How it fits

Enabled per region (one Network Watcher per region) and typically deployed automatically (one instance per region). Flows from VNets across many subnets are analyzed in one pane. network-watcher - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: network-watcher/network-watcher-monitoring-overview

Exam notes

  • Network Watcher is regional — enable it in the region where your VNets live.
  • Flow logs and some tools incur cost/are billed; baseline topology/IP flow verify tools are often free but check current billing docs.
  • Use IP Flow Verify for “which NSG rule is blocking my traffic” exam scenarios; use Next Hop for route/diagnostic questions.

Home · vnet · nsg · route-table · subnet

📘 Source: Microsoft Learn — Network Watcher

vnet-peering

Virtual Network Peering

What it is

Virtual Network Peering (VNet peering) is a direct, high-bandwidth, low-latency connection between two VNets over Microsoft’s backbone, enabling them to communicate as if directly connected — with no gateway, no public internet, no VPN tunnel.

Why it exists

Applications often span multiple VNets (per-tier, per-region, cross-subscription, or cross-tenant environments). Peering gives near‑local connectivity, lets peered VNets share routes, and enables hub-and-spoke designs — a cheap, low-latency alternative to VPN gateways for VNet-to-VNet traffic.

Key ideas

  • Peering is non-transitive by default: VNet A ⇄ B and B ⇄ C does NOT give A ⇄ C. Use hub-and-spoke with a UDR (”service chaining”) or Virtual WAN to route through.
  • Two directions: a peering link is created independently in each VNet (both sides must be enabled).
  • Can peer VNets in: same/different regions (global peering), same/different subscriptions, same/different tenants (limit/considerations apply).
  • Cannot overlap address spaces between peered VNets.
  • Gateway transit lets a spoke use the hub’s vpn-gateway/ExpressRoute gateway for outbound/hybrid connectivity (transit must be enabled on both sides) — a VPN Gateway in the hub makes spoke-to-on-prem possible via peering.
  • Traffic over peering is private and free of egress fees (peering data transfer billed as egress at reduced rates; see docs).

How it fits

              [hub VNet]
  spokeA ─────┘    │    └──── spokeB
  peer links on each side only
  (non-transitive: spokeA can't reach spokeB without UDR/NVA)

vnet-peering - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: virtual-network/virtual-network-peering-overview

Exam notes

  • Memorize non-transitivity — the classic exam gotcha.
  • Allow gateway transit + use remote gateways are peer-settings on the hub/spoke respectively.
  • Peering does not create overlapping-IP routing; ranges must not overlap.
  • Cross-region peering is called global peering; supported for most scenarios.

Home · vnet · subnet · route-table · vpn-gateway · virtual-wan

📘 Source: Microsoft Learn — Vnet Peering

vpn-gateway

Azure VPN Gateway

What it is

Azure VPN Gateway is a managed service (a pair of active VM instances behind a public Virtual Network gateway) that sends encrypted traffic between an Azure VNet and on-premises locations (and/or other VNets) over the public internet or over an IPsec tunnel.

Why it exists

You need secure hybrid connectivity without a dedicated private line. A VPN gateway terminates IPsec/IKE tunnels (site-to-site) and OpenVPN/IKE/SSL (point-to-site) so on-prem and remote users can reach Azure resources securely over the internet.

Key ideas

  • Connection types: Site-to-Site (S2S) — IPsec tunnel to an on-prem VPN device; Point-to-Site (P2S) — individual clients; VNet-to-VNet — between Azure VNets (or via vnet-peering without gateway).
  • Deployed on a dedicated gateway subnet named GatewaySubnet (must be exactly this name).
  • SKUs (VpnGw1/2/3, VpnGw5, etc.) define throughput/tunnels; availability depends on generation.
  • Active-active configuration (two instances) for redundancy.
  • Can run bgp for dynamic routing and failover.
  • VPN vs ExpressRoute: VPN = internet-based, cheaper, variable latency/throughput; ExpressRoute = private dedicated link, higher/SLA-backed throughput.
  • Gateways incur hourly cost + data transfer; only one active/active gateway can exist per region.

How it fits

[on-prem VPN device/router]   <—IPsec S2S—>   [Azure VPN Gateway]
       │                                           │  (GatewaySubnet)
   corp LAN                                    [VNet subnets]

vpn-gateway.svg

Exam notes

  • Gateway subnet must be named GatewaySubnet; it can’t host other resources.
  • Point-to-Site connects individual users; Site-to-Site connects sites; VNet-to-VNet connects VNets.
  • To reach on-premises from a peered spoke, enable ”Use remote gateways” on the spoke and ”Allow gateway transit” on the hub.
  • Compare consistently with expressroute and virtual-wan for hybrid questions.

Home · bgp · expressroute · vnet · virtual-wan · route-table

📘 Source: Microsoft Learn — Vpn Gateway

expressroute

Azure ExpressRoute

What it is

Azure ExpressRoute extends your on-premises networks into the Microsoft cloud over a private, dedicated connection that does not traverse the public internet — provided by a connectivity provider (colocation, point-to-point Ethernet/Ethernet over MPLS, or integrated express route).

Why it exists

VPN over the internet is subject to variable latency, congestion, and security exposure. Organizations needing consistent performance, higher throughput, and private/SLA-backed connectivity to Azure use ExpressRoute — plus that traffic gives them access to Microsoft 365 and Azure from the same private peering.

Key ideas

  • Three circuit offerings: Microsoft peering (Microsoft 365, public Azure services), Public peering (legacy; retired), and Private peering (VNet access) — with modern Standard and Premium depending on services reached.
  • A single ExpressRoute circuit can connect to VNets in multiple subscriptions/regions via circuit -> gateway -> VNet.
  • Requires a gateway (ExpressRoute gateway) on a GatewaySubnet in the target VNet.
  • BGP is the routing protocol between your edge and the ExpressRoute gateway (dynamic, enables failover).
  • Redundancy — circuits are designed with redundant paths (active/active) by the provider.
  • Daily/hourly billing + data transfer; Premium add-on: global reach / more circuits / cross-region, per current docs.

How it fits

[on-prem edge/ER circuit]  <— private, no internet —>  [ExpressRoute gateway]
       provider (Ethernet/MPLS)                         |  (GatewaySubnet)
                                                        ▼
                                                   [VNet subnets]

expressroute - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: expressroute/expressroute-introduction

Exam notes

  • ExpressRoute ≠ VPN: private, dedicated, no internet, higher/consistent throughput; VPN = internet, cheaper, less predictable.
  • Uses BGP, not IKE/IPsec for the core connectivity.
  • Only Premium/SKU and a gateway in the right VNet connect many regions — a circuit is tied to a peering location/region.
  • For exam, know the width vs VPN trade-off, peering types (Microsoft vs Private), and that you still need a gateway per connected VNet.

Home · vpn-gateway · bgp · virtual-wan · vnet

📘 Source: Microsoft Learn — Expressroute

virtual-wan

Azure Virtual WAN

What it is

Azure Virtual WAN is a managed hub-and-spoke networking service that consolidates branch (site-to-site), remote-user (point-to-site), VPN, and ExpressRoute connectivity into a set of virtual hubs Microsoft operates across regions. Each hub carries routing, and can host Azure Firewall and network security groups.

Why it exists

Traditional hub-and-spoke with separate VPN gateways, route tables, NSGs, and peering is complex to operate at scale across many regions. Virtual WAN gives one management plane for branch/remote/hybrid connectivity with global transit routing — administrators connect spokes to a hub instead of hand-managing peering and gateways per region.

Key ideas

  • Virtual hubs — regional hubs that own routing, gateways (VPN Site-to-Site, Point-to-Site, ExpressRoute) and optional Azure Firewall.
  • Global transit — spokes in different regions route through hubs; transitive routing (unlike plain peer non-transitivity) is handled by the hub/routing infrastructure.
  • Branch-to-VNet, VNet-to-VNet, VNet-to-branch over the Microsoft backbone; no internet egress between them.
  • Standard vs Basic tiers: Standard adds ExpressRoute, global transit, fireworks integration, etc.
  • Routing is propagated automatically to spokes; you can override with custom route destinations (UDR style).

How it fits

[Branch A]─┐                  ┌─[Spoke VNet 1]
[Branch B]─┼─► [Virtual Hub A] ┼─[Spoke VNet 2]
[Remote user]                  ├─(peer to hub)
[ER circuit]                   └─► transit to [Virtual Hub B] (other region)

virtual-wan - Microsoft diagram Diagram courtesy of Microsoft Learn / Azure docs: virtual-wan/virtual-wan-about

Exam notes

  • Virtual WAN provides transitive connectivity via its hub, a contrast to basic vnet-peering.
  • One Virtual WAN per region; standard tier required for ExpressRoute and global transit.
  • Deleting a hub/vWAN removes underlying gateways; be careful with Dependency and billing.

Home · vnet · vpn-gateway · expressroute · vnet-peering · azure-firewall

📘 Source: Microsoft Learn — Virtual Wan

nsg

Network Security Group (NSG)

What it is

A Network Security Group (NSG) is a list of allow/deny rules (allow/deny) that filter inbound and outbound traffic at the subnet and/or NIC level for resources in a subnet. It has no routing; routing is handled separately by route tables.

Why it exists

You need cheap, per-interface/per-tier filtering of who can talk to whom inside your VNet and with the outside world. NSGs provide stateful, micro-segmented security filtering without a box — applied right at the workload.

Key ideas (the three pieces — memorize!)

  1. Security rules — each rule has: priority (lower number = higher priority), source/destination (IP/CIDR, service tag, app security group), protocol (TCP/UDP/any), port ranges, direction (inbound/outbound), and action (Allow/Deny).
  2. Association — an NSG binds to a subnet and/or one or more NICs. At a subnet you filter all its VMs; at a NIC you filter that one.
  3. Evaluation order — rules processed by priority, first match wins; default rules (allow VNet, deny internet inbound, etc.) exist and can’t be deleted, only overridden by higher-priority rules.

Flow logic (exam favorite)

subnet association  ────────┐
NIC association    ────────┼──► combine (effective rules)
                            ▼
         process rules by priority, first match decides allow/deny
  • An NSG applied at both subnet and NIC: subnet rules evaluated first, then NIC rules. Both must allow.
  • Stateful: an allowed inbound flow automatically allows the return traffic; NO need for a separate return rule.

How it fits

nsg.svg

Exam notes

  • Default rules: allow VNet-internal, deny all internet inbound, deny-all-internet-inbound on public IPs; override with higher-priority custom rules.
  • Never invent port/priority facts — use lowest-number (highest-priority) rule matches; empty NSG association = no filter applied (defaults allow everything unless explicitly restricted).
  • NSG = filter, route table = path, Azure Firewall = centralized+stateful higher-layer filtering.
  • An NSG can be reused across many subnets/NICs; it’s an agnostic object.

Home · asg · subnet · vnet · azure-firewall · network-watcher

📘 Source: Microsoft Learn — Nsg

asg

Application Security Group (ASG)

What it is

An Application Security Group (ASG) is a logical grouping of virtual machines/NICs under one application-centric name so NSG rules can be written against roles (e.g. WebServers, AppServers) instead of individual IPs/CIDRs.

Why it exists

Writing NSG rules by IP/CIDR is brittle — add a VM, renumber a subnet, and your rules break. An ASG decouples what (role/application tier) from where (IP), so you write one rule (“allow 443 from WebServers to AppServers”) that keeps working as members change.

Key ideas

  • An ASG contains NICs of VMs only (not subnets).
  • NSG rules use an ASG as source or destination; you can mix IPs, service tags, and ASGs in rules.
  • Membership is manual or via VM/VMSS; a NIC can be in one ASG; rules reference ASGs by name.
  • A single ASG can appear in rules of one (or more) NSGs, and multiple ASGs can be combined.

Rule example

priority 100  source: Source=ASG WebServers  dest=ASG AppServers  allow TCP 443
priority 200  source: Source=ASG AppServers  dest=ASG AppServers  deny  all     (isolate tier)

How it fits

NICs tagged into Web and DB ASGs; an NSG associated with the subnet references them: asg - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: virtual-network/application-security-groups

Exam notes

  • ASG = NIC membership by role; not an NSG replacement — it’s the object NSG rules reference.
  • NSG’s “source/destination” can be an ASG, a service tag, or an IP/CIDR.
  • Grouping by application tier is the canonical use case; rules become portable across IP changes.

Home · nsg · subnet · vnet

📘 Source: Microsoft Learn — Asg

azure-firewall

Azure Firewall

What it is

Azure Firewall is a managed, stateful, cloud-native firewall-as-a-service with built-in high availability and unlimited cloud scalability. It performs application (FQDN) and network (IP/port) filtering, threat intelligence (signature-based hunting), DNAT for inbound, and centralized logging/metrics for outbound traffic.

Why it exists

NSGs filter per-subnet/NIC but lack the centralized, application-layer (FQDN) inspection, auto-scalable throughput, and traffic-engineering (hunting/throttling) that a real perimeter firewall needs. Azure Firewall replaces/hardens your NVA or open-source firewalls at scale, with forced tunneling through UDRs to funnel all traffic through it.

Key ideas

  • Rules — Application rule (FQDN allow/deny, e.g. *.contoso.com), Network rule (IP/protocol/port), NAT rule (DNAT inbound), plus Threat Intelligence (deny malicious IPs/FQDNs), Web categories (as per standards).
  • Firewall Policy — a separate resource holding rule collections, reusable across multiple firewalls (better than legacy per-firewall rules).
  • SKUs — Standard and Premium (Premium adds IDPS, TLS inspection, URL filtering).
  • Deployed in a dedicated AzureFirewallSubnet with a single public IP; scales automatically (multiple instances as load grows).
  • Supports Forced tunneling (all internet egress through it), DNS proxy, and integration with Virtual WAN hubs.
  • DDoS Protection — always on (Basic); can be enhanced with DDoS protection plan (Standard).

How it fits

[VM/app] ──0.0.0.0/0 UDR──► [Azure Firewall]  DHCP  [...internet]
                              │  App rules / Network rules / Threat intel / DNAT inbound
                              ▼
                          to allowed destinations

azure-firewall - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: firewall/overview

Exam notes

  • Azure Firewall is stateful and auto-scalable; needs a dedicated AzureFirewallSubnet with a public IP.
  • Use Application rules for outbound FQDNs; Network rules for IP/port; DNAT for inbound mapping.
  • Firewall Policy is the modern way to share rule sets across firewalls.
  • Compare to nsg (per-subnet/NIC stateless-ish microsegmentation) — Firewall = centralized perimeter + app-layer.

Home · nsg · route-table · virtual-wan · ddos-protection · vnet

📘 Source: Microsoft Learn — Azure Firewall

ddos-protection

Azure DDoS Protection

What it is

Azure DDoS Protection defends public IP assignments against Distributed Denial-of-Service (DDoS) attacks. It has two tiers: DDoS Network Protection (Basic, free, always-on) that mitigates common network-layer attacks, and DDoS Network Protection (Standard) that adds enhanced, tuned monitoring and mitigation for the protected VNet’s public IPs.

Why it exists

Public endpoints are targets for volumetric/protocol/application DDoS floods. You can’t build a defense in every workload, so Azure auto-detects and scrubs attacks at the edge; Standard adds cost-aware, written-into-policy protection with per-IP tuning and telemetry.

Key ideas

  • DDoS Protection (Basic) — always on for all Azure public IPs at no extra cost; only default network-layer mitigation (no tuning/telemetry).
  • DDoS Protection (Standard) — attach the DDoS protection plan to a VNet; its public IPs get: 24/7 monitoring, real-time attack metrics (alerts), baseline-based adaptive tuning, mitigation reports, and per-IP protection.
  • Policy-based — rate-limiting/blackholing rules written to stop attacks while keeping legitimate traffic.
  • Applied at the VNet level (Standard) — all public IPs in that VNet are protected; one plan per subscription region/zone.
  • Works alongside Azure Firewall and NSGs.

How it fits

ddos-protection - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: ddos-protection/ddos-protection-overview

[Attacker traffic] ──► [Azure DDoS edge scrubbing] ──► [Public IP]
                              │                          │
                        (Basic: network-layer)       [protected VNet]
                        (Standard: tuned + telemetry)

Exam notes

  • Basic = free, always-on, network-layer only. Standard = plan + VNet-scoped, adds tuning/telemetry/alerts.
  • Attach Standard to the VNet, not individual IPs; one plan per subscription.
  • DDoS is about defending public endpoints; not an alternative to nsg/Firewall for filtering.

Home · azure-firewall · vnet · nsg

📘 Source: Microsoft Learn — Ddos Protection

azure-dns

Azure DNS

What it is

Azure DNS is a hosted authoritative DNS service for public name resolution. You create DNS zones for domains you own (e.g. contoso.com), add records (A, AAAA, CNAME, MX, TXT, etc.), and Azure answers queries globally using Microsoft’s anycast name servers.

Why it exists

Instead of running your own BIND/DNS servers or paying a registrar for resolution, you need high-availability, low-latency, global DNS with a clean management UI/API. Azure DNS keeps management inside your Azure portal/ARM pipeline and integrates with other Azure resources.

Key ideas

  • DNS zone — the container for a domain; name servers (NS) are assigned to each zone (typically 4).
  • Record sets — group records of the same type + name; alias records (can point to Azure resources like LBs, Front Door, blobs, or other zones; track resource IP changes automatically — no manual updates).
  • TTL on records; delegation — point your registrar’s NS to Azure’s zone NS.
  • Private DNS — separate service for internal resolution; see private-dns.
  • Considerations: use alias records to reference Azure Service endpoints; CNAME/alias disallow certain combos; DNS resolution latency via global anycast.

How it fits

[registrar] ─NS─► [Azure DNS zone: contoso.com]──A/www→ 20.x.x.x (LB/Front Door)
                        record sets: A, CNAME, MX, TXT, alias

azure-dns.svg

Exam notes

  • Alias records avoid IP churn when target Azure resources change — key for [LOAD BALANCER] front-door consistency.
  • Azure DNS = public authoritative; Azure Private DNS = internal (linked to VNets). Know the distinction.
  • Record set types + TTL are common asked details.
  • You can move DNS hosting of a domain to Azure by delegating NS records.

Home · private-dns · vnet · load-balancer · azure-front-door

📘 Source: Microsoft Learn — Azure Dns

private-dns

Azure Private DNS

What it is

Azure Private DNS provides authoritative name resolution inside your Virtual Networks using private DNS zones (e.g. privatelink.database.windows.net), without exposing hosts to the public internet. It’s the counterpart of public Azure DNS for internal workloads.

Why it exists

Public DNS won’t resolve private IPs, and cloud-native auto-provided DNS (.internal, azureinternal) is generic. Workloads need custom, stable internal hostnames and must resolve Azure Private Link endpoints. Private DNS gives you clean names for VMs, DBs, storage accounts (via private endpoints) — all within the VNet.

Key ideas

  • Private DNS zone — like a public zone but linked to VNets so only VNet-connected resources resolve it.
  • Virtual network link + auto-registration: when auto-registration is on, VMs in a linked subnet can auto-create their A/PTR records (their hostname → private IP).
  • Resolution — the zone’s records resolve for any VM whose VNet is linked to it; name suffix differences across zones handled by priority/zone scope rules.
  • Common pattern: Private Endpoint + privatelink.<service>.windows.net zone records map the service private IP.
  • Public vs Private: Public zones are authoritative from the internet; private zones are authoritative inside linked VNets.

How it fits

[VM in VNet A] ──► [Private DNS zone  privatelink.database.windows.net]
                       linked to VNet A & B
                       A record → private IP of the DB private endpoint

private-dns - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: dns/private-dns-overview

Exam notes

  • Public Azure DNS = internet-facing; Private DNS = custom internal name resolution in your VNets.
  • Enable auto-registration on the VNet link to auto-populate VM A/PTR records.
  • Use privatelink.* zones with Private Endpoints for PaaS (SQL, Storage, etc.).
  • Split-horizon: a record that should resolve both inside and outside needs the public zone (for internet) and private zone (for internal) — keep them in sync or use the Private Endpoint pattern.

Home · azure-dns · vnet · subnet

📘 Source: Microsoft Learn — Private Dns

load-balancer

Azure Load Balancer

What it is

Azure Load Balancer is a Layer 4 (transport) load balancer that distributes TCP/UDP traffic across a set of backend virtual machines/instances (e.g. a VM scale set). It operates at the network (L3/L4) layer — no HTTP awareness.

Why it exists

A single VM is a single point of failure and a capacity ceiling. Load Balancer spreads traffic and handles failover/health so a collection of backends appears as one reliable service, without adding latency (it’s a pass-through forwarder).

Key ideas

  • Versions: Public LB (receives internet traffic, maps public IP to backends) vs Internal LB (private, inside a VNet, no internet).
  • SKUs: Basic (cost-effective, single front-end/regions, no SLA, health probe limited) vs Standard (multi-frontend, across zones/regions, outbound rules, SLA, required for VMSS) — & Gateway (for L3 VXLAN/gateway load balancing).
  • Components: frontend (public/private IP), backend pool (VMs/VMSS instances by NIC/IP), health probes (HTTP/TCP/HTTPS), load-balancing rules (port mappings + session stickiness session affinity).
  • Layer 4 only — no SSL offload, no path-based routing (that’s application-gateway).
  • Outbound NAT — Standard LB provides outbound connectivity for VMs with no public IP (outbound rules).

How it fits

[Internet] ──► [LB public frontend 20.x.x.x]
                      │  health probe + rule
              ┌───────┼────────┐
           [VM1]   [VM2]   [VM3]   (backend pool, TCP 443)

load-balancer - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: load-balancer/load-balancer-overview

Exam notes

  • L4 (TCP/UDP) vs application-gateway L7 (HTTP/HTTPS) — the #1 distinction.
  • Standard vs Basic: Standard = zones, cross-region, outbound rules, SLA; Basic = single region/zone, no SLA.
  • Health probe determines backend availability; session affinity pins a client to a backend.
  • Public = internet-facing; Internal = within VNet.

Home · application-gateway · traffic-manager · azure-front-door · vnet · subnet

📘 Source: Microsoft Learn — Load Balancer

application-gateway

Azure Application Gateway

What it is

Azure Application Gateway is a Layer 7 (HTTP/HTTPS) load balancer that routes web traffic based on URL paths, hosts, and headers — offering SSL/TLS termination, cookie-based session affinity, and an optional Web Application Firewall (WAF).

Why it exists

Web applications need content-aware routing (e.g. /api/* to one pool, /static/* to another), offload of SSL/HTTP processing, and protection from web exploits (OWASP) — capabilities a Layer-4 Load Balancer can’t give. App Gateway handles them at the application layer.

Key ideas

  • Layer 7 features: URL path-based routing, multi-site (host-based) routing, SSL/TLS termination & end-to-end encryption, session affinity (cookie) , autoscaling.
  • WAF v2 SKU — web application firewall protecting against OWASP Top 10; blocks SQLi/XSS via managed rule sets.
  • Components: listener (protocol/host/path), routing rules → backend pool (VMs, VMSS, App Service, on-prem), health probes (HTTP).
  • SKUs: WAF_v2 / Standard_v2 (autoscaling, zone redundancy); older v1 tiers exist.
  • Deploys in a dedicated subnet for the gateway’s NICs; requires a public/internal IP frontend.
  • AGIC (Application Gateway Ingress Controller) integrates with AKS.

How it fits

[Internet]
   │  HTTPS → SSL offload + WAF
   ▼
[App Gateway frontend]
   │  URL-path rules
   ├── /api/*  → backend pool A (VMs)
   └── /*      → backend pool B (App Service)

application-gateway - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: application-gateway/overview

Exam notes

  • L7 (HTTP/HTTPS) routing vs Load Balancer L4 (TCP/UDP) — memorize.
  • WAF protects web apps (SQLi/XSS) — only on the WAF SKU.
  • SSL offload and cookie session affinity are App Gateway strengths.
  • Needs a dedicated subnet; uses listeners → rules → backend pools.

Home · load-balancer · traffic-manager · azure-front-door · vnet · subnet

📘 Source: Microsoft Learn — Application Gateway

traffic-manager

Azure Traffic Manager

What it is

Azure Traffic Manager is a DNS-based, global traffic router that distributes traffic across endpoints in different regions/endpoints (VMs, LBs, App Gateways, cloud services, web apps, or even external endpoints) entirely at the DNS level — no single Azure resource sits inline.

Why it exists

For global availability and latency, you want users directed to the best region (closest, fastest, or available one). Because it operates on DNS (not proxying or L4/L7), Traffic Manager can send users to entirely different regions/services without a gateway in the path — giving regional failover and geographic performance steering.

Key ideas

  • Routing methods: Priority (primary/backup failover), Weighted (proportion of traffic), Performance (closest/least latency), Geographic (route by user location), Multi-value (return multiple healthy endpoints), Subnet (route specific client IPs).
  • Endpoints — Azure or external; endpoint monitoring via health checks that mark a profile/endpoint Enabled/Disabled/Degraded.
  • DNS-based: users are returned a DNS name that resolves to the chosen endpoint; no proxying, so no added connection latency.
  • Good for regional failover across availability/recovery; complements but does not do L4/L7 offload or SSL termination.

How it fits

[users worldwide]
   │  DNS query → returns best endpoint IP
   ▼
[Traffic Manager profile (DNS)]
   │  Performance routing
   ├──→  [region 1 LB]  [region 2 LB]  [region 3 LB]
        (endpoints monitored for health)

traffic-manager.svg

Exam notes

  • Traffic Manager = DNS-level, global routing; no inline proxy, no SSL, no L4/L7 — routing methods/questions are the core.
  • Compare with Front Door (L7/global proxy + WAF) and Load Balancer (L4, regional).
  • Priority/Weighted/Performance/Geographic methods are exam staples.

Home · azure-front-door · load-balancer · application-gateway · azure-dns

📘 Source: Microsoft Learn — Traffic Manager

azure-front-door

Azure Front Door

What it is

Azure Front Door is a global, HTTP(S)/Layer-7 accelerator that combines intelligent routing (to the nearest/healthiest origin) with global delivery (CDN-style caching), SSL termination at the edge, and an optional Web Application Firewall (WAF). It’s the modern standard global front-end for web applications.

Why it exists

Global web apps need to route users to the right region for both performance and availability, while caching static content at the edge and protecting against web attacks (WAF). Traffic Manager only does DNS; Load Balancer/App Gateway are regional. Front Door combines global L7 routing + CDN + WAF in one managed edge service.

Key ideas

  • Front Door profile + endpoints — routes traffic to origin groups (backends) across regions with health probes and session affinity / affinity (sticky), plus global anycast routing.
  • SSL/TLS termination & end-to-end at edge; path-based / host-based routing just like App Gateway but globally.
  • Caching static content on Azure’s edge network (CDN component).
  • WAF policy, managed rules (OWASP), rate limiting.
  • Routing rules/reconfiguration with low latency (failover in seconds).
  • Standard vs Premium tiers (Premium adds Private Link origin, edge rules richer).

How it fits

[users]  →  [Azure Front Door edge (global anycast)]
                │  L7 + WAF + SSL + caching
                │  latency/health-based routing
        ┌───────┴────────┐
   [origin A region] [origin B region]

azure-front-door - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: frontdoor/front-door-overview

Exam notes

  • Front Door = global L7 proxy + CDN + WAF; Traffic Manager = DNS-only global routing; App Gateway = regional L7; Load Balancer = regional L4.
  • Memorize the four-way comparison (LD: L4 regional, App GW: L7 regional, Traffic Manager: DNS global, Front Door: L7 global + CDN/WAF).
  • Standard vs Premium tier distinction (Premium: Private Link origins, advanced edge operations).

Home · traffic-manager · application-gateway · load-balancer · azure-dns · azure-firewall

📘 Source: Microsoft Learn — Azure Front Door