Load Balancers, DNS, and CDNs: How Cloud Traffic Reaches Applications

 

When a user enters a hostname or opens an application, several systems may participate before the request reaches application code. DNS resolves a name to an address or service endpoint. A content delivery network can answer the request at the edge or forward it toward an origin. Global traffic management can select a region. A load balancer can choose a healthy backend. Firewalls, gateways, reverse proxies, and application listeners can add more decisions along the way.

These components are often studied separately, but production reliability depends on how they work together. A DNS record can point to a healthy load balancer whose backend pool is empty. A CDN can serve static content while dynamic API traffic fails. A regional load balancer can be perfectly healthy while users in another geography are still reaching an unavailable region because cached DNS answers have not changed.

This guide explains the traffic path as one system. It covers DNS resolution, load balancing, health checks, TLS, CDNs, caching, origin protection, regional and global routing, session behavior, private applications, observability, and troubleshooting without tying the architecture to one provider.

Begin with the full request path

Before choosing a product, draw how traffic should move from the client to the application. Start with name resolution. Then show any edge network, web application firewall, CDN, global traffic manager, regional load balancer, reverse proxy, service mesh, application instance, and downstream dependency required to complete the request.

Label which components operate globally, regionally, zonally, or on individual hosts. That scope determines what failures they can route around. A global traffic service may move clients between regions, while a regional load balancer can only distribute traffic among targets inside its supported scope.

The diagram should also show the return path and where TLS begins and ends. This becomes the foundation for availability design, security review, latency analysis, and incident troubleshooting.

Understand what DNS actually does

Domain Name System translates names into records that clients and resolvers use to locate services. For web applications, DNS often returns an address, an alias to another DNS name, or a provider-specific endpoint representing a global or regional service.

DNS does not carry the application request itself. It supplies information that the client uses to establish a later connection. That distinction matters during failover because changing a DNS answer does not instantly move every existing connection or every client that already cached the old answer.

Design DNS as part of the application rather than as a registrar task performed once at launch. Record ownership, delegation, private and public zones, health-based policies, certificate dependencies, and the expected behavior when an endpoint changes.

Use TTL as a control over caching, not a failover guarantee

DNS records include time-to-live values that tell resolvers how long an answer can be cached. Lower TTLs can allow changes to be observed more quickly, but they increase query volume and dependency on resolvers. Higher TTLs reduce DNS traffic but can cause clients to retain old answers longer.

A low TTL is not a promise that every client will switch at exactly that moment. Recursive resolvers, operating systems, browsers, applications, and long-lived connections can all have their own behavior. Some clients may continue using an existing connection even after the record has changed.

Test failover with realistic clients. Measure how quickly traffic changes in practice rather than assuming the configured TTL equals the user-visible recovery time.

Use DNS routing for coarse-grained traffic decisions

Authoritative DNS services can return different answers according to policy. Common approaches include weighted distribution, geographic selection, latency-oriented routing, failover based on health, or simple active-passive records.

DNS routing is useful for moving clients among regions or independently operated endpoints because it works before the connection is established. It is less suited to per-request decisions because the answer can be cached and reused for many requests.

Choose DNS policy according to the architecture. Weighted routing can support gradual migration. Geographic routing can satisfy locality requirements. Health-based failover can move new clients away from an unavailable endpoint, but only if health checks represent the service users actually need.

Understand the purpose of a load balancer

A load balancer accepts traffic on one or more listeners and distributes connections or requests to a pool of backend targets. The targets can be virtual machines, containers, IP addresses, serverless endpoints, or other services depending on the platform.

Load balancing improves scale and availability because clients do not need to know which individual backend is healthy. Instances can be added, removed, replaced, or drained while the stable frontend continues accepting traffic. The load balancer becomes the place where health and traffic policy meet.

Load balancing only works when listeners, health checks, backend reachability, and routing all agree about the path. AZ-700 networking provides an Azure-oriented context for tracing those dependencies from the frontend to the workload.

Distinguish transport and application-layer load balancing

Transport-layer load balancers make decisions primarily from connection information such as source, destination, protocol, and port. They can be efficient and protocol-agnostic, which is useful for TCP, UDP, or very high-throughput workloads.

