Load Balancer na prática: AWS + Cloudflare (e como essa integração funciona)

Quando você coloca uma aplicação em produção, quase sempre existe uma pergunta por trás de tudo: como eu recebo tráfego do mundo, protejo, distribuo e mantenho isso estável?

É aí que entram dois “blocos” que aparecem em praticamente qualquer arquitetura moderna:

• Cloudflare na borda (DNS, CDN, WAF, DDoS, cache, otimizações)
• Load Balancer no provedor (AWS) para distribuir conexões e isolar seus serviços internos

Neste artigo, vamos entender o que o Load Balancer faz, onde o Cloudflare se encaixa e os padrões mais usados para integrar Cloudflare + AWS.

---

O que um Load Balancer faz de verdade?

Um Load Balancer (LB) é um componente que recebe conexões e decide para onde encaminhar dentro do seu ambiente, baseado em regras.

Ele normalmente entrega:

• Distribuição de carga entre múltiplas instâncias (EC2), containers (ECS) ou pods (EKS)
• Alta disponibilidade: se uma instância/pod cai, ele para de mandar tráfego pra ela
• Health checks para só mandar tráfego para alvos saudáveis
• TLS termination (em muitos casos): o LB encerra HTTPS e conversa HTTP interno
• Roteamento L7 (HTTP) ou L4 (TCP/UDP) dependendo do tipo

AWS: ALB vs NLB (o resumo útil)

• ALB (Application Load Balancer): camada 7 (HTTP/HTTPS), roteamento por host/path, ótimo para APIs e múltiplos serviços.
• NLB (Network Load Balancer): camada 4 (TCP/UDP), altíssima performance, útil para tráfego não-HTTP (gRPC puro, MQTT, etc.) ou exigência de IP fixo.

---

Onde o Cloudflare entra?

A forma mais comum é:

1. Cliente resolve o domínio no DNS do Cloudflare
2. O tráfego passa pela rede Cloudflare (CDN/WAF/Proteções)
3. Cloudflare encaminha para o origin (seu endpoint público na AWS: ALB/NLB/API Gateway)
4. A AWS distribui para ECS/EKS/EC2 e seus serviços internos

Isso te dá:

• Proteção e performance na borda
• Um único ponto de entrada (domínio) com controle de segurança
• Roteamento resiliente dentro da AWS

---

Modos de integração Cloudflare → AWS

1) Cloudflare como proxy (o padrão)

O seu domínio fica com o ícone “laranja” (proxy ligado):

• Cloudflare termina TLS com o usuário
• e conecta no origin com um modo de TLS (Flexible / Full / Full strict)

Recomendação prática:

• Use Full (strict) com certificado válido no origin (ALB com ACM ou cert no Ingress)

2) Cloudflare DNS only

Cloudflare só responde o DNS.

• Tráfego vai direto pro ALB/NLB
• Você perde WAF/Cache/DDoS da Cloudflare (mas pode usar AWS WAF/Shield)

3) Cloudflare Tunnel (zero exposição)

Para cenários onde você não quer expor IP público / LB público:

• Conector interno abre um túnel até Cloudflare
• Cloudflare entrega pro seu serviço interno

(Ótimo para painéis, admin, ferramentas internas, etc.)

---

TLS / Certificados: o “pulo do gato”

Opção A (comum): HTTPS até o ALB

• Cloudflare (edge) → HTTPS → ALB (ACM)
• ALB → HTTP/HTTPS interno

Opção B: Cloudflare Origin Certificate

• Cloudflare gera um Origin Cert (confiável por Cloudflare, não por browsers)
• Você instala no origin (ALB/Ingress)
• Cloudflare conecta em Full (strict) e você fica redondo e barato

Opção C: mTLS (mais avançado)

• Cloudflare apresenta certificado de cliente no origin
• Origin valida e só aceita tráfego vindo da Cloudflare

---

Caching e headers (o que muda)

Cloudflare pode:

• Cachear conteúdo estático e até rotas dinâmicas dependendo de regras
• Respeitar/alterar Cache-Control
• Adicionar headers como CF-Connecting-IP, CF-Ray, CF-IPCountry

No origin, você normalmente:

• Usa X-Forwarded-For / X-Forwarded-Proto (ou equivalentes)
• Garante que sua app entenda o IP real do cliente (atrás do proxy)

---

Observabilidade: como você enxerga problemas

• Cloudflare Analytics: tráfego, WAF, bloqueios, cache hit/miss
• AWS CloudWatch / ALB Logs (S3): latência, status codes, health checks
• APM (Datadog/NewRelic/OpenTelemetry): tracing ponta-a-ponta

Um erro 520/522 no Cloudflare geralmente significa:

• origin indisponível / timeout / handshake TLS falhando
• health checks ruins
• rate limiting / firewall no origin bloqueando Cloudflare

---

Diagrama: Fluxo Cloudflare + AWS

---

Checklist rápido (produção) pra essa integração

Cloudflare

• Proxy ligado (laranja) para ganhar WAF/CDN/DDoS
• SSL/TLS: Full (strict)
• Regras de cache (pelo menos para estático)
• Rate limiting e WAF rules para endpoints sensíveis (/login, /api)

AWS

• ALB com target group e health checks confiáveis
• Logs do ALB para S3 (opcional, mas excelente)
• CloudWatch metrics/alarms (5xx, latency, unhealthy hosts)
• Security Group do ALB permitindo apenas o necessário

App

• Respeitar X-Forwarded-For / X-Forwarded-Proto
• Correlation ID (ex.: X-Request-Id) pra troubleshooting
• Timeouts bem definidos (Cloudflare e ALB têm limites)

---

Conclusão

A integração Cloudflare + AWS é um padrão porque separa bem responsabilidades:

• Cloudflare cuida da borda (segurança, performance, cache, DNS)
• AWS Load Balancer cuida de distribuir e manter o tráfego saudável dentro do seu ambiente

Se você quiser, eu adapto o diagrama acima para:

• EKS + Ingress (Nginx) + cert-manager + ExternalDNS
• multi-serviços (path-based) no ALB
• ou NLB + TCP (casos de WebSocket/gRPC/UDP)