Steer traffic. Survive failures. Live.
Watch traffic re-route when a pool fails.
Origin pool
US-East origin
Region: Ashburn. Cloudflare LB sends ~30% of traffic to this pool when all members are healthy. Health checks run from every Cloudflare PoP; on failure, traffic re-routes to healthy peers within seconds.
On this page
Nanosek provides Cloudflare Load Balancing services for organizations that need traffic steering, origin resilience, health-check-based failover, and multi-region distribution. The service covers architecture design, origin pool configuration, health check design, traffic steering policy selection, session affinity, geo routing, weight-based distribution, failover testing, monitoring, and managed Cloudflare operations.
Who this is for
What Cloudflare Load Balancing helps solve
Single origin failure causing outages
Without load balancing and health checks, a single origin failure takes down the entire application. Cloudflare Load Balancing detects failures and routes traffic to healthy origins within seconds.
No traffic distribution across data centers
Applications deployed across multiple data centers or regions need traffic distributed to match capacity, latency, and geographic routing requirements.
Manual failover dependent on DNS TTL
DNS-based failover is slow, unreliable, and creates long outage windows. Cloudflare Load Balancing uses health checks and steering to move traffic in near real-time without waiting for DNS propagation.
Origin overload during traffic spikes
Weighted distribution and active health checks let Nanosek design origin pools that spread load proportionally and protect origins from sudden traffic spikes.
Multi-cloud traffic management complexity
Organizations running workloads across AWS, Azure, GCP, and on-premises need a single traffic management layer. Cloudflare Load Balancing provides a unified steering and failover model.
No geographic routing for global applications
Geo steering routes users to the nearest origin region by latency or geographic location, reducing round-trip time and improving user experience for globally distributed applications.
Session affinity requirements
Applications with stateful sessions that cannot be broken mid-journey need session affinity policies that keep returning users on the same origin pool.
Canary and progressive traffic shifting
Weighted steering allows controlled traffic shifting to new origins, regions, or application versions for canary deployments and progressive rollouts.
Latency-sensitive routing decisions
Dynamic steering uses real-time origin latency data to select the fastest origin at the time of each request rather than relying on static weight assignments.
No visibility into origin health and traffic distribution
Cloudflare Load Balancing analytics provide pool-level health status, origin response time, failover events, and traffic distribution visibility through dashboards and Logpush.
Absence of health-check-aware WAF and bot decisions
Load Balancing integrates with Cloudflare WAF and Bot Management so security decisions can account for origin capacity and health state when steering traffic.
Migration from legacy load balancers
Migrating from F5, HAProxy, AWS ALB, NGINX, or hardware load balancers requires policy translation, health check parity, session handling review, and a tested cutover plan.
Why load balancing needs careful design
Load balancing configuration errors can route users to degraded origins, break session-dependent flows, or cause failover loops. Nanosek designs health checks, pool thresholds, and traffic steering policies with testing gates before production traffic is moved.
Our Cloudflare Load Balancing approach
Architecture and traffic discovery
- Inventory current origin infrastructure, load balancing configuration, traffic patterns, geographic distribution, session requirements, and health check design.
- Identify critical application paths, peak traffic windows, session affinity requirements, failover expectations, and any compliance or geographic routing constraints.
Pool and routing design
- Design origin pool structure, pool membership rules, failover pool hierarchy, and traffic steering mode for each application or hostname.
- Select between round-robin, weighted, geo, latency, and random steering based on application requirements and infrastructure topology.
Health check and failover design
- Design health check type, interval, threshold, path, expected status, follow redirects, and notification configuration for each origin pool.
- Define the pool degraded and critical thresholds that trigger failover, and design the fallback pool chain for each hostname.
Implementation and integration
- Configure origin pools, origins, health checks, load balancing records, steering policies, session affinity, and fallback pool chains in Cloudflare.
- Integrate with WAF, Bot Management, Cache Rules, and Workers where origin selection should interact with security or caching decisions.
Validation and failover testing
- Test health check behavior, failover trigger timing, origin recovery behavior, session affinity persistence, and geo steering routing across test origins.
- Validate traffic distribution under synthetic load, confirm Logpush and dashboard visibility, and prepare cutover runbooks.
Production cutover
- Move production DNS to use Cloudflare Load Balancing records using a tested cutover plan with reduced TTLs, validation steps, and rollback preparation.
- Monitor pool health, failover events, traffic distribution, origin response times, and error rates during and after cutover.
Optimization and managed operations
- Tune health check thresholds, pool weights, steering policies, and alerting after production data is available.
- Provide ongoing managed Cloudflare operations including pool health monitoring, failover event review, configuration updates, and capacity planning support.
Architecture
Cloudflare Load Balancing controls we use
Origin pools
Define groups of origin servers with shared health-check and traffic-steering settings for each application or hostname.
Origins
Individual backend servers or addresses within a pool, with weight, enabled/disabled state, and header configuration.
Load Balancing records
DNS records that point a hostname to a load balancer, enabling Cloudflare to steer traffic rather than returning a static IP.
Health checks
Periodic requests to origins that determine pool health status and trigger failover when origins fall below threshold.
Round-robin steering
Distribute requests across all healthy origins in a pool in sequence, without weighting or location awareness.
Weighted steering
Assign relative traffic weight to each origin or pool for proportional distribution, canary deployments, or migration traffic shifting.
Geo steering
Route traffic to a specific origin pool based on the geographic region of the incoming request.
Latency steering
Route each request to the origin pool with the lowest measured latency at request time using real-time probe data.
Random steering
Distribute requests randomly weighted by origin capacity, useful for simpler setups without latency or geo requirements.
Fallback pools
Define a backup pool that receives traffic when all primary pools are degraded or unavailable.
Pool degraded threshold
Set the percentage of healthy origins below which a pool is considered degraded and traffic moves to the next pool in the chain.
Pool critical threshold
Set the percentage of healthy origins below which a pool is considered critical and all traffic is immediately moved to fallback.
Session affinity
Keep returning users on the same origin pool for the duration of a session to preserve state in stateful applications.
Session affinity TTL
Control how long session affinity cookies persist before the user is re-steered based on current pool health and steering policy.
Steering overrides
Override the default steering policy for specific regions or conditions to handle special routing requirements.
Origin headers
Configure per-origin Host headers and SNI to ensure correct backend routing when origins expect specific header values.
Origin probing intervals
Set how frequently health checks run per origin, balancing detection speed against origin load from health check traffic.
Health check notifications
Alert operations teams when pool health changes, origins fail, or failover events are triggered.
Cloudflare DNS integration
Load Balancing records replace standard DNS records, enabling Cloudflare to steer traffic at the DNS layer with near-real-time failover.
Logpush for Load Balancing
Export load balancing events, health check results, pool changes, and traffic distribution data to SIEM or analytics platforms.
GraphQL Analytics
Review traffic distribution, pool health, failover events, origin response times, and steering behavior through the Cloudflare dashboard.
Workers integration
Use Workers for advanced traffic routing logic that requires request-level context, custom origin selection, or dynamic backend decision making.
Terraform / API automation
Manage load balancer configuration, pool definitions, health checks, and steering policy through Terraform or the Cloudflare API for repeatable deployment.
Spectrum (TCP/UDP) load balancing
Used for non-HTTP workloads requiring TCP or UDP load balancing with Cloudflare network-layer traffic distribution where applicable.
| Control | When Nanosek uses it |
|---|---|
| Origin pools | Define groups of origin servers with shared health-check and traffic-steering settings for each application or hostname. |
| Origins | Individual backend servers or addresses within a pool, with weight, enabled/disabled state, and header configuration. |
| Load Balancing records | DNS records that point a hostname to a load balancer, enabling Cloudflare to steer traffic rather than returning a static IP. |
| Health checks | Periodic requests to origins that determine pool health status and trigger failover when origins fall below threshold. |
| Round-robin steering | Distribute requests across all healthy origins in a pool in sequence, without weighting or location awareness. |
| Weighted steering | Assign relative traffic weight to each origin or pool for proportional distribution, canary deployments, or migration traffic shifting. |
| Geo steering | Route traffic to a specific origin pool based on the geographic region of the incoming request. |
| Latency steering | Route each request to the origin pool with the lowest measured latency at request time using real-time probe data. |
| Random steering | Distribute requests randomly weighted by origin capacity, useful for simpler setups without latency or geo requirements. |
| Fallback pools | Define a backup pool that receives traffic when all primary pools are degraded or unavailable. |
| Pool degraded threshold | Set the percentage of healthy origins below which a pool is considered degraded and traffic moves to the next pool in the chain. |
| Pool critical threshold | Set the percentage of healthy origins below which a pool is considered critical and all traffic is immediately moved to fallback. |
| Session affinity | Keep returning users on the same origin pool for the duration of a session to preserve state in stateful applications. |
| Session affinity TTL | Control how long session affinity cookies persist before the user is re-steered based on current pool health and steering policy. |
| Steering overrides | Override the default steering policy for specific regions or conditions to handle special routing requirements. |
| Origin headers | Configure per-origin Host headers and SNI to ensure correct backend routing when origins expect specific header values. |
| Origin probing intervals | Set how frequently health checks run per origin, balancing detection speed against origin load from health check traffic. |
| Health check notifications | Alert operations teams when pool health changes, origins fail, or failover events are triggered. |
| Cloudflare DNS integration | Load Balancing records replace standard DNS records, enabling Cloudflare to steer traffic at the DNS layer with near-real-time failover. |
| Logpush for Load Balancing | Export load balancing events, health check results, pool changes, and traffic distribution data to SIEM or analytics platforms. |
| GraphQL Analytics | Review traffic distribution, pool health, failover events, origin response times, and steering behavior through the Cloudflare dashboard. |
| Workers integration | Use Workers for advanced traffic routing logic that requires request-level context, custom origin selection, or dynamic backend decision making. |
| Terraform / API automation | Manage load balancer configuration, pool definitions, health checks, and steering policy through Terraform or the Cloudflare API for repeatable deployment. |
| Spectrum (TCP/UDP) load balancing | Used for non-HTTP workloads requiring TCP or UDP load balancing with Cloudflare network-layer traffic distribution where applicable. |
Traffic steering patterns
Active-passive failover
Single-region application with a standby backup
Primary pool with all active origins; fallback pool on standby. Health check triggers automatic failover when primary crosses degraded threshold.
Active-active multi-region
Traffic distributed across two or more regions under normal conditions
Geo or latency steering across regional pools. Each region receives its local traffic; failover routes to alternate region.
Weighted traffic distribution
Gradual traffic shift during migration or canary release
Origin or pool weights set to divide traffic proportionally. Weights adjusted incrementally with validation gates.
Geo routing by continent or country
Data residency, latency optimization, or CDN origin placement
Region-specific pools mapped to geographic zones. Fallback pool handles traffic from regions without a dedicated assignment.
Latency-based steering
Global application where closest origin varies by user location
Dynamic steering uses real-time probe latency to select the fastest pool at request time rather than a static geo assignment.
Session-affinity stateful application
Application with server-side session state that cannot tolerate mid-session re-routing
Session affinity configured with appropriate TTL. Pool health events handled with graceful drain and fallback routing.
Multi-cloud traffic distribution
Workloads running across AWS, Azure, GCP, and on-premises
Each cloud provider represented as a pool or as origins within a pool. Weights or steering policies manage cross-cloud distribution.
Blue-green deployment traffic switching
Zero-downtime application version switch
Blue and green pools defined. Weight shifted from blue to green incrementally or in a single switch with rollback pool ready.
API gateway origin routing
API platform with multiple backend services behind a single hostname
Workers-based routing or separate load balancer records per API path. Each pool targets the appropriate backend service.
DDoS and incident traffic redirect
Routing traffic away from an attacked or degraded origin
Manual or health-check-triggered pool disabling routes traffic to clean origins. Nanosek prepares runbooks for incident-time execution.
| Pattern | Use case | Design notes |
|---|---|---|
| Active-passive failover | Single-region application with a standby backup | Primary pool with all active origins; fallback pool on standby. Health check triggers automatic failover when primary crosses degraded threshold. |
| Active-active multi-region | Traffic distributed across two or more regions under normal conditions | Geo or latency steering across regional pools. Each region receives its local traffic; failover routes to alternate region. |
| Weighted traffic distribution | Gradual traffic shift during migration or canary release | Origin or pool weights set to divide traffic proportionally. Weights adjusted incrementally with validation gates. |
| Geo routing by continent or country | Data residency, latency optimization, or CDN origin placement | Region-specific pools mapped to geographic zones. Fallback pool handles traffic from regions without a dedicated assignment. |
| Latency-based steering | Global application where closest origin varies by user location | Dynamic steering uses real-time probe latency to select the fastest pool at request time rather than a static geo assignment. |
| Session-affinity stateful application | Application with server-side session state that cannot tolerate mid-session re-routing | Session affinity configured with appropriate TTL. Pool health events handled with graceful drain and fallback routing. |
| Multi-cloud traffic distribution | Workloads running across AWS, Azure, GCP, and on-premises | Each cloud provider represented as a pool or as origins within a pool. Weights or steering policies manage cross-cloud distribution. |
| Blue-green deployment traffic switching | Zero-downtime application version switch | Blue and green pools defined. Weight shifted from blue to green incrementally or in a single switch with rollback pool ready. |
| API gateway origin routing | API platform with multiple backend services behind a single hostname | Workers-based routing or separate load balancer records per API path. Each pool targets the appropriate backend service. |
| DDoS and incident traffic redirect | Routing traffic away from an attacked or degraded origin | Manual or health-check-triggered pool disabling routes traffic to clean origins. Nanosek prepares runbooks for incident-time execution. |
Deployment steps
- 01 Inventory current origin infrastructure, traffic patterns, geographic distribution, session requirements, health check design, and any migration from existing load balancers.
- 02 Design origin pool structure, pool hierarchy, failover pool chain, and traffic steering mode for each hostname and application.
- 03 Design health check configuration including check type, interval, threshold, path, expected response, and failure detection timing.
- 04 Configure origin pools, origins, load balancing records, steering policies, session affinity, and fallback pool chains in Cloudflare.
- 05 Test health check behavior, failover trigger, origin recovery, session affinity persistence, and geo or latency steering routing.
- 06 Execute DNS cutover with a tested plan, reduced TTLs, validation steps, and rollback preparation.
- 07 Tune health check thresholds, pool weights, and steering policies based on production data and operate with dashboards, alerting, and managed operations workflows.
Risks and mitigations
Health check false positives causing unnecessary failover.
Design health checks with appropriate interval, timeout, and consecutive failure threshold. Test against realistic origin response times before production.
Session affinity breaking during pool failover.
Design session affinity TTL to match application session lifetime. Test session handling during planned failover events before production.
Origin not allowlisting Cloudflare probe IPs.
Update origin firewall and security group rules to allow inbound health check traffic from Cloudflare IP ranges before enabling health checks.
Pool threshold misconfiguration routing traffic to degraded origins.
Set degraded and critical thresholds based on realistic failure scenarios and test threshold trigger and recovery behavior before cutover.
DNS TTL causing slow failover during cutover.
Reduce DNS TTL to 60 seconds or less at least 24 hours before cutover. Revert TTL to standard values after load balancing is confirmed stable.
Geo routing sending traffic to wrong region under compliance requirements.
Review geo steering region assignments against data residency and compliance requirements. Test routing from representative regions before production.
Weighted steering overloading a smaller origin during migration.
Set initial weights conservatively and increase incrementally. Monitor origin response times and error rates during each weight adjustment.
Failover pool undersized for full traffic volume.
Confirm fallback pool capacity is sufficient to absorb the full expected traffic load from the primary pool. Test at estimated production volume.
Load balancer configuration drift from Terraform or change management.
Manage all load balancing configuration through Terraform or the Cloudflare API with change approval workflow and configuration drift detection.
Workers-based routing logic introducing latency.
Profile Worker execution time under production-like request rates. Use native load balancing controls where they meet routing requirements without Worker overhead.
| Risk | Mitigation |
|---|---|
| Health check false positives causing unnecessary failover. | Design health checks with appropriate interval, timeout, and consecutive failure threshold. Test against realistic origin response times before production. |
| Session affinity breaking during pool failover. | Design session affinity TTL to match application session lifetime. Test session handling during planned failover events before production. |
| Origin not allowlisting Cloudflare probe IPs. | Update origin firewall and security group rules to allow inbound health check traffic from Cloudflare IP ranges before enabling health checks. |
| Pool threshold misconfiguration routing traffic to degraded origins. | Set degraded and critical thresholds based on realistic failure scenarios and test threshold trigger and recovery behavior before cutover. |
| DNS TTL causing slow failover during cutover. | Reduce DNS TTL to 60 seconds or less at least 24 hours before cutover. Revert TTL to standard values after load balancing is confirmed stable. |
| Geo routing sending traffic to wrong region under compliance requirements. | Review geo steering region assignments against data residency and compliance requirements. Test routing from representative regions before production. |
| Weighted steering overloading a smaller origin during migration. | Set initial weights conservatively and increase incrementally. Monitor origin response times and error rates during each weight adjustment. |
| Failover pool undersized for full traffic volume. | Confirm fallback pool capacity is sufficient to absorb the full expected traffic load from the primary pool. Test at estimated production volume. |
| Load balancer configuration drift from Terraform or change management. | Manage all load balancing configuration through Terraform or the Cloudflare API with change approval workflow and configuration drift detection. |
| Workers-based routing logic introducing latency. | Profile Worker execution time under production-like request rates. Use native load balancing controls where they meet routing requirements without Worker overhead. |
Load balancing validation checklist
- All origin servers and addresses documented
- Origin capacity and maximum connection limits understood
- Health check paths and expected responses confirmed
- Health check intervals and thresholds tested
- Pool degraded and critical thresholds configured
- Fallback pool chain defined for all hostnames
- Traffic steering mode selected and validated
- Geo steering region assignments reviewed
- Session affinity requirements confirmed
- Session affinity TTL set appropriately
- Origin Host headers and SNI confirmed
- Origin allowlisting updated for Cloudflare probe IPs
- Failover behavior tested by disabling individual origins
- Failover recovery behavior tested by re-enabling origins
- Full pool failure and fallback routing validated
- DNS cutover plan prepared with TTL reduction steps
- Rollback plan prepared for DNS cutover reversal
- Logpush or analytics visibility confirmed for pool events
- Health check notification alerting configured
- WAF and Bot Management behavior validated with new load balancer routing
- Session affinity persistence validated across pool failover
Deliverables
- Origin infrastructure and traffic pattern inventory
- Load balancing architecture design
- Origin pool and failover pool structure
- Health check design per pool
- Traffic steering policy selection and configuration
- Session affinity design
- Cloudflare Load Balancing implementation
- Failover and recovery test report
- DNS cutover plan and rollback steps
- Dashboard and alerting configuration
- Load balancing runbooks for operations teams
- Terraform or API automation for configuration management
- Managed operations handover and ongoing optimization backlog
When Nanosek should help
Frequently asked questions
What is Cloudflare Load Balancing?
How fast does Cloudflare Load Balancing detect and respond to origin failure?
Can Cloudflare Load Balancing route traffic across AWS, Azure, and on-premises simultaneously?
Does Cloudflare Load Balancing support session affinity?
Can we use Cloudflare Load Balancing for a canary or blue-green deployment?
What happens when all origins in a pool are unhealthy?
Do origins need to be updated to allow Cloudflare health check traffic?
Can Cloudflare Load Balancing work with Workers for advanced routing?
Can Nanosek manage Cloudflare Load Balancing after deployment?
Route production traffic with confidence
Nanosek designs and deploys Cloudflare Load Balancing with the architecture, health check design, failover validation, and managed operations your applications need for reliable traffic distribution.