Application-layer load balancers understand protocols such as HTTP and HTTPS. They can route according to host names, paths, headers, cookies, or other request properties. That makes them useful for web applications, API gateways, multi-service ingress, and advanced routing policies.

The more a device understands about the application, the more features it can provide, but the architecture also becomes more dependent on that protocol behavior. Choose the simplest layer that meets routing, security, and observability requirements.

Use health checks that represent readiness

A backend should receive traffic only when it can handle useful work. A health check that proves a process is running but ignores database, configuration, or dependency readiness can send users to an instance that is technically alive but operationally broken.

Separate liveness from readiness where possible. Liveness answers whether the process should be restarted. Readiness answers whether the target should receive traffic. Deep synthetic checks can validate a broader user journey from outside the backend pool.

Avoid making every health check depend on every shared service. If a common database fails and all application instances report unhealthy, the load balancer can empty the entire pool and obscure the actual dependency failure. Health checks should support the routing decision without creating a new failure cascade.

Plan backend draining and connection handling

Removing a target from service should not abruptly terminate active work unless the application can tolerate it. Connection draining or deregistration delay gives existing requests time to complete while new requests are directed elsewhere.

This matters during deployments, autoscaling, maintenance, and failure recovery. Long-lived connections, streaming traffic, WebSockets, and large uploads can require different draining behavior from short HTTP requests. The application must also respond correctly when a connection disappears despite graceful controls.

Test removal under realistic load. A deployment that looks safe with short test requests may still interrupt users when production connections live for minutes or hours.

Understand session persistence before enabling it

Some load balancers can keep a client associated with the same backend through cookies, source-address hashing, or other persistence mechanisms. This can help legacy applications that store session state locally, but it also reduces the freedom to distribute traffic evenly and replace instances transparently.

Prefer externalized session state when the application architecture allows it. Then any healthy backend can serve any request, making scaling and failover easier. If persistence is required, document why and understand what happens when the selected backend fails.

Sticky sessions should be a conscious compatibility choice rather than the default solution to state management.

Use autoscaling and load balancing together carefully

A load balancer can distribute traffic only among available targets. Autoscaling adds or removes targets according to demand or system metrics. Together they can respond to variable traffic without permanently provisioning peak capacity.

Scaling takes time. New instances may need to boot, pull images, load configuration, warm caches, register with the load balancer, and pass health checks. Capacity planning should account for that delay so the application does not saturate before new targets become useful.

Autoscaling adds or removes backends, so traffic delivery must adapt without sending requests to unhealthy or unreachable targets. advanced AWS networking extends this reasoning into provider-specific load-balancing and network-design decisions.

Understand where TLS terminates

HTTPS protects application traffic through TLS. The encrypted connection can terminate at an edge service, CDN, load balancer, reverse proxy, or the application itself. The termination point determines where plaintext is visible and which component owns certificates and protocol settings.

Many designs terminate client TLS at the edge or load balancer and create a second encrypted connection to the origin or backend. This allows centralized certificate management and application-layer routing while retaining encryption across internal network segments.

Document the trust boundary explicitly. Know which certificates are presented to clients, how origin identity is validated, which protocols are permitted, and how certificate renewal is automated. A certificate expiry can become a complete outage even when every backend is healthy.

Separate encryption from authentication

TLS can provide encrypted transport and can authenticate the server through certificates. Those concepts are related but not identical. Encrypting a channel protects data in transit, while certificate validation helps a client know it is communicating with the intended endpoint.

Mutual TLS can also authenticate clients or services through certificates when that model fits the environment. It requires careful issuance, rotation, revocation, and trust-store management, especially at large scale.

TLS can protect the transport path without deciding whether a caller is authorized to perform an action. SSL encryption and authentication helps separate certificate-based identity and encrypted transport from the access-control decision that follows.

Use a CDN to move content closer to users

A content delivery network uses edge locations to cache and serve content closer to clients. Static assets such as images, JavaScript, stylesheets, downloads, video segments, and documents are common candidates because they can be reused across many requests.

