A CDN failover isn’t about which CDN is faster, it’s about which origin server is available right now.
Let’s say you’ve got two data centers, one in Virginia (VA) and one in Oregon (OR), both serving your popular images.example.com subdomain. Your CDN, let’s call it "EdgeServe," is configured to pull content from these origins. Normally, EdgeServe will try to fetch from VA first because it’s geographically closer to most of your users.
Here’s a simplified view of how EdgeServe might be configured to handle this:
{
"origin_groups": {
"image_origins": {
"origins": [
{
"host": "origin-va.example.com",
"priority": 10,
"weight": 100,
"health_checks": {
"protocol": "HTTP",
"path": "/healthz",
"interval": 30,
"timeout": 5,
"unhealthy_threshold": 3,
"healthy_threshold": 2
}
},
{
"host": "origin-or.example.com",
"priority": 20,
"weight": 100,
"health_checks": {
"protocol": "HTTP",
"path": "/healthz",
"interval": 30,
"timeout": 5,
"unhealthy_threshold": 3,
"healthy_threshold": 2
}
}
],
"failover_strategy": "failover"
}
},
"host_rules": {
"images.example.com": {
"origin_group": "image_origins"
}
}
}
In this setup:
origin_groupsdefines a pool of servers.image_originsis the name of our pool.- Each entry in
originsis a specific origin server. prioritydictates the order of preference: lower numbers are tried first. So,origin-va.example.com(priority 10) is preferred overorigin-or.example.com(priority 20).weightis used when priorities are equal, for load balancing. Here, they’re equal, so it’s 50/50 if both are healthy.health_checksare crucial. EdgeServe periodically pings/healthzon each origin. If it fails 3 times in a row (unhealthy_threshold: 3), the origin is marked unhealthy. It needs 2 consecutive successes (healthy_threshold: 2) to be marked healthy again.failover_strategy: "failover"tells EdgeServe to stop sending traffic to an unhealthy origin and switch to the next available one in priority order.host_rulesmapsimages.example.comto use theimage_originsgroup.
When a user requests an image from images.example.com, EdgeServe first checks the health of origin-va.example.com. If it’s healthy, the request goes there. If origin-va.example.com is unhealthy (e.g., it’s down or its /healthz endpoint is returning 500s), EdgeServe will then try origin-or.example.com. If that one is healthy, the user gets their image, albeit from the Oregon data center.
The health_checks are the eyes and ears of the CDN. If your origin server is overloaded and can’t respond to health checks within the 5-second timeout, it will be marked unhealthy. The interval of 30 seconds means it won’t be checked again for a full half-minute, giving it some breathing room.
The most surprising aspect of CDN failover is how aggressively it can react. If your primary origin is failing health checks repeatedly, the CDN might stop sending any new connections to it within a minute or two, effectively isolating it. This is usually a good thing, preventing it from being overwhelmed and ensuring users get content from a healthy source.
The specific levers you control are the health check parameters. If your origin can technically serve content but is slow, you might need to increase the timeout from 5 seconds to 10 seconds. Conversely, if you want quicker detection of minor issues, you might decrease the unhealthy_threshold to 2. The healthy_threshold determines how quickly an origin is brought back online after recovering; a lower number means faster re-integration.
The next concept you’ll likely encounter is managing multiple origin groups for different types of content, or implementing more sophisticated load balancing strategies beyond simple priority.