GSLB Without Appliances: Global Server Load Balancing as a Service
If you manage infrastructure across multiple locations, whether that’s two data centers, a primary cloud region with a disaster recovery site, or a network of retail and branch locations, you’ve probably encountered the challenge of keeping applications available when something goes wrong.
Global server load balancing (GSLB) is designed to solve that problem. It directs users to the most appropriate location based on factors such as geography, availability, and traffic distribution. If one location becomes unavailable, GSLB helps ensure that users can continue accessing services through another.
The concept is relatively straightforward. The traditional way of implementing it, however, can become surprisingly expensive.
Ask a vendor about deploying GSLB across two data centers, and the proposal may include appliance pairs at each location, software licenses, ongoing support agreements, and professional services to configure everything. What started as a requirement to direct traffic between two sites can quickly turn into a six-figure infrastructure project.
But here’s something worth considering: The three most common GSLB configurations can all be delivered through DNS without deploying or maintaining dedicated appliances.
Geolocation routing, active/passive disaster recovery, and active/active traffic distribution can operate through a globally distributed anycast DNS network. Rather than purchasing and managing the infrastructure responsible for traffic decisions, organizations can consume those capabilities as a managed service.
So how does DNS-based GSLB compare with traditional appliance deployments? And perhaps more importantly, are there still situations where investing in dedicated appliances makes sense?
What Global Server Load Balancing Actually Does
At its core, global server load balancing answers a relatively simple question: When someone tries to access your application or service, which location should handle their request?
The answer depends on how you’ve configured your traffic management policies. You might want users directed to the geographically closest data center, distribute traffic across multiple active locations, or automatically redirect requests when a primary site becomes unavailable.
Traditional GSLB solutions, such as F5 GTM/BIG-IP DNS and Citrix ADC GSLB, typically rely on physical or virtual appliances deployed within an organization’s infrastructure. These appliances act as authoritative DNS servers for selected records and make traffic routing decisions according to defined policies.
DNS-based GSLB performs the same fundamental function, but the underlying architecture is different.
With GSLB as a service, traffic decisions are made through the provider’s globally distributed anycast DNS network. Health monitoring, routing policies, and the infrastructure required to respond to DNS queries are managed by the provider rather than operated on appliances at each customer location.
The distinction matters because organizations gain the ability to manage traffic between sites without introducing another layer of hardware, licensing, and specialized maintenance.
We’re already seeing this shift reflected in the broader market. Cloud-delivered load balancing accounted for approximately 55% of the market in 2025, with annual growth of around 13%, compared with approximately 8% for hardware-based solutions. Analyst coverage of managed DNS also consistently identifies traffic management as one of its fastest-growing segments.
That doesn’t mean appliance-based solutions are disappearing. They continue to play an important role in certain environments. But for organizations primarily concerned with directing users between healthy locations, DNS-based GSLB offers a compelling alternative.
Three Common GSLB Configurations, All Delivered Through DNS
Most organizations evaluating global server load balancing are trying to address one or more of three common requirements. They want users directed to an appropriate geographic location, they need traffic to move automatically when a site fails, or they want multiple locations actively sharing traffic.
All three scenarios can be handled through DNS.
1. Geolocation Routing: Directing Users to the Right Location
Imagine an international retailer operating data centers in Europe and North America. Ideally, European shoppers should connect to infrastructure hosted in Europe, while North American customers should be directed to infrastructure closer to them.
This approach can improve the user experience by reducing the distance traffic needs to travel. In some environments, geographic routing is also used to support regional data residency policies. A public-sector organization, for example, may need to direct citizens to services hosted within national borders.
With DNS-based geolocation routing, the authoritative DNS provider determines the approximate geographic origin of a DNS request, usually using information about the recursive resolver’s network or EDNS Client Subnet data where available.
Based on that information, DNS returns an appropriate destination for the requested service.
For example, a user in Germany requesting www.example.com might receive the IP address of a server in Frankfurt. Someone accessing the same domain from the United States could receive the address of a server in Virginia.
Both users request the same website, but DNS directs them toward different infrastructure according to the geographic routing policy.
The important difference is where that decision happens. Instead of relying on appliances deployed at each data center, the managed DNS provider makes the decision through its global network of points of presence.
Geolocation policies can also be applied to individual DNS records. There’s no requirement to route an entire DNS zone geographically when only a handful of public-facing applications need this functionality.
2. Active/Passive Disaster Recovery: Keeping Services Available When a Site Fails
For many businesses, the primary reason for considering GSLB is disaster recovery.
Consider an organization operating its production systems from Site A, with Site B maintained as a backup. Under normal conditions, all traffic goes to Site A. But if that site experiences a power failure, network disruption, unsuccessful deployment, or regional cloud outage, users need to be directed to Site B.
Ideally, this should happen automatically. Nobody wants their disaster recovery strategy to depend on an engineer waking up at 3 a.m. to change DNS records.
The requirement becomes even more important for organizations delivering critical services. Police forces and other operators of essential systems, for example, may have explicit obligations to keep citizen-facing services available even when an entire facility is lost.
While the resilience requirement itself is easy to understand, implementing it through traditional infrastructure can become costly.
DNS-based GSLB provides an alternative by combining external health monitoring with automated DNS failover.
The managed DNS platform continuously checks the availability of the primary endpoint from multiple monitoring locations. If enough checks indicate that Site A is unavailable, the authoritative DNS service stops returning its IP address and begins returning the address of Site B.
Once the primary site recovers and successfully passes the configured health checks, traffic can be directed back to Site A according to the recovery policy.
Detection typically takes around 60 to 90 seconds, with the practical failover window determined by the detection time and the DNS record’s time to live (TTL). In most configurations, that means recovery can occur within minutes rather than hours, without manual intervention.
There is one important technical distinction to understand. DNS failover affects new DNS resolutions. Users or recursive resolvers that have already cached the previous address may continue using it until their cached records expire.
For most site-level disaster recovery requirements, that convergence period is acceptable, particularly when low TTL values are used. However, it is worth considering when designing recovery time objectives.
For a deeper explanation of the process, see our article on DNS failover.
3. Active/Active Round-Robin: Sharing Traffic Across Healthy Locations
Not every organization wants one data center sitting idle until there’s an outage.
In an active/active configuration, multiple sites handle production traffic simultaneously. This allows organizations to use available infrastructure more effectively while maintaining resilience if one location becomes unavailable.
For example, a business operating two data centers might want both locations serving requests throughout the day. If one site experiences a problem, it should automatically be removed from the available destinations until it recovers.
DNS-based GSLB supports this through round-robin distribution combined with health monitoring.
The authoritative DNS server returns multiple healthy endpoints and rotates their order between queries, helping distribute requests across the available locations. Because health checks continuously monitor those endpoints, a location that fails its checks can be removed from DNS responses.
When the failed location recovers, it can be added back into the rotation automatically.
This gives organizations a combination of active/active traffic distribution and failover protection without requiring dedicated GSLB appliances at each location.
It’s essentially the same traffic management objective that traditional appliance-based GSLB solutions are designed to achieve, delivered through DNS instead.
The Resilience Problem with Appliance-Based GSLB
There’s an architectural issue with traditional appliance GSLB that deserves more attention than it usually receives.
The appliances responsible for making routing decisions are often deployed inside the same facilities they’re intended to protect. That means their availability may depend on the very network connections and infrastructure that could be affected by an outage.
Consider a data center with a 10 Gbps internet connection. Its GSLB appliances sit behind that connection, managing DNS-based traffic decisions.
Now imagine the site becomes the target of a 20 Gbps distributed denial-of-service (DDoS) attack.
The incoming traffic exceeds the available connection capacity. Once that connection becomes saturated, the appliances behind it may no longer be reachable, even if they’re functioning perfectly.
At precisely the moment the organization needs its traffic management infrastructure to respond, the infrastructure responsible for making those decisions may become inaccessible.
This is more than a theoretical concern. According to the figures cited in the original research, 47.1 million DDoS attacks were mitigated globally in 2025, representing a 121% year-over-year increase. Record-breaking attacks are now measured in tens of terabits per second.
Against that scale of attack, the 1 to 10 Gbps connections commonly found at individual sites can become an obvious vulnerability.
The situation becomes even more problematic when GSLB appliances across multiple sites share a DNS decision-making infrastructure that can itself be affected by an attack.
This creates an uncomfortable contradiction: An organization may invest heavily in resilience technology only to discover that the technology shares the same failure domain as the infrastructure it’s supposed to protect.
DNS-based GSLB approaches the problem differently.
Instead of placing the traffic decision-making infrastructure at the organization’s own sites, that function operates on a distributed anycast DNS network.
These networks span multiple global points of presence, often across major internet interconnection locations, with aggregate capacity measured in terabits rather than the bandwidth available through a single data center connection.
If Site A becomes overwhelmed by attack traffic, the DNS infrastructure responsible for directing users to Site B remains outside the affected facility.
The routing decision can still be made because it doesn’t depend on the availability of Site A’s internet connection.
That separation is an important architectural advantage. It doesn’t eliminate the need to protect individual applications or data centers against DDoS attacks, but it helps ensure that the DNS traffic steering layer doesn’t fail alongside the site experiencing the problem.
The Real Cost of GSLB: Appliances vs. GSLB as a Service
When organizations compare global server load balancing solutions, the initial purchase price is often the most visible difference. But hardware costs are only one part of the investment.
Traditional appliance deployments bring additional expenses associated with licensing, support agreements, specialist engineering skills, ongoing maintenance, and expanding the infrastructure as new locations are added.
A fair comparison needs to consider the entire operating model.
Two areas in particular can have a significant impact on long-term cost: scalability and the availability of specialist skills.
Scaling Without Buying More Infrastructure
With appliance-based GSLB, expanding from two data centers to three may involve purchasing another pair of appliances, adding licenses, configuring the environment, and maintaining the new deployment over time.
Adding a fourth site or another cloud region can mean repeating that process.
With DNS-based GSLB, expansion is primarily a configuration exercise. The new endpoint is added to the appropriate DNS routing policy, health checks are configured, and traffic management rules are updated.
For organizations expanding into additional cloud regions, implementing hybrid infrastructure, or supporting multiple geographic markets, that difference can be substantial.
Reducing Dependence on Specialist Skills
The operational cost of maintaining GSLB appliances is another consideration.
Experienced F5 and Citrix engineers have valuable, specialized skills, but those skills can be expensive and difficult to recruit. Organizations also need to consider what happens when the people responsible for configuring and maintaining these systems leave.
With managed DNS-based GSLB, much of that infrastructure responsibility moves to the service provider. Internal teams still need to understand their applications, routing requirements, and recovery policies, but they no longer need to maintain dedicated GSLB appliances.
Instead, they work with DNS policies, a management interface, and the support of the provider’s engineering team.
What Does DNS-Based GSLB Actually Cost?
Pricing varies between providers, but the difference in purchasing models is worth examining.
Published entry-level pricing for enterprise DNS traffic management services from major providers generally starts around $99 to $349 per month, with more advanced enterprise offerings moving to custom quotes.
Cloud platforms such as Amazon Route 53 and Azure Traffic Manager offer comparable traffic management capabilities using usage-based pricing models, including charges associated with DNS queries and health checks.
Those services can be inexpensive to get started with, but organizations may need to assemble and manage several components, while additional support can increase the overall cost.
This leaves an interesting gap in the mid-market.
Many organizations need reliable global traffic management, health-checked failover, per-record geolocation routing, and access to experienced support engineers. They don’t necessarily want the complexity of an enterprise appliance deployment, nor do they want to build and maintain a collection of separate cloud services.
For those businesses, a managed DNS service offering predictable subscription pricing and integrated GSLB capabilities can be a particularly attractive option.
When Traditional GSLB Appliances Still Make Sense
It’s important to recognize that DNS-based GSLB isn’t the right answer for every environment.
We provide managed DNS services, so naturally we see significant value in delivering GSLB through DNS. But there are legitimate technical and operational reasons why organizations may continue investing in appliance-based infrastructure.
When connection-level load balancing is required. If an organization needs sub-second failover, SSL offloading, Layer 7 content switching, or load balancing between server pools within a data center, an application delivery controller (ADC) remains an appropriate solution. These are local traffic management functions rather than global DNS steering requirements. GSLB directs users between locations; it doesn’t replace the load balancing infrastructure operating inside those locations.
When extremely strict latency or determinism requirements apply. Large financial institutions, telecommunications operators, and exchanges may operate environments where precise traffic behavior, timing, and control are critical. Organizations with the engineering resources to support these requirements may have good reasons to maintain dedicated appliances.
When regulatory or organizational policies restrict external dependencies. Certain sovereign, government, and defense environments may prohibit external services from controlling critical traffic decisions. Although these circumstances are relatively uncommon, they can make internally operated traffic management infrastructure necessary.
When applications operate entirely across private networks. Organizations whose sites are connected through a private WAN and whose users access services internally may have no requirement for a public DNS resolution path. In these environments, internal appliances or an internal DNS-based GSLB implementation may be more suitable.
The distinction comes down to what the organization is actually trying to accomplish.
If the requirement involves sophisticated traffic management within a data center, appliances may be entirely justified. If the requirement is simply to direct users to the right healthy site across multiple locations, it’s worth questioning whether dedicated GSLB hardware is necessary.
What to Look for When Choosing GSLB as a Service
Not every DNS-based GSLB offering delivers the same capabilities, and the differences aren’t always obvious from product descriptions.
Before selecting a provider, there are several areas worth investigating.
Support for all three GSLB configurations. Look for a service that supports geolocation routing, active/passive failover, and round-robin distribution with health-based endpoint removal. Ideally, these capabilities should be configurable and combinable at the individual DNS record level rather than requiring separate products.
Health monitoring from multiple locations. A single monitoring location can produce misleading results when its own network connectivity is disrupted. Multiple external health checks with configurable thresholds help reduce the risk of an unnecessary failover.
Support for low DNS TTL values. Because DNS-based failover depends on cached records expiring, TTL configuration matters. Make sure the provider supports low TTLs for traffic steering records, while recognizing that actual cache behavior also depends on recursive resolvers.
A genuinely global anycast DNS network. The resilience benefits of managed GSLB depend heavily on the provider’s architecture. A distributed network of authoritative DNS points of presence helps ensure that traffic decisions remain available even when individual sites or network paths experience problems.
Independence from your application hosting provider. If your DNS infrastructure depends entirely on the same cloud provider hosting your workloads, a broader provider outage could affect both the application and the mechanism intended to redirect traffic. Independent DNS infrastructure can help reduce that shared dependency.
Protection against configuration mistakes. Not every outage begins with a cyberattack or hardware failure. Incorrect DNS changes can disrupt services just as effectively, particularly when those changes propagate globally. Audit logs and the ability to restore previous zone configurations are important operational safeguards. For more on DNS architecture and resilience, see our article on secondary DNS and hidden primary configurations.
Transparent pricing and accessible technical support. The purpose of moving to GSLB as a service is partly to simplify infrastructure management. If a provider still requires lengthy procurement cycles, complicated licensing discussions, and expensive professional services for routine changes, much of that benefit disappears. Published pricing and direct access to experienced engineers can make a meaningful difference.
Ultimately, the value of DNS-based GSLB isn’t simply that it removes hardware. It’s that it can make sophisticated global traffic management easier to deploy, operate, and expand without compromising the underlying resilience objectives.
Getting Started with GSLB Without Appliances
Moving from appliance-based GSLB to a managed DNS service may sound like a significant infrastructure change, but it doesn’t necessarily require changes to the applications or data centers themselves.
In many cases, the process begins by identifying the public-facing services that need global traffic management. These might be a customer portal, an eCommerce platform, an API endpoint, or another business-critical application operating across multiple locations.
The relevant DNS records are then delegated to the managed DNS provider, health checks are configured against each site’s endpoints, and the appropriate traffic management policies are established.
Depending on the business requirement, those policies might direct users geographically, maintain a standby disaster recovery location, or distribute traffic across several active sites.
The underlying infrastructure remains in place. Servers don’t need to move, applications don’t need to be rebuilt, and no additional GSLB appliances need to be installed in the traffic path.
At Total Uptime, we’ve built these capabilities into our managed DNS platform, allowing organizations to implement geolocation routing, health-checked active/passive failover, and active/active round-robin distribution through our global anycast network.
DNS failover is included in every plan, and our senior DNS engineers are available to help organizations configure and manage their traffic policies.
For businesses currently evaluating traditional GSLB appliances, the financial and operational differences can be significant. What might otherwise require a substantial hardware investment can often be delivered through a predictable managed service subscription.
You can explore our Global Server Load Balancing solution or review our published pricing to see how the options compare.
And if you’re currently looking at an appliance GSLB proposal, our team can help you evaluate the requirements and determine what an equivalent DNS-based deployment would look like.
Because when the goal is simply to keep users connected to a healthy application location, it’s worth asking whether another rack of hardware is really the best way to achieve it.
