Ok, before I start to fan the flames, let me start with the usual caveat; GSLB doesn't ALWAYS suck — just more often than you'd think, for these reasons...
What you'll learn:
- The 'Indestructibility' Checklist: Why you shouldn't even touch GSLB until you’ve fortified your primary site’s infrastructure.
- The Latency Trap: Why chasing low geo-latency is a distraction, and why locality is the real secret to performance.
- Public vs. Private Health: The critical difference between knowing an endpoint is 'up' and knowing your application is actually performing.
- The Hidden Cost of Dumb Routing: How poor GSLB configurations lead to massive WAN bandwidth waste in AI and Object Storage environments.
- The Hybrid Advantage: How to strategically combine the strengths of Cloudflare’s edge with 'Smart GSLB' for a failproof, high-performance stack.
A false start?
There's normally two things customers ask for when they approach us saying they want GSLB:
- Active-Passive failover between two internet sites (for Disaster Recovery and High Availability).
- Active-Active load balancing between two or more geographically dispersed sites i.e. Europe and USA (this uses the closest site for speed and high availability).
Sounds simple enough, doesn't it?
But let's briefly step back to what we should have done first, which is make sure our primary site (and all sites for that matter) is as indestructible as possible.
Have you already got the following?
- 2 x internet feeds
- 2 x switch fabrics
- 2 x fFirewalls
- 2 x load balancers (no persistence/sticky here please, we want high availability after all)
- 3+ x web servers
- 2+ x database servers (gee, I wonder if we could put the persistence here?)
Done that? No? Then go and do that first before you think about GSLB.
Assuming you've done that already, then great, by all means explore GSLB.
Next, I'm going to explain what GSLB is, and quite simply what it isn’t…
What people think GSLB is and why you’re probably doing it wrong
A lot of people think that GSLB is all about using the closest data center to your location so that you get low latency for remote workers.
Yes, that’s important and we definitely recommend you use something like Cloudflare for that, and while you’re at it make use of their excellent CDN features for static content.
But when it comes to true multi-site applications like AI & Object Storage. Then saving a few milliseconds of latency is not important. What’s important is getting 100X the performance for local applications and storage, by ensuring local traffic in the data center stays local. And saving 10X bandwidth costs on data center WAN connections for replication of data.
GSLB isn’t about geography. It’s about locality, health, and app awareness. So if your load balancer doesn’t know what your application is doing, it’s not smart load balancing — it’s just hoping.
| Feature | Sucky GSLB | Smart GSLB |
|---|---|---|
| Performance | Geo-latency: Cloudflare’s geo-IP routing picks the nearest edge, reducing latency — but it doesn’t help with application performance. | Locality-based: Smart GSLB understands your internal infrastructure, not just the user’s latency. |
| Health checks | Public health checks: Geo-routing health checks are great. But they only see your public end points and whether they’re online or not. | Private health checks: Smart GSLB, on the other hand, monitors and load balances based on real-time application performance. |
Cloudflare’s global network is built for broad website content delivery — not high performance applications for AI and storage infrastructure.
Luckily, Smart GSLB works seamlessly with Cloudflare so we recommend that you use both.
How can you get GSLB right and make sure it doesn’t suck?
Smart GSLB uses real-time data to intelligently route traffic. Because it understands where your applications and users are, and how your infrastructure is configured using site-specific subnet topology.
This is crucial for critical applications using object storage, such as expensive AI infrastructure where bandwidth constraints cost a huge amount of wasted time and money. Or for critical healthcare systems, where data sovereignty and uptime are non-negotiable.
And when it all goes wrong our GSLB ensures quick multi-site failover, meaning no manual DNS updates and zero downtime for your critical applications.
By combining real-time health checks, application awareness, and true locality-based logic, Smart GSLB intelligently routes every request to the right place on the first attempt, making sure it’s fast, secure, and compliant.
But the most important thing is not the technology — it’s the people who help you get it done right.
My takeaway?
So even though Cloudflare does a pretty good job at what people think they want from GSLB, it sucks in comparison to Smart GSLB.
And there are definitely a couple of situations where Smart GSLB is awesome!
The primary reason to use a GSLB is for multi-site resilience; when you need site failover or more importantly locality based routing i.e. use local site first to save on bandwidth costs and latency.
The secondary reason to use GSLB is when you need seriously high performance load balancing (for example large multi-site object storage systems).