导航|地址|刷新
Load Balancing Reference Architecture

Skip to contentDocumentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/reference-architecture/llms.txt
Use this file to discover all available pages before exploring further.

Docs Directory API SDKs Changelog

Search

Log in

Reference Architecture

/

Overview

How to use

Find by solution

Reference Architectures

Cloudflare SASE with CrowdStrike

Cloudflare SASE with Microsoft

Cloudflare SASE with SentinelOne

Content Delivery Network (CDN)

Load Balancing

Magic Transit

Multi-Vendor Architecture

Secure Access Service Edge (SASE)

Security Architecture

AI Security for Apps

Email Security Deployments

Reference Architecture Diagrams

Artificial Intelligence (AI)

AI Vibe Coding Platform

Automatic captioning for video uploads

Composable AI architecture

Content-based asset creation

Enterprise AI Vibe Coding Platform

Ingesting BigQuery Data into Workers AI

Multi-vendor AI observability and control

Retrieval Augmented Generation (RAG)

Enterprise AI agent workspace

Bots

Bot management

Content Delivery

Optimizing image delivery

Distributed web performance

Internet of Things (IoT)

Connected transportation systems

Network

BYOIP to Cloudflare

Device roaming with geolocated IPs

Protect data center networks

Protect hybrid cloud networks

Protect ISP and telecommunications networks from DDoS attacks

Protect public networks

Secure Access Service Edge (SASE)

Access to private apps without having to deploy client agents

Cloudflare One Appliance deployment

DNS filtering solution for Internet service providers

Protective DNS for governments

Secure access to SaaS applications

Self-hosted VoIP for hybrid users

Zero Trust and Virtual Desktop Infrastructure

ZTNA with external authorization

Security

FIPS 140 level 3 compliance with Cloudflare Application Services

Securing data at rest

Securing data in transit

Securing data in use

Serverless

A/B-testing using Workers

Fullstack applications

Programmable Platforms

Serverless ETL pipelines

Serverless global APIs

Serverless image content management

Storage

Control and data plane architectural pattern for Durable Objects

Egress-free object storage in multi-cloud setups

Event notifications for storage

On-demand Object Storage Data Migration

Storing user generated content

Design Guides

Cloudflare's benefits for SaaS providers

Leveraging Cloudflare for your SaaS applications

Zero Trust for SaaS applications

Designing ZTNA access policies

Network-focused VPN migration

Secure application delivery

Securing guest wireless networks

Streamlined WAF deployment across zones and applications

Zero trust architecture for startups

Implementation Guides

Zero Trust

Secure your Internet traffic and SaaS apps ↗

Replace your VPN ↗

Secure your email with Email security ↗

Deploy clientless access ↗

Holistic AI Security with Cloudflare One ↗

Application Security

Use mTLS with Cloudflare protected resources ↗

Agent resources

Agent setup ↗

Cloudflare Skills ↗

Code Mode MCP Server ↗

Domain-specific MCP Servers ↗MCP

Reference Architecture llms.txt ↗

Reference Architecture llms-full.txt ↗

Cloudflare Docs llms.txt ↗

Cloudflare Docs llms-full.txt ↗

Home

/Reference Architecture

/Reference Architectures

/Load Balancing

Load Balancing Reference Architecture

Last updated Jun 21, 2026|Copy as Markdown|View as Markdown|Agent setup

OverviewIntroduction Who is this document for and what will you learn?Handling dynamic workloads in modern applications Concepts and terminology Challenges addressed by load balancers Types of traffic managementCloudflare Load Balancing architecture and design Inherent advantages in the Cloudflare architecture The structure of a Cloudflare Load Balancer Steering types and methods Health monitors Endpoints and endpoint pools Load balancers Protecting and securing load balancersSummary

Introduction

Cloudflare Load Balancing is a SaaS offering that allows organizations to host applications for a global user base while vastly reducing concerns of maintenance, failover, resiliency, and scalability. Using Cloudflare Load Balancing allows organizations to address the following challenges:

Efficiently handling large volumes of incoming traffic, especially during unexpected surges or spikes.

Ensuring applications and services remain accessible to users.

Maintaining quick response times and optimal performance for all users, especially during high traffic periods.

Adapting to changing traffic demands and ensuring the infrastructure can accommodate growth.

Helping applications and services resist Distributed Denial of Service (DDoS) attacks.

Cloudflare Load Balancing is built on Cloudflare’s connectivity cloud, a unified, intelligent platform of programmable cloud-native services that enable secure any-to-any connectivity between all networks (enterprise and Internet), cloud environments, applications, and users. It is one of the largest global networks, with data centers spanning over 330 cities and interconnection with over 13,000 network peers. It also has a greater presence in core Internet exchanges than many other large technology companies.

As a result, Cloudflare operates within ~50 ms of ~95% of the world’s Internet-connected population. And since all Cloudflare services are designed to run across every network location, all requests are routed, inspected, and filtered close to their source, resulting in strong performance and consistent user experiences.

This document describes a reference architecture for organizations looking to deploy both global and local traffic management load balancing solutions.

Who is this document for and what will you learn?

This reference architecture is designed for IT, web hosting, and network professionals with some responsibility over or familiarity with their organization's existing infrastructure. It is useful to have some experience with networking concepts such as routing, DNS, and IP addressing, as well as basic understanding of load balancer functionality.

To build a stronger baseline understanding of Cloudflare and its load balancing solution, we recommend the following resources:

What is Cloudflare? | Website ↗ (5 minute read) or video ↗ (2 minutes)

Solution Brief: Cloudflare Private Network Load Balancing ↗ (5 minute read)

