3.3 DNS, Load Balancing & Traffic Routing

DNS, Load Balancing & Traffic Routing

High-availability cloud systems rely on three interconnected traffic management pillars: Domain Name System (DNS) for global name resolution and routing, Load Balancers for localized workload distribution and health monitoring, and Content Delivery Networks (CDNs) for low-latency edge caching and DDoS attenuation. The CompTIA Cloud+ (CV0-004) exam rigorously tests the integration of these technologies.

---

1. Cloud DNS & Split-Horizon Architecture

Cloud DNS services (e.g., AWS Route 53, Azure DNS, Google Cloud DNS, Cloudflare) operate as highly available, globally distributed Authoritative DNS services.

Split-Horizon (Split-View) DNS

In enterprise hybrid architectures, organizations frequently implement Split-Horizon DNS. Under this design, the same domain name (e.g., api.example.com or corp.internal) has two independent zone definitions:

1. Public Hosted Zone: Accessible by external internet clients; resolves api.example.com to public Application Load Balancers or CDN edge endpoints.
2. Private Hosted Zone: Associated strictly with specific VPCs/VNets; resolves api.example.com to private RFC 1918 internal load balancers (10.0.5.50). Internal traffic remains isolated within the private cloud SDN, never traversing the public internet.

+-----------------------------------------------------------------------------------------+
|                              SPLIT-HORIZON DNS RESOLUTION                               |
|                                                                                         |
|   [ External Client ]                                                                   |
|          |                                                                              |
|          v Query: api.corp.com                                                          |
|   +---------------------------------------+                                             |
|   | Public DNS Zone (Route 53 / Azure)    | ----> Resolves to: 54.210.88.99             |
|   +---------------------------------------+       (Public Ingress / CloudFront CDN)     |
|                                                                                         |
|   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
|                                                                                         |
|   [ Internal VPC EC2 / Workload ]                                                       |
|          |                                                                              |
|          v Query: api.corp.com                                                          |
|   +---------------------------------------+                                             |
|   | Private DNS Zone (VPC Attached)       | ----> Resolves to: 10.0.10.45               |
|   +---------------------------------------+       (Internal RFC 1918 Private ALB)       |
+-----------------------------------------------------------------------------------------+

Essential DNS Record Types & Zone Apex Rules

[!CAUTION] The Zone Apex CNAME RFC Restriction:
According to RFC 1034, a CNAME record cannot coexist with other records (such as SOA and NS records) at the root zone apex (example.com). Because cloud load balancers and CDNs use dynamic DNS names rather than static IP addresses, standard CNAMEs cannot be placed at the root apex. Cloud providers solved this with ALIAS (Route 53) or ANAME records, which act like a CNAME but dynamically return the target's underlying IP address directly to the client at the DNS server level.

---

2. Advanced DNS Traffic Routing Policies

Cloud DNS engines evaluate sophisticated routing algorithms to optimize latency, cost, and disaster recovery:

+-----------------------------------------------------------------------------------------+
|                           CLOUD DNS TRAFFIC ROUTING POLICIES                            |
|                                                                                         |
|   1. WEIGHTED ROUTING:                                                                  |
|      - Traffic Split: 90% Production (v1.0) <---> 10% Canary (v2.0)                     |
|      - Best For: Canary deployments, A/B testing, gradual blue/green cutover            |
|                                                                                         |
|   2. LATENCY-BASED ROUTING (LBR):                                                       |
|      - Client (Tokyo) ----> Routes to ap-northeast-1 (15ms) vs us-east-1 (140ms)        |
|      - Best For: Global multi-region applications requiring lowest network RTT          |
|                                                                                         |
|   3. GEOLOCATION & GEOPROXIMITY:                                                        |
|      - Geolocation: Routes based on geographic location of query (e.g., EU users -> EU) |
|      - Geoproximity: Routes based on physical coordinates with a configurable 'Bias'    |
|      - Best For: GDPR compliance, data sovereignty, licensed media restrictions         |
|                                                                                         |
|   4. FAILOVER ROUTING (Active-Passive DR):                                              |
|      - Primary Region (Healthy)   ----> 100% Traffic                                    |
|      - Primary Region (Unhealthy) ----> Automated Health-Check Switch ----> DR Region   |
+-----------------------------------------------------------------------------------------+

---

3. Load Balancer Architectures: Layer 4 vs. Layer 7

Load balancing distributes incoming traffic across backend instance pools, containers, or serverless functions to guarantee horizontal scalability and high availability.

