Times que chegam ao Cloudflare Load Balancing vindos de um AWS ALB costumam configurar tudo corretamente e então se deparar com comportamentos que o modelo mental deles não explica: um cliente continua chegando na mesma origem por minutos depois que ela falhou, a distribuição de carga parece desigual entre instâncias, e o failover demora mais do que os health checks sugerem. O produto funciona, mas funciona de um jeito diferente do esperado — porque ele opera no DNS, não na camada de transporte ou de aplicação.
Como o Cloudflare Load Balancing realmente funciona
O Cloudflare Load Balancing é um serviço de distribuição de tráfego que age no momento da resolução de nome. Quando um cliente faz uma consulta DNS para o domínio balanceado, o autoritativo do Cloudflare avalia quais origens estão saudáveis, aplica a regra de steering configurada, e retorna o IP da origem selecionada. A partir desse ponto, o cliente se conecta diretamente à origem — ou ao PoP Cloudflare, se o registro estiver proxiado — e todas as requisições daquela sessão vão para aquele destino até que o TTL expire e o cliente precise resolver o nome novamente.
Isso significa que a distribuição de carga acontece por resolução DNS, não por requisição HTTP. Dois clientes simultâneos que resolvem o domínio no mesmo segundo podem receber origens diferentes. Um único cliente que resolve o nome uma vez e mantém a conexão aberta fica na mesma origem indefinidamente. Se há dez instâncias rodando atrás de um ALB, o ALB distribui as requisições entre elas a cada novo request. Com o Cloudflare LB, a granularidade é o cliente, não a requisição.
O sistema de health checks corrige o caminho quando uma origem falha. O Cloudflare executa health checks ativos a partir de múltiplos PoPs — não de um único ponto — contra cada origem cadastrada. Quando o percentual de falhas ultrapassa o threshold configurado, a origem é marcada como degradada e removida do pool de resolução. Novos clientes que resolverem o nome depois dessa marcação não recebem mais o IP da origem problemática. Clientes que já resolveram o nome e têm o IP em cache continuam tentando se conectar até o TTL expirar. O failover, portanto, tem dois componentes de latência: o tempo para o health check detectar e marcar a falha, e o TTL restante dos clientes que já fizeram a resolução.
O modelo de preços e o que ele cobre
O plano base do Cloudflare Load Balancing custa $5 por mês e inclui dois origin pools, cinco origens por pool, e health checks configuráveis. A cobrança adicional de $0,50 por 500 mil queries de health check se aplica ao volume gerado pelos checks — com intervalos de 60 segundos e distribuição entre múltiplos PoPs, o volume mensal sobe rapidamente, mas ainda fica em uma faixa razoável para setups ativos-passivos com pools pequenos.
Para um setup ativo-passivo simples — um pool principal com duas origens e um pool de fallback — a conta mensal fica abaixo de $10 na maioria dos cenários. Para arquiteturas mais elaboradas com múltiplos pools regionais e health checks granulares por PoP, o custo cresce, mas continua competitivo quando comparado com o overhead operacional de gerenciar failover manual entre regiões.
Geo Steering: roteamento por origem geográfica do cliente
O Geo Steering é a funcionalidade que transforma o Load Balancer em uma camada de roteamento geográfico real. A configuração associa regiões — continentes ou países específicos — a pools de origem. Clientes brasileiros resolvem o domínio e recebem o IP da origem em São Paulo. Clientes europeus recebem o IP da origem em Frankfurt. O autoritativo do Cloudflare identifica a localização geográfica do resolver que fez a consulta e retorna a resposta do pool correspondente.
Quando o pool regional fica indisponível — todas as origens nele marcadas como degradadas — o Cloudflare cai automaticamente para o pool de fallback global configurado. O cliente europeu cujo pool de Frankfurt está fora recebe o IP da São Paulo ou de qualquer outro pool que esteja saudável, sem intervenção manual. Esse mecanismo de fallback automático é o que torna o Geo Steering útil para alta disponibilidade geográfica, não apenas para otimização de latência.
Session affinity por cookie complementa o roteamento geográfico para casos onde a mesma instância precisa atender o mesmo cliente ao longo de múltiplas resoluções DNS. O Cloudflare injeta um cookie na resposta HTTP que identifica a origem selecionada, e o Load Balancer usa esse cookie para devolver o cliente à mesma origem em resoluções subsequentes, mesmo que o TTL já tenha expirado. Para aplicações sem estado isso é irrelevante; para sessões que armazenam contexto na memória da instância, é o mecanismo que evita quebra de experiência durante re-resoluções normais de TTL.
A distinção que muda o desenho da arquitetura
Um ALB opera na camada 7. Ele recebe conexões TCP, inspeciona cabeçalhos HTTP, aplica regras de roteamento por path e por header, e distribui cada requisição individual para uma instância do pool de backend. Ele vê cada request. Pode fazer path-based routing — /api vai para um grupo de instâncias, /static vai para outro. Pode injetar ou modificar cabeçalhos. Tem visibilidade sobre o corpo da requisição se o protocolo permitir.
O Cloudflare LB não vê requisições individuais. Ele responde perguntas DNS. Não tem como inspecionar o path /api porque o path nem existe na camada DNS — ele só aparece depois que o cliente estabeleceu a conexão TCP com a origem e enviou o HTTP GET. Isso não é limitação acidental; é a consequência natural de operar no protocolo errado para esse nível de granularidade.
O padrão que combina os dois resolve problemas diferentes em cada camada. O Cloudflare LB cuida do roteamento geográfico e do failover entre regiões: clientes no Brasil chegam em São Paulo, clientes na Europa chegam em Frankfurt, e se São Paulo cai, o tráfego migra automaticamente. Dentro de cada região, um ALB ou um nginx distribui as requisições entre as instâncias do pool, faz path-based routing, e gerencia a carga no nível de request. Os dois coexistem sem conflito porque resolvem problemas em camadas diferentes da pilha.
O que os health checks significam para o SLA de failover
A velocidade do failover depende de três variáveis: o intervalo de health check, o número de falhas consecutivas necessárias para marcar uma origem como degradada, e o TTL do registro DNS. Com health checks a cada 60 segundos e dois failures consecutivos como threshold, o pior caso para detecção é 120 segundos. Somando o TTL — que para registros proxiados fica em 60 segundos — o janela máxima de failover fica em torno de 3 minutos.
Reduzir o intervalo de health check acelera a detecção, mas eleva o volume de queries cobradas. O ponto de equilíbrio depende do SLA de disponibilidade do serviço. Para sistemas onde 3 minutos de falha parcial é aceitável — a origem inoperante atende zero clientes novos após a detecção, mas clientes com cache ativo ainda tentam por até o TTL — o setup padrão é adequado. Para sistemas onde qualquer desvio de tráfego para uma origem degradada é inaceitável, a combinação de TTL baixo, health check com intervalo curto e pelo menos dois PoPs verificando em paralelo reduz a janela para menos de 2 minutos na prática.
O ponto que times com background em ALB subestimam é que o Cloudflare LB não interrompe conexões ativas quando uma origem é marcada como degradada. Ele para de retornar aquele IP em novas resoluções DNS. Clientes que já têm o IP em cache continuam tentando. O timeout de conexão TCP ou o erro de aplicação é o que o cliente vai sentir até o TTL expirar e uma nova resolução devolver um IP saudável. O impacto real depende de qual fração dos clientes ativos tem cache fresco versus cache expirado no momento da falha.
Leia também
- Cloudflare DNS: infraestrutura de rede que vai muito além de resolver nomes
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido
- DNSSEC com Cloudflare: o que protege, o que não protege e como ativar sem problemas
- Cloudflare Email Routing: receber email no seu domínio — e o que não vem junto
- KV vs R2 vs Cache API: quando usar cada camada de armazenamento do Cloudflare
- Cloudflare KV: o que globalmente distribuído significa quando você precisa escrever