The CDN can reduce origin load, improve latency, absorb large traffic spikes, and provide a globally distributed frontend. Some CDNs also support dynamic acceleration, edge functions, web application firewalls, certificate management, and origin failover.

The performance benefit depends on cacheability, user geography, object size, and how often content changes. Measure real hit ratios and latency rather than assuming every application will improve equally.

Design cache keys deliberately

A cache key determines which requests are considered equivalent. If the key ignores an important header, query parameter, language, device type, authentication state, or other input, one user’s response can be served incorrectly to another request. If the key includes too many irrelevant variations, the hit ratio collapses and the CDN behaves mostly like a proxy.

Start with the smallest set of request properties that changes the response. Separate truly public cacheable content from personalized or sensitive content. Be careful with authorization headers, cookies, and query strings.

Cache design is application design. The network service can store and route responses, but the application team must understand what makes content safe to reuse.

Plan cache expiration and invalidation

Cached content must eventually be refreshed. Time-based expiration is simple, but it can leave stale content until the object expires. Explicit invalidation can remove or replace content more quickly after a deployment or urgent correction.

Very short expiration can reduce the performance benefit because edge locations continually return to the origin. Very long expiration can make updates difficult. Versioned filenames are often effective for static assets because a new deployment references a new object while old versions can expire naturally.

Test how cache behavior interacts with rollback. If an application version expects one asset while a CDN serves another, a deployment can fail even though the origin and edge are individually healthy.

Protect the origin from direct exposure

If users can bypass the CDN or global frontend and connect directly to the origin, security controls and caching may be less effective. Where appropriate, restrict the origin so it accepts traffic only from the approved edge or load-balancing layer, private network, or authenticated service identity.

Origin protection also reduces the risk that attackers discover the backend address and send traffic around rate limits or web application firewall controls. The exact mechanism can include private connectivity, firewall rules, signed requests, service-to-service authentication, or provider-specific origin validation.

Do not create a protection method that prevents emergency access or troubleshooting without a documented alternative. Security and operability should be designed together.

Distinguish a CDN from a load balancer

A CDN is optimized for distributed edge delivery and caching, while a load balancer primarily distributes traffic among backend targets. Modern cloud services can blur the boundary because global application-delivery products may combine edge routing, caching, TLS, health checks, and web security.

The architecture should describe the function each layer performs rather than relying on the product label. Ask whether the component caches content, selects a region, chooses a backend, terminates TLS, filters application traffic, or performs several of these jobs.

Understanding the function makes troubleshooting easier and reduces accidental duplication, such as applying conflicting redirects or header changes at multiple layers.

Use global traffic management for multi-region applications

A multi-region application needs a mechanism for directing users to an appropriate region. DNS policies, anycast frontends, global load balancers, or edge networks can make this decision based on health, latency, geography, policy, or configured priority.

The global layer cannot make an unhealthy regional application healthy. Regional health checks must be meaningful, and the surviving region must have enough capacity to accept additional users. Stateful applications also need a data design that supports the traffic movement.

Global traffic management should be chosen from application requirements such as latency, failover time, data locality, and session behavior. cloud-provider tradeoffs is useful for seeing how providers package those capabilities differently while the architectural questions remain consistent.

Understand active-active and active-passive traffic patterns

In active-active designs, more than one region serves production traffic at the same time. This can reduce latency and make capacity in secondary regions continuously exercised. It also increases data and application complexity because users may reach different regions for related operations.

Active-passive designs send normal production traffic to one primary region and keep another region ready for failover. They can be simpler but require confidence that the passive region is current, healthy, and able to scale when needed.

Traffic management must align with the data architecture. Routing writes to multiple regions without a clear data-consistency model can create conflicts that no load balancer can solve.

Include private and internal load balancing

Not every load balancer faces the public internet. Internal load balancers provide stable private endpoints for application tiers, shared services, internal APIs, and hybrid clients. They can distribute traffic without assigning public addresses to backend resources.

Internal traffic still needs health checks, capacity planning, TLS, authentication, and observability. A private address is not proof that a service is trusted. Use identity and application authorization according to the sensitivity of the operation.

Private DNS often works with internal load balancing so clients can use stable service names rather than addresses that may change as backends scale or fail.

