Cloudflare Load Balancing can make your application seem like it’s everywhere at once, but its true magic lies in making it feel like it’s everywhere even when it’s not.
Let’s see it in action. Imagine you have two web servers, one in us-east-1 and another in eu-west-2.
{
"name": "my-awesome-app-lb",
"description": "Load balancing for my awesome app",
"subdomain": "app.example.com",
"fallback_origin": "origin_eu_west_2",
"origins": [
{
"name": "origin_us_east_1",
"address": "192.0.2.10",
"enabled": true,
"health_check": {
"protocol": "HTTP",
"port": 80,
"request_path": "/healthz",
"interval": 30,
"timeout": 5,
"unhealthy_threshold": 3,
"healthy_threshold": 2,
"method": "GET",
"host_header": "app.example.com"
}
},
{
"name": "origin_eu_west_2",
"address": "198.51.100.20",
"enabled": true,
"health_check": {
"protocol": "HTTP",
"port": 80,
"request_path": "/healthz",
"interval": 30,
"timeout": 5,
"unhealthy_threshold": 3,
"healthy_threshold": 2,
"method": "GET",
"host_header": "app.example.com"
}
}
],
"rules": [
{
"description": "Route all traffic to the closest origin",
"conditions": [
{
"type": "request_protocol",
"operator": "equals",
"value": "HTTP"
}
],
"priority": 1,
"actions": [
{
"type": "route",
"origin": "origin_us_east_1"
}
]
}
]
}
This configuration sets up a load balancer for app.example.com. It has two origins: origin_us_east_1 (at 192.0.2.10) and origin_eu_west_2 (at 198.51.100.20). Both origins are configured to be checked every 30 seconds using an HTTP GET request to /healthz on port 80, with a 5-second timeout. An origin is considered unhealthy after 3 failed checks and healthy again after 2 successful checks. The fallback_origin is set to origin_eu_west_2, meaning if all other origins fail, traffic will be sent there. The primary rule routes all HTTP traffic to origin_us_east_1. If you were to make a request to app.example.com from the US, Cloudflare’s edge would likely direct you to the us-east-1 origin. If you were in Europe, it would direct you to eu-west-2.
The core problem Cloudflare Load Balancing solves is distributing incoming traffic across multiple backend servers or data centers to improve performance, reliability, and availability. It achieves this by intelligently directing user requests to the most appropriate origin server. This involves several moving parts: the load balancer itself, the origins (your backend servers), and health checks. When a user makes a request to your domain, Cloudflare’s DNS resolves it to an IP address on their global network. From there, the load balancer evaluates traffic steering rules, considers the health of your origins, and forwards the request to a healthy origin that best matches the routing logic. The health checks are critical; they continuously probe your origins to determine their availability. If an origin fails a health check, Cloudflare stops sending traffic to it until it becomes healthy again. This failover mechanism is what prevents downtime.
The routing rules are where you define the intelligence behind your load balancing. You can create rules based on various conditions like the geographic location of the visitor, the HTTP method, cookies, or even specific request headers. For example, you could route visitors from Asia to an origin server located in Singapore. The origin field in the rules action specifies which origin (or group of origins) to send traffic to if the conditions are met. The priority field determines the order in which rules are evaluated; lower numbers have higher priority.
The fallback_origin setting is a crucial safety net. It specifies an origin that will receive traffic if all other origins defined in the load balancer become unhealthy. This ensures that your application remains accessible even in the event of a widespread outage affecting your primary data centers. It’s common practice to set the fallback origin to an origin in a different geographic region or even a completely different cloud provider for maximum resilience.
The health check configuration is granular. interval dictates how often Cloudflare checks the health of an origin (in seconds). timeout is the maximum time Cloudflare waits for a response from the origin during a health check. unhealthy_threshold is the number of consecutive failed health checks required to mark an origin as unhealthy. healthy_threshold is the number of consecutive successful health checks needed to mark an unhealthy origin as healthy again. These values should be tuned based on your application’s typical response times and the network latency to your origins. For instance, if your application sometimes takes 7 seconds to respond under load, setting timeout to 5 seconds would cause unnecessary false negatives.
A common point of confusion is how Cloudflare’s Anycast network interacts with load balancing. When a request hits Cloudflare’s edge, it’s not always routed to the closest origin in terms of geographical distance. The load balancer’s rules and the health of the origin play a significant role. If your "closest" origin is unhealthy, Cloudflare will route you to the next closest healthy origin, irrespective of the initial perceived distance. This means a user in New York might be directed to a server in Europe if the US server is down, and the European server is the next available healthy option.
The next step in advanced traffic management is often implementing weighted load balancing, allowing you to distribute traffic across healthy origins based on predefined percentages, which is useful for canary deployments or traffic shaping.