+-----------------------------------------------------------------------------------------+
|                     LAYER 4 (NLB) VS. LAYER 7 (ALB) ARCHITECTURE                        |
|                                                                                         |
|   [ LAYER 4: NETWORK LOAD BALANCER ]                                                    |
|   - OSI Layer: Transport Layer (TCP, UDP, TLS)                                          |
|   - Performance: Millions of requests/sec; ultra-low sub-millisecond latency            |
|   - Addressing: Static IP / Elastic IP per Availability Zone                            |
|   - Routing Logic: IP address and TCP/UDP port tuple only                               |
|   - Source IP Preservation: Preserves client source IP natively down to the backend     |
|                                                                                         |
|   [ LAYER 7: APPLICATION LOAD BALANCER ]                                                |
|   - OSI Layer: Application Layer (HTTP, HTTPS, HTTP/2, gRPC, WebSockets)                |
|   - Performance: High throughput; evaluates rich Layer 7 payload rules                  |
|   - Addressing: Dynamic DNS endpoint (dynamic IP pool)                                  |
|   - Routing Logic: Host headers, URL path (/api vs /static), HTTP headers, query params  |
|   - Source IP: Replaces source IP with ALB IP; appends original in X-Forwarded-For      |
+-----------------------------------------------------------------------------------------+

Advanced Load Balancing Mechanics

1. SSL/TLS Termination & Offloading: The load balancer decrypts incoming HTTPS traffic using certificates managed in Certificate Manager, terminating the TLS session and passing unencrypted HTTP (or re-encrypted TLS) to backend targets, offloading cryptographic CPU overhead from application servers.
2. Server Name Indication (SNI): Allows a single load balancer to bind multiple SSL/TLS certificates on a single IP address, serving different domain names (siteA.com, siteB.com) based on the hostname requested in the client TLS handshake.
3. Sticky Sessions (Session Affinity): Binds a client's session to a specific backend instance using HTTP cookies (Application-generated or Duration-based cookies). Useful for legacy stateful applications, though stateless architectures are preferred.
4. Cross-Zone Load Balancing: When enabled, the load balancer distributes traffic evenly across all registered targets in all Availability Zones, preventing target imbalance when one AZ has more instances than another.

---

4. Content Delivery Networks (CDN) & Edge Caching Architecture

A Content Delivery Network (CDN) (e.g., AWS CloudFront, Azure CDN, Google Cloud CDN, Fastly) utilizes a globally distributed network of Points of Presence (PoPs) and Edge Locations to cache content closer to end users.

+-----------------------------------------------------------------------------------------+
|                             CDN EDGE CACHING & ORIGIN FLOW                              |
|                                                                                         |
|   [ End User (Berlin) ]                                                                 |
|           |                                                                             |
|           v (1. HTTP GET /banner.jpg)                                                   |
|   +---------------------------------------+                                             |
|   | Edge Location (PoP - Frankfurt)       | ---(CACHE HIT: 98% CHR)----> Returns to User|
|   +---------------------------------------+                              (5ms Latency)  |
|           |                                                                             |
|           | (2. CACHE MISS)                                                             |
|           v                                                                             |
|   +---------------------------------------+                                             |
|   | Origin Shield (Regional Edge Cache)   |                                             |
|   +---------------------------------------+                                             |
|           |                                                                             |
|           | (3. Consolidated Fetch)                                                     |
|           v                                                                             |
|   +---------------------------------------+                                             |
|   | Origin Server (AWS S3 / Cloud ALB)    | ----> Returns 200 OK + Cache-Control: max-age|
|   | (us-east-1, North Virginia)           |                                             |
|   +---------------------------------------+                                             |
+-----------------------------------------------------------------------------------------+

CDN Architectural Best Practices

• Cache Hit Ratio (CHR): The percentage of requests served directly from the edge cache without contacting the origin server ($\text{CHR} = \frac{\text{Cache Hits}}{\text{Total Requests}}$). Maximizing CHR reduces origin server compute load and egress bandwidth billing.
• Origin Shield: An intermediate caching layer positioned between edge locations and the origin. It consolidates multiple edge misses into a single request to the origin, shielding the backend from thundering herd spikes.
• TTL & Cache-Control Headers: Managed via HTTP headers returned by the origin:
  • Cache-Control: public, max-age=86400, s-maxage=604800
• Cache Invalidation vs. Cache Busting:
  • Invalidation API: Explicitly purges objects from all global edge caches before TTL expiration (incurs API costs at scale).
  • Cache Busting (Recommended): Incorporates version strings or content hashes into asset URLs (e.g., styles.v2.css or bundle-a1b2c.js), bypassing old cache entries instantly with zero API overhead.