Use service discovery for dynamic environments

Container platforms and microservice systems can create and remove service instances frequently. Traditional static address configuration is unsuitable in that environment. Service discovery maps a logical service name to healthy endpoints, often integrated with orchestration, DNS, or a service mesh.

Discovery solves the problem of finding a service, while load balancing determines which instance receives a request. The functions may be implemented in one platform component or several layers.

Dynamic platforms need a stable way for clients or upstream services to find changing workloads. Kubernetes on AWS shows how services, ingress, and orchestration provide that abstraction without requiring clients to track individual container addresses.

Plan web application firewall placement intentionally

A web application firewall examines HTTP traffic for malicious or unwanted request patterns. It is often placed at an edge service, CDN, application gateway, or load balancer where it can protect many backends consistently.

WAF rules can block attacks but can also block legitimate traffic when tuned poorly. Deploy managed and custom rules with observability, staged enforcement, and a process for reviewing false positives. Keep application-layer security controls in the application as well; a WAF is one layer rather than a replacement for secure development.

Central placement can simplify governance, but application teams still need visibility into why requests were rejected.

Observe every layer of the traffic path

DNS query logs, edge metrics, CDN cache statistics, load-balancer access logs, health-check results, firewall logs, backend application logs, and distributed traces each answer different questions. No single source provides the entire story.

Build dashboards around the user journey. Show request rate, success, latency, regional distribution, backend health, TLS errors, cache hit ratio, origin errors, and capacity. During an incident, operators should be able to determine whether users fail before the edge, at routing, at a load balancer, or inside the application.

When a request fails, packet and flow evidence can distinguish DNS, routing, policy, load-balancer, and backend problems. network traffic monitoring reinforces why traffic visibility should be part of the design rather than added only after an incident.

Troubleshoot from the client toward the origin

Start by resolving the hostname from the affected client or network. Confirm the returned endpoint and whether DNS caching could explain the behavior. Test connection establishment and TLS. Inspect edge or CDN logs. Check global routing, regional frontend health, load-balancer target health, and backend application logs in that order.

This sequence narrows the fault domain without random configuration changes. If the DNS answer is wrong, changing backend health checks will not help. If the edge reaches the origin but receives application errors, changing DNS may only spread the problem differently.

Capture timestamps and request identifiers where possible so events can be correlated across layers.

Test failover and deployment behavior

Application-delivery architecture is only trustworthy when tested. Remove a backend and confirm health checks drain it. Simulate a zonal failure and verify surviving targets have capacity. Change a DNS or global routing policy and measure how real clients move. Invalidate cached content after a deployment and verify both new and old sessions behave correctly.

Test certificate renewal, origin failure, cache miss storms, and a deployment that creates unhealthy backends. These scenarios expose dependencies that a steady-state performance test will not reveal.

Use safe environments and controlled production exercises appropriate to the risk. The objective is to make traffic movement predictable under change and failure.

Build a traffic-delivery review checklist

Document the hostname, authoritative DNS, TTLs, public or private resolution path, edge and CDN layers, TLS termination points, global routing policy, regional load balancers, backend health checks, target capacity, origin restrictions, and security controls. Include the owner of each layer and the telemetry used to verify it.

Trace at least one complete request and one failure scenario. Ask what happens when an instance fails, a zone fails, a region fails, a certificate expires, the origin slows down, DNS returns a stale answer, or cache content becomes incorrect.

The strongest design is not the one with the most traffic services. It is the one in which every layer has a clear job, failure behavior, security boundary, and source of evidence.

Distinguish application gateways from API gateways

An application gateway or application-layer load balancer usually focuses on delivering web traffic to backend services. An API gateway adds API-specific capabilities such as request authentication, quotas, usage plans, transformation, schema validation, versioning, or developer-facing management. Some cloud products combine several of these functions, so the service name alone does not reveal the architectural role.

Use an API gateway when the application needs a managed contract at the API boundary rather than only traffic distribution. Keep business authorization in the application or an appropriate identity layer; gateway authentication should complement the application’s own rules rather than becoming the only control protecting sensitive operations.

