{"id":500,"date":"2026-04-14T07:06:39","date_gmt":"2026-04-14T07:06:39","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-load-balancer-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-14T07:06:39","modified_gmt":"2026-04-14T07:06:39","slug":"azure-load-balancer-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-load-balancer-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Azure Load Balancer Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure Load Balancer is Microsoft Azure\u2019s native, Layer 4 (TCP\/UDP) load-balancing service for distributing traffic across virtual machines (VMs), virtual machine scale sets (VMSS), and other IP-based endpoints inside an Azure virtual network (VNet) and\/or from the public internet.<\/p>\n\n\n\n<p>In simple terms: <strong>Azure Load Balancer gives you a single IP address (public or private) and spreads connections across multiple backend instances<\/strong>, improving availability and scaling for network workloads.<\/p>\n\n\n\n<p>Technically: Azure Load Balancer operates at <strong>OSI Layer 4<\/strong> (not HTTP-aware like an L7 reverse proxy). It uses <strong>health probes<\/strong> to detect backend availability and then applies <strong>load-balancing rules<\/strong> (and optional inbound NAT rules, outbound rules) to steer flows to healthy endpoints. It supports <strong>internal load balancing<\/strong> (private frontend IP) and <strong>public load balancing<\/strong> (public IP frontend), and can be <strong>zone-redundant<\/strong> or <strong>zonal<\/strong> depending on how you deploy the frontend IP.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> When you run multiple instances of a service (web, API, gaming, DNS, custom TCP services), you need a stable \u201cfront door\u201d IP and a way to distribute connections so the service remains available during maintenance, failures, and scale events. Azure Load Balancer provides that stable entry point and highly available distribution mechanism at the networking layer.<\/p>\n\n\n\n<blockquote>\n<p>Naming \/ lifecycle note (important): The current service name is <strong>Azure Load Balancer<\/strong>. It has historically had <strong>Basic<\/strong> and <strong>Standard<\/strong> SKUs. <strong>Standard<\/strong> is the recommended SKU for production. If you see guidance suggesting <strong>Basic Load Balancer<\/strong>, treat it as legacy guidance and <strong>verify the latest retirement\/availability status in official docs<\/strong> before adopting it.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Load Balancer?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Azure Load Balancer is a managed Azure Networking service that provides <strong>high-performance, low-latency Layer 4 load balancing<\/strong> for inbound and outbound traffic.<\/p>\n\n\n\n<p>Primary official documentation entry:\n&#8211; https:\/\/learn.microsoft.com\/azure\/load-balancer\/load-balancer-overview<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Public load balancing<\/strong>: distribute internet traffic to backend instances.<\/li>\n<li><strong>Internal load balancing (ILB)<\/strong>: distribute private traffic inside a VNet (east-west) to backend instances.<\/li>\n<li><strong>Health probing<\/strong>: detect unhealthy instances and avoid sending new flows to them.<\/li>\n<li><strong>Port\/flow mapping<\/strong> with rules:<\/li>\n<li><strong>Load-balancing rules<\/strong> for distributing traffic.<\/li>\n<li><strong>Inbound NAT rules<\/strong> for mapping a frontend port to a specific backend VM\/port (commonly used for management access via unique ports).<\/li>\n<li><strong>Outbound rules<\/strong> for controlling SNAT behavior for outbound connectivity (Standard SKU scenarios).<\/li>\n<li><strong>Zonal and zone-redundant architectures<\/strong>: align with Availability Zones for resiliency (region-dependent).<\/li>\n<li><strong>High Availability (HA) Ports<\/strong> for load balancing all ports (common with NVAs and some advanced designs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (practical mental model)<\/h3>\n\n\n\n<p>An Azure Load Balancer resource is built from a set of sub-resources:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Frontend IP configuration<\/strong><\/li>\n<li>Public frontend: bound to a <strong>Public IP address<\/strong> resource.<\/li>\n<li>Internal frontend: bound to a <strong>private IP<\/strong> in a subnet.<\/li>\n<li><strong>Backend pool<\/strong><\/li>\n<li>The set of targets (typically VM NICs or VMSS instances).<\/li>\n<li><strong>Health probes<\/strong><\/li>\n<li>TCP probe or HTTP probe used to determine backend health.<\/li>\n<li><strong>Load-balancing rules<\/strong><\/li>\n<li>Define how traffic from frontend IP:port is distributed to backend pool:port with a selected probe.<\/li>\n<li><strong>Inbound NAT rules \/ NAT pools<\/strong><\/li>\n<li>Map unique frontend ports to specific backend instances (commonly for SSH\/RDP access).<\/li>\n<li><strong>Outbound rules (Standard)<\/strong><\/li>\n<li>Control outbound SNAT and associate backend pools to a public IP\/prefix.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed Azure Networking service<\/strong><\/li>\n<li><strong>Layer 4<\/strong> (TCP\/UDP), not an L7 reverse proxy<\/li>\n<li>Works with <strong>VNets<\/strong>, <strong>subnets<\/strong>, <strong>NICs<\/strong>, <strong>Public IPs<\/strong>, and other Azure networking primitives<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional, zonal, and global considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Load Balancer is a regional service.<\/strong><\/li>\n<li>You can deploy it as:<\/li>\n<li><strong>Zone-redundant<\/strong> (frontend spans zones) or<\/li>\n<li><strong>Zonal<\/strong> (frontend pinned to a specific zone),\n  depending on SKU, region support, and the Public IP configuration.<\/li>\n<li>For <strong>global<\/strong> HTTP(S) load balancing and acceleration, Azure\u2019s typical choices are <strong>Azure Front Door<\/strong> (global) or <strong>Traffic Manager<\/strong> (DNS-based). Azure Load Balancer is not a global anycast service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Azure ecosystem<\/h3>\n\n\n\n<p>Azure Load Balancer is often used alongside:\n&#8211; <strong>Azure Virtual Network (VNet)<\/strong> and <strong>Network Security Groups (NSGs)<\/strong>\n&#8211; <strong>Virtual Machines<\/strong> and <strong>Virtual Machine Scale Sets<\/strong>\n&#8211; <strong>Azure Firewall<\/strong>, NVAs, and <strong>Gateway Load Balancer<\/strong> (for advanced chaining patterns\u2014verify current compatibility in docs)\n&#8211; <strong>Azure Monitor<\/strong> for metrics and diagnostics\n&#8211; <strong>Azure Private Link \/ Private Endpoints<\/strong> (adjacent patterns; not a direct function of Load Balancer)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure Load Balancer?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Higher uptime for customer-facing services<\/strong>: multiple instances behind one stable IP reduces outage risk.<\/li>\n<li><strong>Predictable scaling<\/strong>: add instances behind the load balancer without changing client configuration.<\/li>\n<li><strong>Lower operational overhead<\/strong> compared to self-managed L4 load balancers for many scenarios.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Layer 4 performance and low latency<\/strong>: suitable for high-throughput TCP\/UDP services.<\/li>\n<li><strong>Works for non-HTTP protocols<\/strong>: game servers, IoT gateways, DNS, SMTP relays, custom TCP APIs.<\/li>\n<li><strong>Supports internal and public entry points<\/strong> using the same conceptual model.<\/li>\n<li><strong>Health-based distribution<\/strong>: avoids sending new connections to unhealthy targets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Repeatable deployments<\/strong> with ARM\/Bicep\/Terraform\/Azure CLI.<\/li>\n<li><strong>Integration with Azure monitoring<\/strong> (metrics and diagnostic logs\u2014availability may vary by region and SKU; verify).<\/li>\n<li><strong>Supports zone-aware designs<\/strong>: helps meet resiliency requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security and compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduces exposed surface area<\/strong>: you can expose only the load balancer frontend and keep backends private.<\/li>\n<li>Works with <strong>NSGs<\/strong>, <strong>Azure Policy<\/strong>, and standard Azure governance tools.<\/li>\n<li>Supports architectures that align with common compliance patterns (segmentation, controlled ingress\/egress).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability and performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Designed for <strong>high scale<\/strong> and <strong>high availability<\/strong> within a region.<\/li>\n<li>Works naturally with <strong>VM Scale Sets<\/strong> for horizontal scaling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Azure Load Balancer when you need:\n&#8211; L4 load balancing for TCP\/UDP\n&#8211; A single stable frontend IP (public or private)\n&#8211; High throughput, low latency distribution\n&#8211; Simple, robust primitives that pair well with VMSS and zonal resiliency<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid Azure Load Balancer when:\n&#8211; You need <strong>HTTP routing features<\/strong> such as path-based routing, TLS termination, WAF, cookie affinity at L7, header rewrites<br\/>\n  \u2192 Consider <strong>Azure Application Gateway<\/strong> (regional L7) or <strong>Azure Front Door<\/strong> (global L7).\n&#8211; You need <strong>global<\/strong> multi-region load balancing with automatic edge entry<br\/>\n  \u2192 Consider <strong>Azure Front Door<\/strong> or <strong>Traffic Manager<\/strong> (DNS-based).\n&#8211; You need deep <strong>service-to-service<\/strong> traffic management inside Kubernetes (mTLS, retries, circuit breaking)<br\/>\n  \u2192 Consider service mesh (Istio\/Linkerd) and Kubernetes ingress\/gateway patterns.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Load Balancer used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and enterprise software<\/li>\n<li>Gaming (UDP\/TCP matchmaking and game server fleets)<\/li>\n<li>Financial services (internal L4 distribution, low-latency systems)<\/li>\n<li>Retail\/e-commerce (supporting tier-0\/tier-1 services behind stable endpoints)<\/li>\n<li>Telecommunications and IoT (TCP\/UDP gateways, device ingress)<\/li>\n<li>Media streaming (protocols and workloads that need L4 distribution)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineering and platform teams<\/li>\n<li>SRE\/operations teams managing VM-based fleets<\/li>\n<li>DevOps teams building CI\/CD for infrastructure<\/li>\n<li>Security teams designing segmented network perimeters<\/li>\n<li>Developers running stateful or custom protocol services on VMs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM-based web frontends when L7 isn\u2019t required (or when TLS is terminated elsewhere)<\/li>\n<li>Custom TCP\/UDP services<\/li>\n<li>Internal APIs and microservices on VMs<\/li>\n<li>NVAs and network middleboxes (advanced patterns; validate with current docs)<\/li>\n<li>Bastion-like access patterns via inbound NAT rules (with caution; often better alternatives exist)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Two-tier and three-tier VM architectures<\/li>\n<li>Hub-and-spoke networks (ILBs for internal services)<\/li>\n<li>Blue\/green deployments (swap backend pool membership)<\/li>\n<li>Zonal active-active within a region<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Standard SKU, zone-redundant frontends where supported, strong NSG and monitoring posture.<\/li>\n<li><strong>Dev\/test<\/strong>: can still use Standard SKU; cost differences should be evaluated. If considering legacy SKUs, verify current status and retirement guidance in docs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Azure Load Balancer is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Public TCP load balancing for VM web servers (L4)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need a stable public IP and distribution across multiple web VMs.<\/li>\n<li><strong>Why this service fits:<\/strong> L4 distribution is simple and fast; health probes keep traffic off failed instances.<\/li>\n<li><strong>Example:<\/strong> Two or more NGINX VMs behind a public Azure Load Balancer on port 80\/443 (TLS termination could be on the VMs or upstream).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Internal load balancing for private APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Internal apps need a private endpoint to reach a pool of API servers.<\/li>\n<li><strong>Why it fits:<\/strong> Internal frontend IP in a subnet provides private-only access.<\/li>\n<li><strong>Example:<\/strong> An internal \u201corders-api\u201d on TCP 8443 accessible only inside the VNet via an ILB.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Highly available jump access via inbound NAT rules (carefully)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must reach individual VMs for management without giving each VM a public IP.<\/li>\n<li><strong>Why it fits:<\/strong> Inbound NAT rules map distinct frontend ports to specific backend VM ports.<\/li>\n<li><strong>Example:<\/strong> Frontend public IP:50001 \u2192 VM1:22, :50002 \u2192 VM2:22 (SSH). Prefer Azure Bastion for many enterprise cases; NAT rules are a tradeoff.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) UDP load balancing for gaming or telemetry ingestion<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You run UDP services that must scale out horizontally.<\/li>\n<li><strong>Why it fits:<\/strong> Azure Load Balancer supports UDP distribution.<\/li>\n<li><strong>Example:<\/strong> UDP\/3478 or custom UDP ports load balanced across a game server fleet.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) HA Ports for network virtual appliances (NVA) scenarios<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want to forward all ports to NVAs without defining individual rules.<\/li>\n<li><strong>Why it fits:<\/strong> HA Ports simplifies \u201call ports\u201d distribution for advanced networking appliances.<\/li>\n<li><strong>Example:<\/strong> Internal LB with HA Ports in front of firewall NVAs to distribute east-west flows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Backend pool for VM Scale Sets (VMSS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need elastic scale with a stable endpoint.<\/li>\n<li><strong>Why it fits:<\/strong> VMSS integrates naturally with backend pools; autoscale adds\/removes instances.<\/li>\n<li><strong>Example:<\/strong> VMSS of stateless API servers behind a public Standard Load Balancer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) East-west load balancing in microservices on VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple service instances need a stable address for service discovery without deploying a full mesh.<\/li>\n<li><strong>Why it fits:<\/strong> ILB provides a stable private IP.<\/li>\n<li><strong>Example:<\/strong> \u201cinventory-service\u201d ILB at 10.10.2.10 distributing to 6 VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Outbound SNAT control (Standard SKU outbound rules)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Outbound connections fail or are throttled due to SNAT port exhaustion or unpredictable egress.<\/li>\n<li><strong>Why it fits:<\/strong> Outbound rules can centralize and control SNAT behavior and public egress identity.<\/li>\n<li><strong>Example:<\/strong> Backend pool egresses through specific public IP(s) for allowlisting third-party services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) High availability for legacy line-of-business apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A legacy app can only be deployed on VMs and expects a fixed endpoint.<\/li>\n<li><strong>Why it fits:<\/strong> Azure Load Balancer provides stable IP and failover within the pool.<\/li>\n<li><strong>Example:<\/strong> A TCP-based proprietary protocol on port 31000 distributed across active-active app servers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Split-horizon endpoints (internal and public)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Same service needs private access for internal clients and public access for partners.<\/li>\n<li><strong>Why it fits:<\/strong> Use separate LBs or frontends depending on design; keep policies separate.<\/li>\n<li><strong>Example:<\/strong> Public LB for partner ingress; internal LB for internal workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Migration bridge for data center to Azure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You migrate VM workloads and need a familiar load balancer pattern.<\/li>\n<li><strong>Why it fits:<\/strong> Azure Load Balancer mirrors classic L4 LB patterns used on-prem.<\/li>\n<li><strong>Example:<\/strong> Lift-and-shift IIS\/NGINX farm behind a load balancer with minimal app changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Internal DNS \/ directory services distribution (carefully)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Clients need a single endpoint for redundant internal infrastructure services.<\/li>\n<li><strong>Why it fits:<\/strong> ILB provides stable private IP and health checks.<\/li>\n<li><strong>Example:<\/strong> Internal TCP 53\/UDP 53 distribution (validate protocol behaviors carefully; not all stateful protocols load-balance well without session awareness).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: Feature availability can vary by SKU (Basic vs Standard), region, and backend type (VM vs VMSS). Always confirm in official docs for your exact design.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Public and internal load balancing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides either a public frontend (internet-facing) or a private frontend (internal VNet).<\/li>\n<li><strong>Why it matters:<\/strong> Enables secure segmentation\u2014public entry where needed, private-only endpoints otherwise.<\/li>\n<li><strong>Practical benefit:<\/strong> Keep backend VMs private; expose only the load balancer.<\/li>\n<li><strong>Caveats:<\/strong> Internal LBs are reachable only within connected networks (VNet peering\/VPN\/ExpressRoute). Ensure routing and NSGs allow it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Layer 4 distribution (TCP\/UDP)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Distributes flows based on 5-tuple hashing (source\/destination IP\/port + protocol) rather than HTTP content.<\/li>\n<li><strong>Why it matters:<\/strong> Works for any TCP\/UDP service, not just web.<\/li>\n<li><strong>Practical benefit:<\/strong> High performance and protocol flexibility.<\/li>\n<li><strong>Caveats:<\/strong> No native L7 features (no URL-based routing, no header logic, no WAF, no TLS offload).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Health probes (TCP or HTTP)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Checks backend instance health and only sends new flows to healthy targets.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents blackholing traffic to dead instances.<\/li>\n<li><strong>Practical benefit:<\/strong> Automated failover inside a backend pool.<\/li>\n<li><strong>Caveats:<\/strong> Probes must be allowed by NSG rules. HTTP probes require a valid HTTP response from the backend path\/port.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Load-balancing rules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Maps frontend IP:port \u2192 backend pool:port using a health probe.<\/li>\n<li><strong>Why it matters:<\/strong> This is the core traffic distribution mechanism.<\/li>\n<li><strong>Practical benefit:<\/strong> Clean, predictable port mapping and distribution.<\/li>\n<li><strong>Caveats:<\/strong> Ensure backend port is open on OS firewall and NSG.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Inbound NAT rules (and NAT pools)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Maps unique frontend ports to a specific backend VM (or NIC) port.<\/li>\n<li><strong>Why it matters:<\/strong> Enables per-instance access without public IPs on every VM.<\/li>\n<li><strong>Practical benefit:<\/strong> Simplifies limited management access patterns.<\/li>\n<li><strong>Caveats:<\/strong> Security risk if misused. Prefer <strong>Azure Bastion<\/strong> or private management networks for enterprise environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Outbound rules (Standard SKU)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls outbound SNAT for a backend pool to reach the internet via designated public IPs\/prefixes.<\/li>\n<li><strong>Why it matters:<\/strong> Helps prevent unpredictable egress behavior and supports IP allowlisting.<\/li>\n<li><strong>Practical benefit:<\/strong> Stable egress IP(s) for compliance and partner integrations.<\/li>\n<li><strong>Caveats:<\/strong> Understand SNAT port limits and outbound connectivity design. Also consider <strong>NAT Gateway<\/strong> as an alternative for outbound-only scenarios.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 High availability and scale (Standard SKU patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides resilient L4 load balancing and supports high scale backends (commonly VMSS).<\/li>\n<li><strong>Why it matters:<\/strong> Production workloads need predictable availability.<\/li>\n<li><strong>Practical benefit:<\/strong> Handles instance failures and maintenance events.<\/li>\n<li><strong>Caveats:<\/strong> Design must include backend redundancy (multiple instances, preferably across zones).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Availability Zones support (zonal \/ zone-redundant)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows zone-aware frontends (and in many designs, zone-redundant frontends).<\/li>\n<li><strong>Why it matters:<\/strong> Zone failures are a real risk; zone redundancy improves resilience.<\/li>\n<li><strong>Practical benefit:<\/strong> Higher availability for regionally deployed services.<\/li>\n<li><strong>Caveats:<\/strong> Zone support varies by region and by resource type (Public IP, Load Balancer SKU). Verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 Floating IP \/ direct server return (advanced)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports scenarios where backend receives traffic with original destination IP\/port (common in some NVA\/cluster designs).<\/li>\n<li><strong>Why it matters:<\/strong> Required for certain active-active appliances and failover clusters.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables advanced network architectures.<\/li>\n<li><strong>Caveats:<\/strong> Advanced; requires careful backend configuration. Validate with official docs and vendor guidance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.10 Diagnostics and metrics (Azure Monitor integration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Exposes metrics and (where supported) logs for health probes, data path, rule counters, etc.<\/li>\n<li><strong>Why it matters:<\/strong> You need observability to operate reliably.<\/li>\n<li><strong>Practical benefit:<\/strong> Alert on backend health, troubleshoot traffic distribution, capacity planning.<\/li>\n<li><strong>Caveats:<\/strong> Exact metrics\/log categories can change; confirm in your region\/SKU and in Azure Monitor docs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">7.1 High-level architecture<\/h3>\n\n\n\n<p>Azure Load Balancer sits between clients and backend endpoints.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data plane:<\/strong> Client traffic flows to the load balancer frontend IP and is forwarded to backend instances based on rules and distribution logic.<\/li>\n<li><strong>Control plane:<\/strong> You configure the load balancer resource (frontends, backend pools, probes, rules) using Azure Resource Manager through Portal, CLI, ARM\/Bicep, Terraform, etc.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.2 Request\/data\/control flow (inbound)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Client resolves DNS to the load balancer <strong>frontend IP<\/strong> (public or private).<\/li>\n<li>Client opens a TCP\/UDP connection to frontend IP:port.<\/li>\n<li>Load balancer selects a backend instance from the <strong>backend pool<\/strong> according to hashing\/distribution.<\/li>\n<li>Load balancer forwards traffic to the backend instance IP:port.<\/li>\n<li>Backend responds; flows continue to be pinned for the life of the connection (typical for L4).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">7.3 Health probing flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Load balancer sends probe requests to each backend target on the configured probe port\/path.<\/li>\n<li>If probes fail beyond threshold, the backend is marked unhealthy and removed from rotation for new flows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.4 Integrations with related services<\/h3>\n\n\n\n<p>Common integrations:\n&#8211; <strong>Azure Virtual Network (VNet)<\/strong>: required context for backends and ILB frontends.\n&#8211; <strong>Network Security Groups (NSGs)<\/strong>: control traffic to\/from NICs\/subnets; must allow LB probes and traffic.\n&#8211; <strong>Public IP \/ Public IP Prefix<\/strong>: required for public frontends and stable egress identities.\n&#8211; <strong>VM Scale Sets (VMSS)<\/strong>: attach to backend pool for elastic scaling.\n&#8211; <strong>Azure Monitor<\/strong>: metrics, diagnostic settings, alerts.\n&#8211; <strong>Azure Firewall \/ NVAs<\/strong>: used in hub-and-spoke or inspection patterns; sometimes combined with load balancers (design-specific).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7.5 Dependency services<\/h3>\n\n\n\n<p>At minimum, most designs require:\n&#8211; Resource group\n&#8211; VNet + subnet\n&#8211; Backend compute: VMs\/VMSS\n&#8211; NICs\n&#8211; NSG rules\n&#8211; Public IP (for public LB)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7.6 Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Management operations are controlled by <strong>Azure RBAC<\/strong> on the load balancer resource and related resources (VNet, Public IP, NICs).<\/li>\n<li>Data plane traffic is controlled primarily by:<\/li>\n<li>Load balancer rules\/NAT rules<\/li>\n<li>NSGs on subnets\/NICs<\/li>\n<li>OS firewalls on backends<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.7 Networking model notes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Load Balancer is not a proxy in the same sense as an L7 gateway; it distributes L4 flows.<\/li>\n<li>Backends are typically identified via NIC IP configurations.<\/li>\n<li>For public inbound, the backend VMs commonly do <strong>not<\/strong> need public IP addresses.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.8 Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Azure Monitor metrics and alerts for:<\/li>\n<li>probe health (unhealthy instances)<\/li>\n<li>data path availability indicators (where available)<\/li>\n<li>traffic counters (where available)<\/li>\n<li>Use Azure Policy for enforcing:<\/li>\n<li>Standard SKU (if that\u2019s your org standard)<\/li>\n<li>Diagnostic settings configured to Log Analytics \/ Storage<\/li>\n<li>Required tags (owner, cost center, environment)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.9 Mermaid diagrams<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Simple architecture diagram<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Client[Client on Internet] --&gt;|TCP\/80| PIP[(Public IP)]\n  PIP --&gt; LB[Azure Load Balancer\\nPublic Frontend]\n  LB --&gt; VM1[VM1: NGINX]\n  LB --&gt; VM2[VM2: NGINX]\n  LB -. health probe .-&gt; VM1\n  LB -. health probe .-&gt; VM2\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style reference diagram (zonal, monitoring, outbound)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Internet\n    Users[Users\/Partners]\n  end\n\n  subgraph AzureRegion[Azure Region]\n    DNS[Public DNS] --&gt; PIP[(Standard Public IP\\nZone-redundant)]\n    Users --&gt; PIP\n\n    PIP --&gt; SLB[Azure Load Balancer (Standard)\\nPublic Frontend]\n\n    subgraph VNet[Spoke VNet]\n      subgraph SubnetWeb[Web Subnet]\n        VMSS[(VM Scale Set\\nInstances across Zones)]\n        NSG1[NSG: allow 80\/443\\nallow AzureLoadBalancer probe]\n      end\n\n      SLB --&gt; VMSS\n      NSG1 --- VMSS\n\n      subgraph SubnetMgmt[Management Subnet]\n        Jump[Private admin access\\n(Bastion\/Jump host)]\n      end\n    end\n\n    SLB -.metrics\/logs.-&gt; Monitor[Azure Monitor\\nMetrics + Logs]\n    VMSS -.boot\/agent logs.-&gt; Monitor\n\n    VMSS --&gt;|Outbound via rule or alternative| Outbound[(Outbound Public IP\/Prefix)]\n  end\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Azure account and subscription<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong> with billing enabled.<\/li>\n<li>Ability to create resources in a resource group in your chosen region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions (IAM \/ RBAC)<\/h3>\n\n\n\n<p>For the hands-on lab (CLI-based), you typically need one of:\n&#8211; <strong>Owner<\/strong> or <strong>Contributor<\/strong> on the subscription\/resource group, plus\n&#8211; Permissions to create and manage:\n  &#8211; Resource groups\n  &#8211; VNets\/subnets\n  &#8211; NSGs\n  &#8211; Public IPs\n  &#8211; Load balancers\n  &#8211; VMs \/ availability sets (or VMSS)<\/p>\n\n\n\n<p>Least-privilege note: In production, split duties between network and compute roles; apply RBAC at resource group scope.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Load Balancer (especially Standard) is billable.<\/li>\n<li>VMs, disks, public IPs, and outbound data transfer are also billable.<\/li>\n<li>Ensure you understand cost before leaving resources running.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<p>Choose one:\n&#8211; <strong>Azure Portal<\/strong> (browser)\n&#8211; <strong>Azure CLI<\/strong> (used in this tutorial): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli\n&#8211; Optional: <strong>SSH client<\/strong> if you plan to connect to VMs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Load Balancer is broadly available. Availability Zones support depends on region.<\/li>\n<li>Verify regional support for zones and SKUs:<\/li>\n<li>https:\/\/learn.microsoft.com\/azure\/reliability\/availability-zones-service-support (general reference; verify the exact page for current coverage)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Common quotas you may hit:\n&#8211; vCPU quota for your VM family\n&#8211; Public IP address quotas\n&#8211; Regional resource limits<\/p>\n\n\n\n<p>Check quotas:\n&#8211; In Portal: <strong>Subscriptions \u2192 Usage + quotas<\/strong>\n&#8211; Or verify via Azure CLI (quota commands vary by resource provider; often simplest in Portal).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services for the lab<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VNet + subnet<\/li>\n<li>NSG<\/li>\n<li>Two Linux VMs (or a VMSS)<\/li>\n<li>Public IP (Standard recommended)<\/li>\n<li>Azure Load Balancer (Standard recommended)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<blockquote>\n<p>Pricing changes and differs by region\/currency\/contract. Do not rely on static numbers in articles. Use the official pricing page and calculator for accurate estimates.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing resources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Load Balancer pricing: https:\/\/azure.microsoft.com\/pricing\/details\/load-balancer\/<\/li>\n<li>Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you get billed)<\/h3>\n\n\n\n<p>Azure Load Balancer pricing typically depends on some combination of:\n&#8211; <strong>SKU<\/strong> (Basic vs Standard; Standard is the normal production choice)\n&#8211; <strong>Time-based charges<\/strong> (e.g., per hour of provisioned load balancer and\/or rules)\n&#8211; <strong>Rule count<\/strong> (configured load-balancing rules, inbound NAT rules, outbound rules)\n&#8211; <strong>Data processed<\/strong> (GB processed through the load balancer)<\/p>\n\n\n\n<p>Because these dimensions can be updated by Microsoft, <strong>verify the exact meters on the official pricing page<\/strong> for your region and SKU.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Historically, <strong>Basic Load Balancer<\/strong> has often been described as having no direct hourly charge, while <strong>Standard<\/strong> is billed. However:\n&#8211; Basic is legacy guidance in many environments and may be subject to retirement timelines.\n&#8211; Always confirm current pricing and availability in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers (what makes the bill go up)<\/h3>\n\n\n\n<p>Direct:\n&#8211; Running <strong>Standard Load Balancer<\/strong> continuously\n&#8211; More <strong>rules<\/strong> (LB rules, NAT rules, outbound rules)\n&#8211; High <strong>data processing<\/strong> volumes<\/p>\n\n\n\n<p>Indirect:\n&#8211; <strong>Public IP<\/strong> resources (especially Standard Public IP)\n&#8211; <strong>VM compute<\/strong> (often the biggest cost)\n&#8211; <strong>Managed disks<\/strong> and snapshots\n&#8211; <strong>Outbound data transfer<\/strong> (egress to internet is usually charged)\n&#8211; <strong>Logging\/monitoring<\/strong> (Log Analytics ingestion and retention costs can be significant)\n&#8211; <strong>Availability Zones<\/strong> don\u2019t directly add LB cost, but they often encourage more instances and redundancy<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data processed by the load balancer may be billed (meter dependent).<\/li>\n<li>Internet egress from Azure is commonly billed. If you use outbound rules or NAT, you may create predictable egress identity but still pay egress charges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>internal load balancing<\/strong> for east-west traffic that doesn\u2019t need public exposure.<\/li>\n<li>Keep rule sets minimal: only the ports you need.<\/li>\n<li>If you mainly need outbound SNAT control for private subnets, evaluate <strong>Azure NAT Gateway<\/strong> as an alternative (cost model differs; compare using calculator).<\/li>\n<li>Turn on diagnostics thoughtfully:<\/li>\n<li>Send only needed logs\/metrics to Log Analytics<\/li>\n<li>Use sampling\/retention policies aligned to incident response requirements<\/li>\n<li>Right-size VM instances and scale sets; the compute cost often dwarfs the load balancer cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A low-cost lab typically includes:\n&#8211; 1 Standard Load Balancer\n&#8211; 1 Standard Public IP\n&#8211; 2 small Linux VMs (plus disks)\n&#8211; Minimal logging<\/p>\n\n\n\n<p>To estimate:\n1. Price the LB + Public IP per hour in your region.\n2. Price the two VMs and disks per hour\/month.\n3. Add expected data processing and outbound internet egress.\n4. Add monitoring\/log ingestion if enabled.<\/p>\n\n\n\n<p>Use:\n&#8211; https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, consider:\n&#8211; Multiple rules (80\/443, internal service ports, management NAT rules)\n&#8211; Larger backend pools (VMSS with many instances)\n&#8211; Higher throughput (data processed)\n&#8211; Monitoring at scale (Log Analytics + alerting)\n&#8211; Potential DDoS protection at the VNet\/public IP level (Azure DDoS Protection is a separate cost)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a <strong>public Standard Azure Load Balancer<\/strong> that distributes HTTP traffic across <strong>two Linux VMs<\/strong> running NGINX. You\u2019ll validate load balancing by returning each VM\u2019s hostname in the HTTP response.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a VNet and subnet<\/li>\n<li>Deploy a <strong>Standard Public IP<\/strong><\/li>\n<li>Deploy an <strong>Azure Load Balancer (Standard)<\/strong> with:<\/li>\n<li>frontend IP configuration<\/li>\n<li>backend pool<\/li>\n<li>health probe<\/li>\n<li>load-balancing rule (TCP\/80)<\/li>\n<li>Deploy two Ubuntu VMs into the backend pool<\/li>\n<li>Verify traffic distribution and probe health<\/li>\n<li>Clean up all resources<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p><strong>Client \u2192 Public IP \u2192 Azure Load Balancer \u2192 VM1\/VM2 (NGINX)<\/strong><\/p>\n\n\n\n<p>You will use <strong>Azure CLI<\/strong>. Commands are designed to be copy\/paste friendly. If any command errors due to API changes, <strong>verify with official CLI reference<\/strong>:\n&#8211; https:\/\/learn.microsoft.com\/cli\/azure\/network\/lb\n&#8211; https:\/\/learn.microsoft.com\/cli\/azure\/vm<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and create a resource group<\/h3>\n\n\n\n<pre><code class=\"language-bash\"># Log in (if not already)\naz login\n\n# (Optional) select subscription\naz account set --subscription \"&lt;YOUR_SUBSCRIPTION_ID&gt;\"\n\n# Variables\nRG=\"rg-alb-lab\"\nLOC=\"eastus\"   # choose a region near you\nVNET=\"vnet-alb-lab\"\nSUBNET=\"subnet-web\"\nNSG=\"nsg-web\"\nPIP=\"pip-alb-lab\"\nLB=\"alb-standard-lab\"\nFE=\"fe-public\"\nBE=\"be-web\"\nPROBE=\"probe-http\"\nRULE=\"rule-http-80\"\n\naz group create --name \"$RG\" --location \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Resource group is created.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group show -n \"$RG\" --query \"{name:name,location:location}\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create VNet, subnet, and NSG<\/h3>\n\n\n\n<p>Create the VNet and subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet create \\\n  --resource-group \"$RG\" \\\n  --name \"$VNET\" \\\n  --address-prefixes 10.10.0.0\/16 \\\n  --subnet-name \"$SUBNET\" \\\n  --subnet-prefixes 10.10.1.0\/24\n<\/code><\/pre>\n\n\n\n<p>Create an NSG and rules:\n&#8211; Allow inbound HTTP (80) from internet\n&#8211; Allow the Azure Load Balancer probe (service tag <code>AzureLoadBalancer<\/code>) to reach port 80<br\/>\n  (This is a common requirement; probe source handling can vary by scenario\u2014verify in docs if your architecture is different.)<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg create \\\n  --resource-group \"$RG\" \\\n  --name \"$NSG\"\n\n# Allow HTTP from Internet\naz network nsg rule create \\\n  --resource-group \"$RG\" \\\n  --nsg-name \"$NSG\" \\\n  --name allow-http-internet \\\n  --priority 100 \\\n  --direction Inbound \\\n  --access Allow \\\n  --protocol Tcp \\\n  --source-address-prefixes Internet \\\n  --destination-port-ranges 80\n\n# Allow health probes from AzureLoadBalancer tag\naz network nsg rule create \\\n  --resource-group \"$RG\" \\\n  --nsg-name \"$NSG\" \\\n  --name allow-probe-azureloadbalancer \\\n  --priority 110 \\\n  --direction Inbound \\\n  --access Allow \\\n  --protocol Tcp \\\n  --source-address-prefixes AzureLoadBalancer \\\n  --destination-port-ranges 80\n<\/code><\/pre>\n\n\n\n<p>Associate the NSG to the subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet update \\\n  --resource-group \"$RG\" \\\n  --vnet-name \"$VNET\" \\\n  --name \"$SUBNET\" \\\n  --network-security-group \"$NSG\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Subnet is protected by NSG rules allowing HTTP and LB probes.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet show -g \"$RG\" --vnet-name \"$VNET\" -n \"$SUBNET\" \\\n  --query \"{subnet:name,nsg:networkSecurityGroup.id}\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a Standard Public IP<\/h3>\n\n\n\n<p>Standard Load Balancer typically pairs with <strong>Standard Public IP<\/strong>.<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network public-ip create \\\n  --resource-group \"$RG\" \\\n  --name \"$PIP\" \\\n  --sku Standard \\\n  --allocation-method Static\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A static public IP is created.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network public-ip show -g \"$RG\" -n \"$PIP\" --query \"{ip:ipAddress,sku:sku.name}\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create the Azure Load Balancer (Standard) and frontend\/backend<\/h3>\n\n\n\n<p>Create the load balancer:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network lb create \\\n  --resource-group \"$RG\" \\\n  --name \"$LB\" \\\n  --sku Standard \\\n  --public-ip-address \"$PIP\" \\\n  --frontend-ip-name \"$FE\" \\\n  --backend-pool-name \"$BE\"\n<\/code><\/pre>\n\n\n\n<p>Create a health probe (HTTP probe to <code>\/<\/code> on port 80):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network lb probe create \\\n  --resource-group \"$RG\" \\\n  --lb-name \"$LB\" \\\n  --name \"$PROBE\" \\\n  --protocol Http \\\n  --port 80 \\\n  --path \/\n<\/code><\/pre>\n\n\n\n<p>Create a load-balancing rule for TCP\/80:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network lb rule create \\\n  --resource-group \"$RG\" \\\n  --lb-name \"$LB\" \\\n  --name \"$RULE\" \\\n  --protocol Tcp \\\n  --frontend-port 80 \\\n  --backend-port 80 \\\n  --frontend-ip-name \"$FE\" \\\n  --backend-pool-name \"$BE\" \\\n  --probe-name \"$PROBE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The load balancer is ready to distribute HTTP traffic to whatever is in the backend pool.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network lb show -g \"$RG\" -n \"$LB\" \\\n  --query \"{sku:sku.name,frontends:length(frontendIpConfigurations),backends:length(backendAddressPools),rules:length(loadBalancingRules)}\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create two VMs and attach them to the backend pool<\/h3>\n\n\n\n<p>We will create:\n&#8211; An availability set (optional but common for VM pairs)\n&#8211; Two Ubuntu VMs without public IPs\n&#8211; NICs connected to the backend pool\n&#8211; Cloud-init to install NGINX and return hostname<\/p>\n\n\n\n<p>Create an availability set:<\/p>\n\n\n\n<pre><code class=\"language-bash\">AVSET=\"avset-alb-lab\"\naz vm availability-set create -g \"$RG\" -n \"$AVSET\"\n<\/code><\/pre>\n\n\n\n<p>Create a cloud-init file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; cloud-init-nginx.yml &lt;&lt;'EOF'\n#cloud-config\npackage_update: true\npackages:\n  - nginx\nwrite_files:\n  - path: \/var\/www\/html\/index.html\n    owner: root:root\n    permissions: '0644'\n    content: |\n      &lt;html&gt;\n      &lt;body&gt;\n      &lt;h1&gt;Azure Load Balancer backend&lt;\/h1&gt;\n      &lt;p&gt;Hostname: __HOSTNAME__&lt;\/p&gt;\n      &lt;\/body&gt;\n      &lt;\/html&gt;\nruncmd:\n  - HOST=$(hostname)\n  - sed -i \"s\/__HOSTNAME__\/${HOST}\/g\" \/var\/www\/html\/index.html\n  - systemctl enable nginx\n  - systemctl restart nginx\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create the two VMs and place their NICs into the backend pool:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ADMIN=\"azureuser\"\nSSHKEY=\"$HOME\/.ssh\/id_rsa.pub\"   # adjust if needed\n\nfor i in 1 2; do\n  VM=\"vm-web-$i\"\n\n  az vm create \\\n    --resource-group \"$RG\" \\\n    --name \"$VM\" \\\n    --image Ubuntu2204 \\\n    --size Standard_B1s \\\n    --admin-username \"$ADMIN\" \\\n    --ssh-key-values \"$SSHKEY\" \\\n    --vnet-name \"$VNET\" \\\n    --subnet \"$SUBNET\" \\\n    --public-ip-address \"\" \\\n    --availability-set \"$AVSET\" \\\n    --custom-data cloud-init-nginx.yml \\\n    --nsg \"\"  # we already attached NSG to subnet\ndone\n<\/code><\/pre>\n\n\n\n<p>Now add each VM NIC to the LB backend pool. First, find NIC names:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm list -g \"$RG\" -o table\naz network nic list -g \"$RG\" -o table\n<\/code><\/pre>\n\n\n\n<p>Attach NIC IP configurations to backend pool (commonly <code>ipconfig1<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">for i in 1 2; do\n  VM=\"vm-web-$i\"\n  NIC=$(az vm show -g \"$RG\" -n \"$VM\" --query \"networkProfile.networkInterfaces[0].id\" -o tsv | awk -F\/ '{print $NF}')\n  az network nic ip-config address-pool add \\\n    --resource-group \"$RG\" \\\n    --nic-name \"$NIC\" \\\n    --ip-config-name ipconfig1 \\\n    --lb-name \"$LB\" \\\n    --address-pool \"$BE\"\ndone\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Both VMs are running NGINX and are registered in the backend pool.<\/p>\n\n\n\n<p>Verify backend pool association:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network lb address-pool show -g \"$RG\" --lb-name \"$LB\" -n \"$BE\" --query \"backendIpConfigurations[].id\" -o tsv\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Test from the internet (HTTP)<\/h3>\n\n\n\n<p>Get the load balancer public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">LB_IP=$(az network public-ip show -g \"$RG\" -n \"$PIP\" --query ipAddress -o tsv)\necho \"$LB_IP\"\n<\/code><\/pre>\n\n\n\n<p>Test with curl:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s \"http:\/\/$LB_IP\" | sed -n '1,10p'\n<\/code><\/pre>\n\n\n\n<p>Run multiple times to observe distribution:<\/p>\n\n\n\n<pre><code class=\"language-bash\">for x in {1..6}; do\n  echo \"Request $x\"\n  curl -s \"http:\/\/$LB_IP\" | grep -i Hostname\n  sleep 1\ndone\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You should see <strong>Hostname: vm-web-1<\/strong> and <strong>Hostname: vm-web-2<\/strong> appear across requests (exact distribution may not alternate perfectly because L4 hashing can stick flows based on client tuple; using separate connections helps).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use these checks to confirm health and data path.<\/p>\n\n\n\n<p>1) Confirm both VMs are running:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm get-instance-view -g \"$RG\" -n vm-web-1 --query \"instanceView.statuses[?starts_with(code,'PowerState')].displayStatus\" -o tsv\naz vm get-instance-view -g \"$RG\" -n vm-web-2 --query \"instanceView.statuses[?starts_with(code,'PowerState')].displayStatus\" -o tsv\n<\/code><\/pre>\n\n\n\n<p>2) Confirm NGINX is running (via Run Command):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm run-command invoke -g \"$RG\" -n vm-web-1 --command-id RunShellScript --scripts \"systemctl is-active nginx &amp;&amp; hostname\"\naz vm run-command invoke -g \"$RG\" -n vm-web-2 --command-id RunShellScript --scripts \"systemctl is-active nginx &amp;&amp; hostname\"\n<\/code><\/pre>\n\n\n\n<p>3) Confirm the LB rule and probe exist:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network lb rule show -g \"$RG\" --lb-name \"$LB\" -n \"$RULE\" -o table\naz network lb probe show -g \"$RG\" --lb-name \"$LB\" -n \"$PROBE\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>Curl times out \/ connection fails<\/strong>\n&#8211; Check NSG rules allow inbound TCP\/80 from Internet.\n&#8211; Confirm you created a <strong>public<\/strong> LB frontend with a <strong>Public IP<\/strong> and that you are using that IP.\n&#8211; Verify backend VMs are in the correct subnet and running.<\/p>\n\n\n\n<p>2) <strong>Health probe shows unhealthy (traffic not reaching backends)<\/strong>\n&#8211; Make sure NSG allows the probe source:\n  &#8211; Allow from <code>AzureLoadBalancer<\/code> service tag to probe port (80 in this lab).\n&#8211; Ensure NGINX is actually listening on port 80:\n  &#8211; <code>az vm run-command invoke ... \"ss -lntp | grep :80\"<\/code>\n&#8211; If using an HTTP probe with a path, ensure the path returns <strong>HTTP 200<\/strong> (or at least a valid response per probe expectations).<\/p>\n\n\n\n<p>3) <strong>Backend pool attachment didn\u2019t work<\/strong>\n&#8211; Double-check NIC and IP config names:\n  &#8211; Many NICs use <code>ipconfig1<\/code>, but confirm with:\n    <code>bash\n    az network nic show -g \"$RG\" -n \"&lt;NIC_NAME&gt;\" --query \"ipConfigurations[].name\" -o tsv<\/code>\n&#8211; Confirm the pool is referenced correctly by name.<\/p>\n\n\n\n<p>4) <strong>You don\u2019t see traffic \u201calternating\u201d<\/strong>\n&#8211; Load balancing is flow-based. Repeated requests might reuse connections depending on client behavior.\n&#8211; Use fresh TCP connections (curl typically does) and wait between requests.\n&#8211; For strict test behavior, use multiple client sources or explicitly disable keepalive in your client.<\/p>\n\n\n\n<p>5) <strong>SSH access to VMs<\/strong>\n&#8211; In this lab, VMs have <strong>no public IPs<\/strong>, so SSH from internet won\u2019t work directly.\n&#8211; For secure access, use <strong>Azure Bastion<\/strong> or a private jump host in a management subnet. (Not required for this lab.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete --name \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p>Verify deletion (may take a few minutes):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group exists --name \"$RG\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>Standard SKU<\/strong> for production and enterprise workloads.<\/li>\n<li>Design for redundancy:<\/li>\n<li>Use <strong>VM Scale Sets<\/strong> or multiple VMs across fault domains<\/li>\n<li>Use <strong>Availability Zones<\/strong> where supported (zone-redundant frontends where appropriate)<\/li>\n<li>Use <strong>internal load balancers<\/strong> for east-west traffic and reserve public exposure for truly public endpoints.<\/li>\n<li>For HTTP(S) features (TLS offload\/WAF\/path routing), use <strong>Application Gateway<\/strong> or <strong>Front Door<\/strong> instead of forcing it into Load Balancer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce least privilege with RBAC:<\/li>\n<li>Network team controls LB\/VNet\/NSG<\/li>\n<li>App team controls VMs\/VMSS<\/li>\n<li>Use Azure Policy to require:<\/li>\n<li>Standard SKU (if that\u2019s your baseline)<\/li>\n<li>Required tags<\/li>\n<li>Diagnostics settings (where feasible)<\/li>\n<li>Avoid exposing management ports via inbound NAT rules unless necessary; prefer <strong>Azure Bastion<\/strong> and private management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t leave dev\/test load balancers and VMs running unnecessarily.<\/li>\n<li>Keep rule count minimal; remove old NAT rules and unused LB rules.<\/li>\n<li>Monitor and manage outbound data transfer and SNAT-related designs:<\/li>\n<li>Consider <strong>NAT Gateway<\/strong> when you primarily need outbound.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep backends healthy and responsive; probe configuration should reflect real service health.<\/li>\n<li>Avoid overly aggressive probe intervals that create unnecessary overhead; avoid overly slow intervals that delay failover.<\/li>\n<li>For high-scale scenarios, prefer VMSS and consider distribution and zone placement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use at least <strong>two<\/strong> backend instances (minimum for meaningful HA).<\/li>\n<li>Align probe type with app reality:<\/li>\n<li>TCP probe for \u201cport open\u201d<\/li>\n<li>HTTP probe for \u201cservice healthy\u201d (returns expected response)<\/li>\n<li>Implement graceful shutdown on backends so draining\/maintenance doesn\u2019t cut active users unexpectedly (application responsibility; LB is L4).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Azure Monitor alerts:<\/li>\n<li>backend health degradation<\/li>\n<li>unusual drops in traffic counters (where available)<\/li>\n<li>Maintain runbooks:<\/li>\n<li>how to swap backends<\/li>\n<li>how to roll updates safely<\/li>\n<li>how to identify unhealthy instances and remediate<\/li>\n<li>Tag resources: <code>app<\/code>, <code>env<\/code>, <code>owner<\/code>, <code>costCenter<\/code>, <code>dataClassification<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/naming best practices<\/h3>\n\n\n\n<p>Use consistent naming, for example:\n&#8211; <code>lb-{app}-{env}-{region}<\/code>\n&#8211; <code>pip-{app}-{env}-{region}<\/code>\n&#8211; <code>nsg-{tier}-{app}-{env}<\/code>\nUse consistent tags and consider Azure Policy enforcement.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed via <strong>Azure Resource Manager<\/strong> and <strong>Azure RBAC<\/strong>.<\/li>\n<li>Key permissions typically involve <code>Microsoft.Network\/loadBalancers\/*<\/code>, plus related resources (Public IPs, VNets, NICs).<\/li>\n<li>Use custom roles if built-in roles are too broad.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Load Balancer is L4 and does not terminate TLS by itself.<\/li>\n<li>Encryption in transit (TLS) is handled by:<\/li>\n<li>the backend application (TLS on the VM), or<\/li>\n<li>an upstream L7 service like Application Gateway\/Front Door.<\/li>\n<li>Encryption at rest is not applicable to the load balancer itself, but is relevant for VM disks\/log stores.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public load balancer frontends are internet reachable by default; restrict with:<\/li>\n<li>NSG rules (source IP restrictions)<\/li>\n<li>DDoS Protection (separate service) if required<\/li>\n<li>Upstream WAF at L7 (Application Gateway\/Front Door) for HTTP(S)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding secrets in VM custom data or scripts.<\/li>\n<li>Use <strong>Azure Key Vault<\/strong> for secrets and certificates, and managed identities for access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use:<\/li>\n<li>Azure Activity Log for control plane operations (who changed LB rules)<\/li>\n<li>Azure Monitor metrics and (where supported) resource logs for data-plane insights<\/li>\n<li>Send logs to Log Analytics or a SIEM (Microsoft Sentinel) according to policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Maintain documentation for:<\/li>\n<li>exposed endpoints (ports, protocols)<\/li>\n<li>NSG rules and change approvals<\/li>\n<li>egress IPs for partner allowlisting<\/li>\n<li>For regulated industries, implement least-privilege RBAC, change control, and log retention requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allowing <code>0.0.0.0\/0<\/code> to management ports via NAT rules<\/li>\n<li>Forgetting to lock down NSGs because \u201cthe load balancer is the firewall\u201d (it is not)<\/li>\n<li>Using public IPs on backend VMs unnecessarily<\/li>\n<li>Not controlling outbound egress identity and then failing partner allowlists (or causing SNAT exhaustion)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer private backends with no public IPs.<\/li>\n<li>Use Azure Bastion or private access for management.<\/li>\n<li>Restrict inbound sources at NSG and\/or upstream L7.<\/li>\n<li>Turn on diagnostics and establish alerting for backend health.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Some items below depend on SKU and region. Validate against official docs for your exact scenario.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Layer 4 only<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>No URL\/path routing, no native TLS termination, no WAF.<\/li>\n<li>If you need L7 features, use Application Gateway or Front Door.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Flow-based behavior (not request-based)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Distribution is per flow\/connection. Sticky behaviors can occur due to hashing.<\/li>\n<li>Don\u2019t expect perfect round-robin per HTTP request.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Health probe pitfalls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Probes must be allowed through NSGs.<\/li>\n<li>HTTP probe path must return a valid response; incorrect path yields unhealthy backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Zonal design complexity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Zonal vs zone-redundant frontends can affect resiliency patterns.<\/li>\n<li>Ensure backend instances are placed across zones if your goal is zone resilience.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">SNAT and outbound connectivity surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Outbound connectivity design can cause unexpected issues (SNAT port exhaustion, unpredictable egress IP).<\/li>\n<li>Consider outbound rules or NAT Gateway depending on design goals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Rule sprawl<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many inbound NAT rules for management can become hard to govern and secure.<\/li>\n<li>Prefer structured management patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Legacy SKU risk<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you encounter <strong>Basic<\/strong> guidance, treat it as legacy and <strong>verify current retirement\/availability<\/strong> in official docs before adopting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Observability gaps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>L4 load balancers provide limited \u201capplication insight\u201d compared to L7 gateways.<\/li>\n<li>You may need backend logs and APM tooling to troubleshoot application issues.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure Load Balancer is one tool in Azure Networking; choose based on OSI layer, scope (regional\/global), and features.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key alternatives (Azure)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Application Gateway<\/strong>: Regional L7 load balancer with TLS termination, WAF, HTTP routing.<\/li>\n<li><strong>Azure Front Door<\/strong>: Global edge L7 entry with acceleration, WAF, global load balancing.<\/li>\n<li><strong>Azure Traffic Manager<\/strong>: DNS-based global traffic distribution across endpoints\/regions.<\/li>\n<li><strong>Azure NAT Gateway<\/strong>: Outbound-only SNAT control for subnets (not inbound load balancing).<\/li>\n<li><strong>Gateway Load Balancer<\/strong>: Service insertion for NVAs (advanced; verify fit).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives (other clouds)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS: Network Load Balancer (NLB), Application Load Balancer (ALB)<\/li>\n<li>GCP: TCP\/UDP Network Load Balancing, HTTPS Load Balancer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Self-managed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>HAProxy, NGINX (stream), Envoy (L4\/L7 depending), Keepalived\/VRRP (usually not applicable in cloud the same way)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure Load Balancer<\/strong><\/td>\n<td>Regional L4 TCP\/UDP balancing<\/td>\n<td>High performance, simple primitives, internal\/public, VMSS-friendly<\/td>\n<td>No L7 features, flow-based distribution<\/td>\n<td>You need TCP\/UDP load balancing with stable IPs<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Application Gateway<\/strong><\/td>\n<td>Regional HTTP(S) apps<\/td>\n<td>TLS termination, WAF, path-based routing, cookie affinity<\/td>\n<td>More complexity\/cost than L4; HTTP-focused<\/td>\n<td>You need L7 features in a region<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Front Door<\/strong><\/td>\n<td>Global HTTP(S) entry<\/td>\n<td>Global anycast, acceleration, WAF, multi-region failover<\/td>\n<td>Not for arbitrary TCP\/UDP; global design constraints<\/td>\n<td>You need global web acceleration and routing<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Traffic Manager<\/strong><\/td>\n<td>Global DNS-based routing<\/td>\n<td>Simple multi-region distribution, supports many endpoint types<\/td>\n<td>DNS-based (not real-time per-connection), caching effects<\/td>\n<td>You want DNS-level global failover\/geo routing<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure NAT Gateway<\/strong><\/td>\n<td>Outbound-only internet access<\/td>\n<td>Predictable egress, scalable SNAT for subnets<\/td>\n<td>No inbound load balancing<\/td>\n<td>You mainly need outbound SNAT control<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS NLB<\/strong><\/td>\n<td>AWS regional L4<\/td>\n<td>Similar L4 model<\/td>\n<td>Cloud-specific differences<\/td>\n<td>Multi-cloud comparison \/ migration planning<\/td>\n<\/tr>\n<tr>\n<td><strong>GCP TCP\/UDP LB<\/strong><\/td>\n<td>GCP L4<\/td>\n<td>Strong global\/regional options<\/td>\n<td>Cloud-specific differences<\/td>\n<td>Multi-cloud comparison \/ migration planning<\/td>\n<\/tr>\n<tr>\n<td><strong>HAProxy\/NGINX self-managed<\/strong><\/td>\n<td>Custom LB behavior<\/td>\n<td>Full control, advanced routing possible<\/td>\n<td>You manage HA, scaling, patching<\/td>\n<td>You need custom behavior not met by managed services<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: internal tier-1 services with strict segmentation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services company runs internal services (risk scoring, policy evaluation) on VMs. Clients are multiple internal apps across VNets. They need a stable endpoint, high availability, and strict network segmentation.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Hub-and-spoke VNets with central governance<\/li>\n<li>Internal Azure Load Balancer (Standard) per service in the spoke VNet<\/li>\n<li>Backend pool: VM Scale Set (or multiple VMs) across zones<\/li>\n<li>NSGs tightly restrict inbound sources to only approved subnets\/service tags<\/li>\n<li>Azure Monitor alerts on probe health and instance availability<\/li>\n<li><strong>Why Azure Load Balancer was chosen:<\/strong><\/li>\n<li>L4 is sufficient (gRPC\/HTTP is terminated on app side or upstream)<\/li>\n<li>Stable private IP per service<\/li>\n<li>Works well with VMSS and zonal patterns<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced downtime during patching (rolling updates behind the LB)<\/li>\n<li>Clear network boundaries with minimal public exposure<\/li>\n<li>Predictable scaling and operations runbooks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: cost-aware public endpoint for a TCP API<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup runs a custom TCP API for device ingestion. They need to scale from 2 to 10 VM instances without changing device configuration and want a single static IP for customer allowlisting.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Public Azure Load Balancer (Standard) with a static Standard Public IP<\/li>\n<li>Backend pool: VM Scale Set with autoscale based on CPU\/connection metrics (app + VM metrics)<\/li>\n<li>Health probe: TCP on ingestion port (and app-level health endpoints on a secondary port for deeper checks)<\/li>\n<li>CI\/CD updates the VMSS image; instances roll gradually<\/li>\n<li><strong>Why Azure Load Balancer was chosen:<\/strong><\/li>\n<li>Protocol is not HTTP; L4 is required<\/li>\n<li>Single stable IP for customer allowlisting<\/li>\n<li>Simple, managed, low-ops<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Quick scale-out during traffic spikes<\/li>\n<li>Reduced single-instance risk<\/li>\n<li>Straightforward cost model driven mostly by VM usage and traffic<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Azure Load Balancer Layer 4 or Layer 7?<\/strong><br\/>\nAzure Load Balancer is <strong>Layer 4 (TCP\/UDP)<\/strong>. For Layer 7 HTTP(S) features, use Azure Application Gateway or Azure Front Door.<\/p>\n\n\n\n<p>2) <strong>What\u2019s the difference between Public and Internal Azure Load Balancer?<\/strong><br\/>\nPublic has a <strong>public frontend IP<\/strong> (internet-facing). Internal has a <strong>private frontend IP<\/strong> inside a subnet (VNet-only reachability).<\/p>\n\n\n\n<p>3) <strong>Do backend VMs need public IPs?<\/strong><br\/>\nTypically <strong>no<\/strong>. Most secure designs keep backend VMs private and expose only the load balancer frontend.<\/p>\n\n\n\n<p>4) <strong>How does Azure Load Balancer decide which backend gets traffic?<\/strong><br\/>\nIt uses <strong>flow-based hashing<\/strong> (L4). Distribution is by connection\/flow, not by HTTP request.<\/p>\n\n\n\n<p>5) <strong>Can Azure Load Balancer terminate TLS\/SSL?<\/strong><br\/>\nNo. TLS termination is done by the backend service or by an L7 service (Application Gateway\/Front Door).<\/p>\n\n\n\n<p>6) <strong>What are health probes and why do they matter?<\/strong><br\/>\nHealth probes test each backend. Unhealthy backends are removed from rotation for new flows, improving availability.<\/p>\n\n\n\n<p>7) <strong>Why is my backend unhealthy even though the VM is running?<\/strong><br\/>\nCommon reasons: NSG blocks probe traffic, wrong probe port\/path, service not listening, OS firewall blocks the probe port.<\/p>\n\n\n\n<p>8) <strong>Can I load balance UDP traffic?<\/strong><br\/>\nYes, Azure Load Balancer supports <strong>UDP<\/strong> load balancing.<\/p>\n\n\n\n<p>9) <strong>What is an inbound NAT rule used for?<\/strong><br\/>\nIt maps a frontend port to a specific backend VM\/port (e.g., SSH\/RDP). Use carefully; it can increase exposure.<\/p>\n\n\n\n<p>10) <strong>How do I get a stable outbound IP for my backend VMs?<\/strong><br\/>\nOptions include <strong>Standard Load Balancer outbound rules<\/strong> or <strong>Azure NAT Gateway<\/strong>. Choose based on architecture and pricing; verify current guidance in official docs.<\/p>\n\n\n\n<p>11) <strong>Does Azure Load Balancer support Availability Zones?<\/strong><br\/>\nYes, in supported regions and with appropriate configuration (zonal or zone-redundant). Verify regional support.<\/p>\n\n\n\n<p>12) <strong>Can Azure Load Balancer do cross-region load balancing?<\/strong><br\/>\nAzure Load Balancer is <strong>regional<\/strong>. For cross-region, consider Azure Front Door or Traffic Manager (depending on protocol and requirements).<\/p>\n\n\n\n<p>13) <strong>When should I pick Azure Application Gateway instead?<\/strong><br\/>\nWhen you need HTTP(S) features: TLS offload, WAF, path-based routing, header rewrites, etc.<\/p>\n\n\n\n<p>14) <strong>Is Azure Load Balancer \u201cstateful\u201d?<\/strong><br\/>\nIt is stateful in the sense of <strong>connection tracking<\/strong> for L4 flows. It is not application-aware.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the best way to observe and troubleshoot it?<\/strong><br\/>\nUse Azure Monitor metrics\/diagnostics (where available), NSG flow logs (if enabled), and backend OS\/app logs. Start by confirming probe health, NSG rules, and backend listeners.<\/p>\n\n\n\n<p>16) <strong>Can I use Azure Load Balancer with Kubernetes?<\/strong><br\/>\nKubernetes on Azure commonly uses load balancers via services of type <code>LoadBalancer<\/code> (AKS integrates with Azure Load Balancer). The exact behavior depends on AKS configuration; verify AKS documentation for your cluster.<\/p>\n\n\n\n<p>17) <strong>Is Basic SKU still supported?<\/strong><br\/>\nBasic has been considered legacy in many architectures. <strong>Verify current support\/retirement status in official Azure docs<\/strong> before using it.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure Load Balancer<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Load Balancer overview<\/td>\n<td>Canonical concepts, SKUs, capabilities, and configuration model: https:\/\/learn.microsoft.com\/azure\/load-balancer\/load-balancer-overview<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Load Balancer documentation hub<\/td>\n<td>Entry point for tutorials, concepts, and how-to guides: https:\/\/learn.microsoft.com\/azure\/load-balancer\/<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Azure Load Balancer pricing<\/td>\n<td>Most accurate source for pricing meters and regional differences: https:\/\/azure.microsoft.com\/pricing\/details\/load-balancer\/<\/td>\n<\/tr>\n<tr>\n<td>Official tool<\/td>\n<td>Azure Pricing Calculator<\/td>\n<td>Build end-to-end estimates (LB + VMs + data): https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td><code>az network lb<\/code> command group<\/td>\n<td>Accurate CLI syntax and examples: https:\/\/learn.microsoft.com\/cli\/azure\/network\/lb<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Azure Architecture Center<\/td>\n<td>Reference architectures and networking best practices (search Load Balancer patterns): https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Monitoring<\/td>\n<td>Azure Monitor documentation<\/td>\n<td>Metrics, logs, and diagnostics patterns: https:\/\/learn.microsoft.com\/azure\/azure-monitor\/<\/td>\n<\/tr>\n<tr>\n<td>Security<\/td>\n<td>Network Security Groups documentation<\/td>\n<td>Required for securing LB traffic paths: https:\/\/learn.microsoft.com\/azure\/virtual-network\/network-security-groups-overview<\/td>\n<\/tr>\n<tr>\n<td>Related service<\/td>\n<td>Azure Application Gateway<\/td>\n<td>Compare L7 vs L4 patterns: https:\/\/learn.microsoft.com\/azure\/application-gateway\/overview<\/td>\n<\/tr>\n<tr>\n<td>Related service<\/td>\n<td>Azure Front Door<\/td>\n<td>Global edge load balancing and WAF: https:\/\/learn.microsoft.com\/azure\/frontdoor\/front-door-overview<\/td>\n<\/tr>\n<tr>\n<td>Related service<\/td>\n<td>Azure Traffic Manager<\/td>\n<td>DNS-based global distribution: https:\/\/learn.microsoft.com\/azure\/traffic-manager\/traffic-manager-overview<\/td>\n<\/tr>\n<tr>\n<td>Related service<\/td>\n<td>Azure NAT Gateway<\/td>\n<td>Outbound SNAT alternative: https:\/\/learn.microsoft.com\/azure\/nat-gateway\/nat-overview<\/td>\n<\/tr>\n<tr>\n<td>Hands-on learning<\/td>\n<td>Microsoft Learn (Azure networking modules)<\/td>\n<td>Structured learning paths; search for Load Balancer modules: https:\/\/learn.microsoft.com\/training\/<\/td>\n<\/tr>\n<tr>\n<td>Samples<\/td>\n<td>Azure Quickstart Templates (ARM)<\/td>\n<td>Community + Microsoft templates; validate template source\/quality: https:\/\/github.com\/Azure\/azure-quickstart-templates<\/td>\n<\/tr>\n<tr>\n<td>Updates<\/td>\n<td>Azure Updates<\/td>\n<td>Track service announcements\/changes: https:\/\/azure.microsoft.com\/updates\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, cloud engineers<\/td>\n<td>Azure\/DevOps tooling, automation, CI\/CD, infrastructure concepts (verify course specifics)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate IT professionals<\/td>\n<td>DevOps fundamentals, SCM, automation concepts (verify Azure coverage)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams, engineers<\/td>\n<td>CloudOps practices, operations, monitoring (verify Azure networking coverage)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform teams<\/td>\n<td>Reliability engineering, monitoring, incident response (verify Azure modules)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams, SREs<\/td>\n<td>AIOps concepts, monitoring automation (verify Azure relevance)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training content (verify specific offerings)<\/td>\n<td>Beginners to engineers seeking mentorship<\/td>\n<td>https:\/\/www.rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify Azure modules)<\/td>\n<td>DevOps engineers and students<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training platform (verify offerings)<\/td>\n<td>Teams needing short-term guidance<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training (verify service catalog)<\/td>\n<td>Operations teams and engineers<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact service list)<\/td>\n<td>Architecture reviews, implementation support<\/td>\n<td>Designing Azure networking baseline; implementing Azure Load Balancer + VMSS; monitoring setup<\/td>\n<td>https:\/\/www.cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify consulting scope)<\/td>\n<td>DevOps process, cloud automation, platform enablement<\/td>\n<td>IaC for Azure Load Balancer deployments; CI\/CD pipelines for VMSS; operational runbooks<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify catalog)<\/td>\n<td>DevOps transformation, automation support<\/td>\n<td>Standardizing Azure Networking patterns; migrating VM farms behind Azure Load Balancer; observability improvements<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Azure Load Balancer<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Networking fundamentals:<\/li>\n<li>IP addressing, subnets, routing<\/li>\n<li>TCP vs UDP, ports, connection behavior<\/li>\n<li>Azure fundamentals:<\/li>\n<li>Resource groups, regions, Availability Zones<\/li>\n<li>VNets, subnets, NSGs, public IPs<\/li>\n<li>VM fundamentals:<\/li>\n<li>Linux basics, systemd, firewall basics<\/li>\n<li>How to install and validate a service (NGINX, custom TCP server)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Load Balancer<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>L7 load balancing and web security:<\/li>\n<li>Azure Application Gateway (WAF, TLS termination)<\/li>\n<li>Azure Front Door (global entry, WAF)<\/li>\n<li>Outbound and egress design:<\/li>\n<li>NAT Gateway, Azure Firewall, egress filtering<\/li>\n<li>Observability:<\/li>\n<li>Azure Monitor, Log Analytics, alert design, SLOs<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Bicep\/ARM, Terraform, policy-as-code<\/li>\n<li>High availability patterns:<\/li>\n<li>Zonal architectures, multi-region DR with Front Door\/Traffic Manager<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Cloud Network Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Security Engineer (network security controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Microsoft certification paths change over time; commonly relevant:\n&#8211; Azure fundamentals and administrator tracks\n&#8211; Azure networking content within architect-level certifications<\/p>\n\n\n\n<p>Start here and follow current Microsoft guidance:\n&#8211; https:\/\/learn.microsoft.com\/credentials\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Build an internal ILB for a private API tier and restrict access via NSGs.<\/li>\n<li>Deploy a VM Scale Set behind a Standard Load Balancer with autoscale rules.<\/li>\n<li>Implement blue\/green by swapping backend pool membership.<\/li>\n<li>Add monitoring: metrics alerts for probe health and VM availability.<\/li>\n<li>Compare outbound patterns: outbound rules vs NAT Gateway (cost and behavior).<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Load Balancer<\/strong>: Azure-managed Layer 4 load balancer for TCP\/UDP traffic.<\/li>\n<li><strong>Frontend IP configuration<\/strong>: The IP (public or private) clients connect to.<\/li>\n<li><strong>Backend pool<\/strong>: Group of backend endpoints (VM NICs\/VMSS instances) that receive traffic.<\/li>\n<li><strong>Health probe<\/strong>: Periodic check (TCP\/HTTP) used to determine backend health.<\/li>\n<li><strong>Load-balancing rule<\/strong>: Maps frontend port\/protocol to backend port\/pool and probe.<\/li>\n<li><strong>Inbound NAT rule<\/strong>: Maps a frontend port to a specific backend instance port.<\/li>\n<li><strong>Outbound rule<\/strong>: Controls outbound SNAT behavior for a backend pool (Standard SKU scenario).<\/li>\n<li><strong>NSG (Network Security Group)<\/strong>: Stateful firewall rules applied to subnets\/NICs.<\/li>\n<li><strong>VNet (Virtual Network)<\/strong>: Private network boundary in Azure.<\/li>\n<li><strong>Availability Zone<\/strong>: Physically separate datacenter zone within an Azure region.<\/li>\n<li><strong>Zone-redundant<\/strong>: Deployed across zones to survive a zone failure.<\/li>\n<li><strong>SNAT<\/strong>: Source Network Address Translation, often involved in outbound internet connections.<\/li>\n<li><strong>VMSS (Virtual Machine Scale Set)<\/strong>: Azure compute resource for scaling identical VMs.<\/li>\n<li><strong>L4 \/ Layer 4<\/strong>: Transport layer (TCP\/UDP) load balancing.<\/li>\n<li><strong>L7 \/ Layer 7<\/strong>: Application layer (HTTP\/S) load balancing with content-aware routing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Load Balancer is Azure\u2019s core <strong>Networking<\/strong> service for <strong>regional Layer 4 (TCP\/UDP) load balancing<\/strong> with public and internal options. It matters because it provides a stable frontend IP, health-based failover, and scalable distribution across VM and VM Scale Set backends\u2014without requiring you to run and patch your own load balancer appliances.<\/p>\n\n\n\n<p>Cost-wise, focus on the <strong>SKU (Standard vs legacy options)<\/strong>, the number of configured <strong>rules<\/strong>, <strong>data processed<\/strong>, and indirect costs like <strong>VM compute<\/strong>, <strong>Public IPs<\/strong>, <strong>monitoring ingestion<\/strong>, and <strong>internet egress<\/strong>. Security-wise, treat the load balancer as a traffic distributor\u2014not a firewall\u2014then enforce protection with <strong>NSGs<\/strong>, least-privilege <strong>RBAC<\/strong>, safe management access patterns, and strong logging\/alerting.<\/p>\n\n\n\n<p>Use Azure Load Balancer when you need <strong>high-performance L4 distribution<\/strong> with a stable endpoint. Choose Application Gateway or Front Door when you need <strong>HTTP(S) features<\/strong> or <strong>global<\/strong> entry.<\/p>\n\n\n\n<p>Next step: build the same lab using a <strong>VM Scale Set<\/strong> backend and add <strong>Azure Monitor alerts<\/strong> for probe health\u2014then compare the design to an <strong>Application Gateway<\/strong> deployment to understand the L4 vs L7 tradeoffs.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,50],"tags":[],"class_list":["post-500","post","type-post","status-publish","format-standard","hentry","category-azure","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/500","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=500"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/500\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=500"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=500"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=500"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}