Solution Brief: Cloudflare GTM Load Balancing ↗ (5 minute read)

Blog: Elevate load balancing with Private IPs and Cloudflare Tunnels: a secure path to efficient traffic distribution ↗ (13 minutes)

Those who read this reference architecture will learn:

How Cloudflare Load Balancing can address both Private Network Load Balancing and global traffic management use cases.

How Cloudflare’s global network enhances the functionality of Cloudflare Load Balancing.

The capabilities of Cloudflare Load Balancers, and how they apply to various use cases.

The structure of Cloudflare Load Balancers and their various configurations.

Handling dynamic workloads in modern applications

Concepts and terminology

Endpoint

In this document, the term “endpoint” is any service or hardware that intercepts and processes incoming public or private traffic. Since load balancing can be used for more than just web servers, the term endpoint has been chosen to represent all possible types of origins, hostnames, private or public IP addresses, virtual IP addresses (VIPs), servers, and other dedicated hardware boxes. It could be on-premises or hosted in a public or private cloud — and could even be a third-party load balancer.

Steering

Steering is a load balancer’s main function — the process of handling, sending, and forwarding requests based on a set of policies. These policies generally take many factors into account, including request URL, URL path, HTTP headers, configured weights, priority, and endpoint latency, responsiveness, capacity, and load.

Layer 7

Layer 7 ↗ of the OSI model ↗, also known as the application layer, is where protocols such as SSH, FTP, NTP, SMTP, and HTTP(S) reside. When this document refers to layer 7 or layer 7 load balancers, it means HTTP(S)-based services. The Cloudflare layer 7 stack allows Cloudflare to apply services like DDoS protection, Bot Management, WAF, CDN, Load Balancing, and more to a customer's website to improve performance, availability, and security.

Layer 4

Layer 4 of the OSI model ↗ — also called the transport layer — is responsible for end-to-end communication between two devices. Network services that operate at layer 4 can support a much broader set of services and protocols. Cloudflare’s public layer 4 load balancers are enabled by a product called Spectrum, which works as a layer 4 reverse proxy. In addition to offering load balancing, Spectrum provides protection from DDoS attacks ↗ and can conceal the endpoint IP addresses.

SSL/TLS Offloading

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols used to secure connections over the Internet. SSL and TLS offloading, also known as SSL/TLS termination or SSL/TLS acceleration, is a technique used in load balancers and web servers to handle the SSL/TLS encryption and decryption process without affecting an endpoint’s performance. SSL/TLS offloading improves server performance, simplifies certificate management, and enhances scalability by offloading the resource-intensive encryption and decryption tasks to dedicated devices, helping endpoints remain dedicated to serving content and application logic.

Challenges addressed by load balancers

Modern websites, or any applications for that matter, face three main challenges:

Performance: Ensuring that the application responds to users requests and input in a timely manner

Availability: Maintaining the uptime for the application, so it is always able to respond to user requests

Scalability: Growing, shrinking, or relocating application resources based on user behavior or demand.

Performance

Application performance can be affected by several factors, but the most common cause of performance issues is the amount of usage or load placed on an endpoint. An endpoint generally has a finite amount of compute resources it can provide. If too many requests arrive at once, or if the type of requests cause increased CPU/memory usage, the endpoint will respond slower or fail to respond at all.

To address these challenges, endpoints can be upgraded with more compute resources. But during idle or low-usage times, the organization ends up paying for underutilized resources. Organizations may also deploy multiple endpoints — but to seamlessly steer traffic between them, a load balancing solution is needed to make this process seamless to the end user.

Figure 1 shows how load might be distributed without a load balancer:
Figure 1: Endpoint performance can suffer without a load balancer
Load balancers allow organizations to host several endpoints and portion out traffic between them, ensuring no single endpoint gets overwhelmed. The load balancer handles all incoming requests and forwards them to the appropriate endpoint. The client doesn’t need any knowledge of endpoint availability or load — it just needs to send the request to the load balancer and the load balancer handles the rest. Figure 2 shows how a load balancer can evenly distribute traffic from users across a set of endpoints.
Figure 2: Load balancers help distribute load across endpoints
Another performance-related issue has to do with the distance between a client and an endpoint. Whether due to the mere fact of traveling farther, or having to make more network hops, a request that travels a longer distance generally has a higher round-trip time (RTT).

RTT becomes important at scale. For example, if a client and endpoint are both located in the United States, it would be reasonable to expect a RTT of 25ms. If the client has 20 requests it needs responses to, the total time required to handle them sequentially (not including compute time) would be 500ms (20 x 25ms). And if the same client connected from the APAC region the RTT might be upwards of 150ms, resulting in an undesirable total loading time of 3000ms (20 x 150ms). (Certainly, request streaming enhancements in HTTP/2 and HTTP/3 might change this math — but in websites with dynamic or interactive content, where a response’s information is used to generate additional requests, the example still holds in general.) Figure 3 illustrates how this happens.
Figure 3: How latency can compound and affect the total time it takes to load a resource
In the same way a load balancer can pass traffic to a less-busy endpoint, it can also pass traffic to a geographically closer endpoint, resulting in a more responsive experience for the client. Specifically, the load balancer performs a lookup of the IP address that sent the request, determines its location, and selects the closest or most region-appropriate endpoint to send it to (this is similar to functionality provided by DNS solutions like GeoDNS).

Availability

Service availability encompasses both unintentional and intentional downtime of endpoints behind a load balancer. Several factors can contribute to unintentional downtime, including hardware failure, software bugs, network issues, and ISP or other vendor issues. Even for the most advanced organizations, these issues are inevitable.

…