Intelligent traffic distribution for high availability and low latency
Load balancing is commonly used to manage traffic flow between redundant systems, such as web servers or CDN services. All systems in the configuration are always “live” and each handles a share of incoming traffic. That way, if one system is unavailable, the rest will take over the load with no appreciable impact
These kinds of multi-cloud architectures have sky-rocketed in popularity over the past few years, thanks to advances in DNS management, which have made load balancing across multiple cloud services significantly more affordable and accessible than traditional hardware load balancers.
DNS Load Balancing distributes your query traffic across multiple resources based on resource availability and performance.
Talk to an Expert→DNS load balancing is also remarkably faster since there are no extra lookups to a third-party service. Everything happens right at the DNS level! Your DNS records act as a sort of traffic director, choosing what traffic to send to which resource. Constellix takes things one step further, by letting you inject your own custom logic into your configurations. You can apply rules that optimize traffic flow based on resource performance, cost, and network topography. Or write your own rules based on the querying client’s location or network.
Easily integrate health checks into your LB configurations, with baked-in Failover. Failover automatically moves your traffic from unavailable resources to healthy ones.
The "most affordable" and "easiest to configure" kind of load balancing.
✓ DNS Failover is natively integrated with almost all of our services:
✓ GeoProximity
✓ Global Load Balancing
✓ Traffic Steering
✓ Round Robin
✓ Latency Load Balancing
Failover is supported for A, AAAA, ANAME, and CNAME records. All you need to do is enable Failover for your record, and specify the IP addresses or hostnames of your "backup" resources. These backups are only used when the primary IP/hostname is unavailable.
The most basic of load balancing services is called round-robin. Round-robin is often compared to a rotor because it returns one endpoint at a time in a cyclical manner.
Let’s say you want to point your domain to three geographically distributed web servers: 4.4.4.4 , 2.2.2.2 , and 3.3.3.3 with round-robin enabled. Each time your domain is queried, it will return the next IP in the list.
You can integrate monitoring checks with your round-robin/multi-value configurations. That way, only healthy endpoints are served to users. If an endpoint is detected as down, it will be removed from the rotation. But if it comes back as healthy, it will be included in the next cycle. You can also use Round Robin with Failover if you want just one endpoint to be returned unless it is down. If it does come back as down, then we will Failover the other endpoints, which will be returned in a round-robin fashion.
In this case, you would create two pools, one with just your primary endpoint. The second pool would contain the endpoints you want to Failover to.
ITO, Internet Traffic Optimization, uses integrated monitoring checks, just like Round Robin with Failover, but it can also account for the round trip time (RTT) of the systems in your load balancing configuration.
Enable ITO in your load balancing pools, and traffic will only be sent to the fastest responding resource(s). You can choose to return one or multiple resources in an ITO pool.
Latency load balancing is ideal for multi-vendor configurations like multi-CDN, multi-DDoS, or multi-cloud.
Keep in mind... Latency load balancing is configured by region, so you want to have multiple resources in whichever region you are using this feature.
All of our load balancing services can be configured regionally. That means the load balancing policy will only be used when a user from a specified region makes a query for that record.
Regional load balancing can be used to build your own region-specific CDN (Content Delivery Network), create custom routing rules for a single region, and so much more.
what our customers say:
For critical web applications, you need to have an independent system that is capable of monitoring your primary infrastructure, detecting failure, and switching to an independent secondary system.
verified reviewer