Cloud Load Balancer Cheat Sheet

Load balancers look simple from the outside because clients only see a single endpoint. Internally, they make a long series of routing and policy decisions that affect latency, availability, and security. A useful cheat sheet starts by separating the main choices: network versus application balancing, public versus internal exposure, and regional versus global scope.

Layer 4 load balancers route by transport information such as IP address and TCP or UDP port. They are fast, protocol-agnostic, and a good fit for raw TCP services, game backends, and cases where the application protocol should stay untouched. Because they do not inspect HTTP semantics deeply, they offer fewer options for header-based routing or per-path policy.

Layer 7 load balancers understand HTTP and HTTPS. They can route by host name, path, header, cookie, or method, terminate TLS, apply WAF rules, and produce richer request metrics. That makes them ideal for web applications, APIs, and microservice ingress. The tradeoff is extra complexity and some processing overhead, which is usually acceptable for internet-facing application traffic.

Health checking is one of the most important mechanisms regardless of layer. A backend is not healthy merely because its process is running. Good health checks verify that the application can accept useful work, including key dependencies if appropriate. Bad health checks can cause either false confidence or self-inflicted outages. If the check is too shallow, broken instances stay in rotation. If it is too expensive, the balancer can contribute to overload.

Session affinity, sometimes called sticky sessions, is another design choice with consequences. It can reduce cache misses or simplify stateful applications, but it also makes traffic distribution less even and weakens failover if user state lives only in memory. Stateless application design is usually more resilient, but some protocols still benefit from persistence at the balancer.

Cloud load balancers also differ by scope. Internal load balancers expose services only within a private network and are common for service-to-service traffic. External load balancers terminate user traffic from the internet. Global balancers can direct users to the nearest healthy region and fail over across geography, while regional balancers are simpler and often cheaper for single-region architectures.

TLS handling deserves explicit attention. Terminating TLS at the balancer simplifies certificate management and observability, but traffic between the balancer and backend may still need encryption depending on the trust boundary. Features such as mTLS, proxy protocol support, and original client IP preservation matter when downstream services enforce identity or rate limits.

The right load balancer is therefore not chosen by popularity. It is chosen by protocol, routing needs, failure domain, and operational policy. If you know whether the service needs HTTP-aware routing, global failover, internal-only exposure, and strict transport controls, the cheat sheet becomes a decision tool rather than a glossary.