Study guide
3.3 DNS, Load Balancing & Traffic Routing
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
3.3 DNS, Load Balancing & Traffic Routing
Key Takeaways Explain This Topic AI
Split-Horizon (Split-View) DNS hosts identical domain names with distinct public and private zone records, ensuring internal cloud resources resolve to private RFC 1918 IPs while external users resolve to public endpoints.
Cloud DNS supports advanced routing policies including Weighted (canary testing), Latency-based (lowest RTT), Geolocation (legal compliance), and Failover (active-passive health-check driven).
Layer 4 Load Balancers (NLB) process millions of TCP/UDP requests per second at ultra-low latency with static IPs, whereas Layer 7 Load Balancers (ALB) evaluate HTTP/HTTPS headers, paths, and host headers for microservices routing.
Content Delivery Networks (CDNs) cache static assets at globally distributed Edge PoPs, utilizing Origin Shield layers, TTLs, and cache invalidation strategies to maximize Cache Hit Ratios (CHR).
At the zone apex (e.g., example.com), standard DNS RFCs prohibit CNAME records; cloud architectures utilize synthetic ALIAS/ANAME records to point root domains directly to dynamic cloud load balancers.
Last updated: August 2026
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:
Public Hosted Zone: Accessible by external internet clients; resolves api.example.com to public Application Load Balancers or CDN edge endpoints.
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
- Record Type Description Use Case in Cloud Architecture
- A Record Maps a hostname to a 32-bit IPv4 address. web1.example.com -> 192.0.2.1
- AAAA Record Maps a hostname to a 128-bit IPv6 address. web1.example.com -> 2001:db8::1
CNAME Record Canonical Name; aliases one hostname to another hostname. www.example.com -> my-alb-1234.us-east-1.elb.amazonaws.com
ALIAS / ANAME CSP Synthetic Record that resolves directly to cloud resources. Points the Zone Apex ( example.com ) directly to an ALB or CDN.
MX Record Mail Exchanger; specifies mail servers. example.com -> mail.protection.outlook.com
TXT Record Arbitrary text strings. Domain ownership validation, SPF, DKIM, DMARC.
SRV Record Service Locator; defines port and protocol for specific services. Microservices discovery, Kubernetes CoreDNS, SIP/LDAP.
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
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.
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.
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.
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 ( CHR = Cache Hits Total Requests \text{CHR} = \frac{\text{Cache Hits}}{\text{Total Requests}} CHR = Total Requests Cache Hits ). 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.