Introducing Bunny CDN Load Balancer: make your origins work together

Say your application runs in two regions, with a third held in reserve. You want the first two to share everyday traffic, and the standby region to step in when they cannot serve it. When an origin fails, those priorities should still determine where the request goes next.

At bunny.net, we want you to be able to express that plan once and have the CDN carry it through from normal traffic distribution to failover.

Today, we’re introducing Bunny CDN Load Balancer, available now in Public Preview. It distributes HTTP(S) requests from your Pull Zones across the origins you configure, using your routing preferences alongside origin health and performance.

Set priorities across your origin pool

A Load Balancer is a routing policy in your bunny.net account. Attach it to one Pull Zone or reuse it across several. Requests that need an origin follow that policy; cached responses continue to be served directly from the CDN edge.

Origin groups let you organize backends by region, provider, capacity, or purpose. In our example, the two primary regions would sit in the first priority tier, with the standby region in a later tier. Traffic can be shared across primary groups while backup capacity waits behind them.

You can spread traffic evenly, assign weights, or favor nearby or lower-latency groups. The pool can combine standard HTTP(S) servers, Bunny Storage, Edge Scripting, and Magic Containers, so your primary and standby capacity can use different types of backend.

Keep your priorities intact during failover

For each request that needs an origin, the edge builds an ordered list of eligible destinations before contacting the first one. It orders the origin groups, then the origins within them, according to your priority tiers and balancing settings.

When another attempt is safe, the next candidate is already known. In our example, eligible primary capacity stays ahead of the standby region throughout failover.

Retries also take account of what a request can do. After an origin returns a 5xx response, only requests that are safe to replay are tried again. Requests with a body, or a method that may create or change data, are not blindly repeated after that response. This reduces the risk of turning a failed request into a duplicate order, upload, or payment.

The failover chain has a time limit, so one request cannot keep working through slow origins indefinitely.

Respond to health at each edge

An origin can be reachable from the Frankfurt edge while a network problem prevents the São Paulo edge from reaching it. Load Balancer combines a network-wide health view with what each edge sees in live traffic.

Optional health checks monitor origins in a group from across the bunny.net network. A degraded origin is excluded from normal rotation globally until it passes a health check again. Each edge also reacts to failures it encounters locally, even when active checks are disabled, so it can respond to a problem affecting its own requests.

If no healthy origin remains, Load Balancer can attempt an unhealthy origin as a last resort. Origins and groups you explicitly disable stay excluded.

For applications that need repeat requests to reach the same origin, optional sticky sessions use an encrypted edge cookie to maintain that choice. Health takes precedence: if the chosen origin becomes unhealthy or unavailable, the visitor is assigned another origin.

Balance speed and capacity

Repeatedly sending traffic to the origin with the lowest measured latency can make it the busiest, eroding the speed advantage that put it first. That’s why latency-based origin balancing also considers requests already in flight. As an origin becomes busier, it grows less attractive for new requests, helping the rest of the pool share the load.

Stale and newly added origins are re-tested automatically. Probing backs off when they remain slow or unavailable, while recovered origins can be considered for traffic again.

Start balancing your origin traffic

Public Preview is available now for $9.50 per month per Load Balancer, including 50 million origin-bound requests each month. Additional requests are billed at $0.65 per million.

Requests served from the CDN cache do not count. Sharing a Load Balancer across multiple Pull Zones uses one monthly fee and one shared request allowance.

To get started:

• Create a Load Balancer and choose how traffic should be distributed between origin groups.
• Add your origin groups and the origins each should contain, setting priorities to reflect your primary and standby capacity.
• Set your Pull Zone’s origin type to Load Balancer and select the configuration you created.

Once traffic is flowing, use the dashboard or API statistics to see how requests are distributed, how each origin is performing, and where failover is happening. The Load Balancer documentation covers the routing, health-check, sticky-session, and API options in detail.

Log in or sign up today to join the Public Preview and start balancing your origin traffic with automatic failover.