Load Balancing Basics for Cloud Servers

Layer 4 versus layer 7

For a web application, layer 7 is almost always the right choice, because path-based routing, header inspection and TLS termination are exactly the features you will want.

Health checks are the important configuration

A health check that only confirms the port is open will happily route traffic to a server whose database connection has failed. Make it mean something:

• Use a dedicated endpoint such as /healthz, not the homepage.
• Have it verify real dependencies — a database ping, cache reachability.
• Keep it fast and cheap; it runs every few seconds from every balancer node.
• Return a clear status code: 200 for healthy, anything else for unhealthy.
• Exclude it from logs and metrics, or it will dominate both.
• Do not make it so strict that a slow dependency removes every server at once.

That last point causes real outages. A health check that fails when a non-critical service is slow can take down a perfectly functional fleet.

Distribution algorithms

• Round robin — each server in turn. Fine when requests are similar and servers identical.
• Least connections — to the server with fewest active connections. Better when request durations vary.
• Weighted — proportional to capacity. Useful with mixed instance sizes or during a gradual rollout.
• IP hash — the same client to the same server. A workaround for session state, not a solution.

Least connections is a good default for web applications. Round robin is fine and simpler when responses are uniformly quick.

Sessions: fix the cause

Sticky sessions pin a user to one server so local session state keeps working. They are available everywhere and they undermine most of the point: uneven distribution, and a logout for everyone on a server that restarts.

The better answer is to move sessions to shared storage — Redis, a database, or a signed cookie — so any server can serve any request. Then any balancing algorithm works and servers become genuinely disposable.

Terminate TLS at the balancer

1. Attach the certificate to the load balancer; most providers issue and renew managed certificates at no cost.
2. Redirect HTTP to HTTPS at the balancer, not in the application.
3. Forward X-Forwarded-For and X-Forwarded-Proto, and configure the application to trust them.
4. Decide whether the balancer-to-server hop is encrypted. Within a private network, plain HTTP is common; for sensitive data, re-encrypt.
5. Set sensible timeouts — idle, connection and request — and make them longer than your slowest legitimate response.

Forgetting X-Forwarded-For is the classic mistake: every request appears to come from the balancer, so rate limiting and logging become useless.

What the providers offer

DigitalOcean, Linode, UpCloud, Hetzner, Vultr and the hyperscalers all sell a managed load balancer for a modest monthly fee, with health checks and managed certificates included. Running HAProxy, Nginx or Caddy yourself gives more control and makes the balancer itself a single point of failure unless you run two.

For most teams the managed option is the better trade. The exception is when you need routing logic the managed product does not support.

Common questions

Where to go next

See scaling up versus scaling out and cloud networking basics.