Azure DNS and Load Balancer Essentials

DNS (Domain Name System) translates human-readable domain names (like api.mycompany.com) into IP addresses that computers use to communicate. Azure provides two DNS services: Azure DNS for hosting public DNS zones (internet-facing domains), and Azure Private DNS for internal name resolution within VNets. Without proper DNS configuration, Azure resources must be referenced by their IP addresses, making architectures brittle — any IP change breaks all dependent configurations. Azure DNS is a highly available, globally distributed service backed by Microsoft's anycast network.

Azure DNS public zones host DNS records for domains that are accessible from the internet. You delegate your domain (registered with a registrar like GoDaddy) to Azure DNS by updating the domain's NS records to point to Azure's name servers. Once delegated, you manage all DNS records (A, CNAME, MX, TXT, etc.) from the Azure portal or CLI instead of a separate DNS provider. Azure DNS public zones provide 100% SLA uptime, sub-second global propagation, and RBAC-controlled access so only authorised team members can modify DNS records.

Azure Private DNS zones provide name resolution for resources within VNets without exposing DNS records publicly. For example, you can create a private zone myapp.internal and register your VMs so they resolve by name (db.myapp.internal) rather than by IP. Private DNS zones are linked to VNets — only resources in linked VNets can resolve the private records. You can also enable auto-registration, which automatically creates DNS records for VMs when they join the VNet, keeping DNS in sync without manual management.

Private Endpoints (for services like Azure SQL, Blob Storage, Key Vault) require DNS to resolve the service's public hostname to the private IP instead of the public IP. Azure provides private DNS zones for each service (e.g., privatelink.blob.core.windows.net for Blob Storage). When you create a Private Endpoint, Azure creates a DNS A record in this private zone pointing to the private IP. Link this zone to your VNet, and all DNS lookups for the storage account URL automatically resolve to the private IP — routing traffic through the private backbone without any application code changes.

Azure Load Balancer distributes inbound network traffic across multiple backend resources (VMs or instances in a scale set) to ensure no single resource is overwhelmed. It operates at Layer 4 (Transport Layer) of the OSI model — it routes TCP and UDP packets based on source/destination IP and port, without inspecting the HTTP content. Azure Load Balancer is a highly available, zone-redundant service with a 99.99% SLA (Standard SKU) and supports both inbound load balancing (from internet or VNet) and outbound SNAT for VM internet egress.

Azure Load Balancer has four main components: Frontend IP configuration — the public or private IP that clients connect to. Backend pool — the set of VMs or scale set instances that receive traffic. Load balancing rules — map a frontend IP:port to a backend port and specify the load distribution algorithm (5-tuple hash by default). Health probes — periodically test each backend instance; instances that fail health checks stop receiving new connections until they recover. Together these components define how traffic is received, checked, and distributed.

Health probes are periodic checks sent by the load balancer to each backend instance to determine if it is healthy and should receive traffic. You configure the probe protocol (HTTP, HTTPS, or TCP), port, and interval. For HTTP/HTTPS probes, the load balancer sends a GET request to a specified URL path — the instance is healthy if it returns HTTP 200. For TCP probes, a successful TCP connection means healthy. If a backend fails a configurable number of consecutive probes, the load balancer stops sending it new connections until it passes probes again. This provides automatic fault tolerance without manual intervention.

Azure Load Balancer comes in two SKUs: Basic — free, supports up to 300 backend instances, no SLA, no availability zone support, no secure-by-default NSG requirement. Standard — paid (~$20/month base), supports up to 1,000 backend instances, 99.99% SLA, zone-redundant front end, secure by default (requires explicit NSG rules to allow traffic), and supports multiple frontend IPs. For any production workload, the Standard SKU is strongly recommended. Microsoft is retiring the Basic SKU — new deployments should always use Standard.

Azure Load Balancer can be deployed in two configurations: Public (External) Load Balancer — has a public IP on the frontend; distributes internet traffic across backend VMs. Used for internet-facing applications like web servers and API gateways. Internal (Private) Load Balancer — has a private IP on the frontend within a VNet; distributes intra-VNet traffic. Used for multi-tier applications where the app tier load balancer should not be accessible from the internet — only from the web tier in the same VNet. You can deploy both simultaneously: public LB for the web tier, internal LB for the app tier.

Azure offers two primary load balancing services for different scenarios: Azure Load Balancer — Layer 4, TCP/UDP, ultra-low latency, handles millions of connections per second. Best for non-HTTP workloads or when maximum throughput and minimal latency are priorities. Azure Application Gateway — Layer 7, HTTP/HTTPS, understands URL paths and headers, includes Web Application Firewall (WAF), SSL termination, cookie-based session affinity, and URL-based routing. Best for web applications that need content-aware load balancing, TLS offloading, and WAF protection. For simple TCP load balancing, use Load Balancer. For web applications, Application Gateway adds significant value.

DNS and Load Balancer work together to create resilient, user-friendly endpoints. A common pattern: 1) Create an Azure Load Balancer with a Standard public IP and a backend pool of web server VMs. 2) Create a DNS CNAME record in Azure DNS pointing www.mycompany.com to the Load Balancer's public IP (or DNS name). 3) When users visit www.mycompany.com, DNS resolves to the Load Balancer's IP, and the Load Balancer distributes requests across healthy VM instances. This provides both a user-friendly URL and automatic traffic distribution with fault tolerance.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure DNS hosts public and private DNS zones with near-100% availability, enabling human-readable names for Azure resources, private DNS zones with auto-registration keep VNet DNS records current without manual management, and Azure Load Balancer distributes Layer 4 TCP/UDP traffic across healthy backend VM instances using health probes to detect and bypass failed instances automatically. Next up we move to the Azure Databases course, starting with Azure SQL Database.