Avoid stacking multiple gateways without a clear reason. Every proxy adds latency, configuration, certificates, logging, and another failure surface. If a CDN, web application firewall, global frontend, API gateway, and service mesh all modify headers or retries, document which layer owns each behavior.

Protect DNS as production infrastructure

A DNS zone can be as critical as the application it names. Unauthorized record changes can redirect users, break email and API endpoints, or defeat carefully designed regional failover. Restrict who can modify zones, use strong administrative authentication, log changes, and separate routine application deployment from domain-level ownership where appropriate.

Automate records carefully. Dynamic environments benefit from infrastructure as code, but a faulty deployment should not be able to delete unrelated production zones or replace global records accidentally. Review delegation, domain renewal, and registrar access as part of availability planning, not only security.

Private DNS deserves the same discipline. Misconfigured forwarding or a conflicting private zone can make internal applications resolve differently from external clients and create failures that look like routing problems.

Prevent cache stampedes at the origin

A CDN can remove enormous load from an origin while cache entries are valid. If a popular object expires simultaneously across many edge locations, the origin can receive a sudden burst of refresh requests. Similar behavior can occur after a large invalidation or deployment.

Use cache-control strategy, request coalescing where supported, staggered expiry, origin shielding, and sufficient backend capacity to protect against these events. For dynamic applications, application-level caches may need the same controls. The architecture should consider what happens when the cache is empty, not only when hit ratio is high.

A cache should improve resilience, not become a dependency the origin cannot survive without. Periodically test cold-cache behavior so capacity assumptions remain realistic.

Keep backend networks simple enough to diagnose

Application-delivery systems sit on top of the underlying cloud network. A load balancer still needs a valid path to its targets, and targets still need return routing, security rules, and access to dependencies. Private backends can fail because of route tables, network security, overlapping addresses, or misconfigured service endpoints even when the frontend itself reports healthy.

Backend health is hard to diagnose when the underlying network is poorly understood. Reviewing AWS VPC design concepts such as subnet placement, routes, and gateways helps separate application failure from reachability failure.

Keep enough separation that frontend changes do not require broad modifications to internal routing. Stable network boundaries make both security and troubleshooting easier.

Control cost across edge and delivery layers

Traffic services charge according to combinations of processed data, requests, rules, capacity units, zones, edge transfer, origin transfer, and security features. A global application can therefore accumulate cost at several layers before the request reaches a backend.

Measure where bytes move. CDN caching can reduce origin transfer, but uncacheable content still travels to the origin. Cross-region origins can create extra data movement. Logging every request at full detail can become expensive at high volume. Security inspection and NAT paths may add further processing charges.

Cost optimization should preserve resilience and security. The goal is to remove accidental duplication: unnecessary cross-region hops, multiple proxies performing the same function, oversized logging, or static content repeatedly served from application servers when the edge could cache it safely.

Practice with a request-tracing lab

Build a small web application with a hostname, TLS, a load balancer, and at least two backend instances. Record the DNS answer and follow one request through each layer. Remove one backend and observe health-check behavior. Change a routing rule. Rotate the certificate. Add a static object behind a CDN and verify cache hits and misses.

Then introduce failure. Break origin reachability, make the health endpoint fail, change the DNS answer, or expire cached content under load in a safe environment. Predict what telemetry should change and compare the prediction with the evidence.

A request-tracing lab should follow the same transaction across DNS, traffic management, load balancing, routing, and the backend service. Google Cloud network engineering adds the broader routing, hybrid, security, and performance context needed to interpret what each hop is doing.

Prefer clear responsibility over a long chain of services

Cloud platforms make it easy to add another frontend component because each service solves a real problem. Complexity appears when several layers solve overlapping versions of the same problem. A global frontend may already provide TLS, WAF, caching, health checks, and regional routing; adding separate products for every feature can make behavior harder to predict.

For each traffic component, write one sentence describing its job. If two components have essentially the same sentence, ask whether both are needed. Then document the order of evaluation: where DNS selects an endpoint, where TLS terminates, where security rules run, where caching occurs, where a region is chosen, and where a backend is selected.

This clarity is more valuable than memorizing product portfolios because it lets architects evaluate new services without losing the underlying model.