Cloudflare One Workers: Unificando Edge Computing, Zero Trust e Desempenho Global
Em um sábado de julho de 2026, enquanto o mundo digere os números impressionantes de tráfego da Copa do Mundo e equipes de infraestrutura preparam janelas de manutenção em Newark e Ashburn, um movimento silencioso mas avassalador consolida a Cloudflare Cloudflare One Workers como o núcleo de uma plataforma que há dois anos era vista apenas como um CDN com alguns extras. Hoje, a Cloudflare movimenta uma em cada cinco requisições HTTP do planeta, opera mais de 300 pontos de presença em mais de 100 países e empurra a lógica de aplicações para a borda com latências de inicialização a frio inferiores a um milissegundo — um feito de engenharia que altera a geometria da computação em nuvem como a conhecíamos.
O anúncio recente das Cache Response Rules — um mecanismo que permite reescrever cabeçalhos de cache no momento exato em que a resposta sai da borda — ilustra bem essa transformação. Já não se trata apenas de servir conteúdo estático rapidamente. Trata-se de manipular o comportamento HTTP em camadas profundas, com granularidade por rota, por código de status e por cookie, sem tocar na origem. Esse é o tipo de capacidade que empresas brasileiras que operam marketplaces, fintechs e plataformas de streaming estavam acostumadas a buscar em appliances caros ou em configurações frágeis de Varnish. Agora, está disponível no mesmo plano de controle onde rodam Cloudflare One Workers, os túneis WARP, as políticas de Zero Trust e a proteção contra DDoS que em 2024 mitigou sozinha um ataque de mais de 2 Tbps.
Para profissionais de TI e entusiastas de tecnologia que precisam decidir onde executar a próxima aplicação — se em funções serverless tradicionais, em containers efêmeros ou na borda — este é o momento de entender a profundidade da plataforma Cloudflare One e como os Workers se tornaram o componente central de um ecossistema que abrange CDN, segurança, SASE e inteligência artificial. Vamos percorrer os anúncios mais recentes, dissecar a arquitetura de borda da Cloudflare, comparar custos e latências com AWS e GCP, e traduzir tudo isso para a realidade de latência e regulação que afeta as empresas que operam no Brasil.
Além da análise técnica, você encontrará cenários práticos de arquitetura, recomendações sobre quando usar Workers versus Lambda@Edge versus Vercel Edge Functions, e a perspectiva de quem implementa essa plataforma em ambientes corporativos de missão crítica — incluindo a experiência da JRT Technology Solutions configurando CDN, WAF e Zero Trust para empresas que não podem se dar ao luxo de errar na escolha da infraestrutura. Ao final, você terá uma visão de 360 graus sobre por que a Cloudflare está redefinindo o que significa “serverless na borda” e como extrair o máximo dessa plataforma ainda em 2026.
Cache Response Rules, BGP e a Copa: os sinais de uma plataforma que não para de evoluir
Nas últimas semanas, a Cloudflare publicou uma série de lançamentos e pesquisas que, vistos isoladamente, parecem retalhos de um roadmap extenso. Mas quando os conectamos, formam a silhueta de uma plataforma cada vez mais autônoma. O estudo sobre manipulação do atributo BGP ORIGIN, por exemplo, revelou que quase 70% dos caminhos BGP sofrem reescrita por provedores de trânsito em busca de vantagens de tráfego — uma descoberta que ecoa diretamente na confiança que depositamos em rotas da internet e que a Cloudflare combate com seu backbone privado e o roteamento inteligente do Argo. Essa mesma pesquisa sustenta o argumento técnico para abolir o atributo ORIGIN da seleção de rotas, algo que afeta qualquer empresa com presença multirregional, inclusive no Brasil, onde rotas para Miami e Lisboa competem diariamente.
Já o impacto da Copa do Mundo de 2026 sobre o tráfego HTTP global trouxe dados fascinantes sobre como horários de jogos, streaming e até pausas para hidratação reorganizaram os padrões de acesso. Para uma CDN, isso não é curiosidade: é combustível para calibrar caching preditivo, alocação de capacidade e políticas de Waiting Room. As Cache Response Rules, anunciadas em paralelo, são a ferramenta que permite corrigir decisões de cache que a origem não controla — como um Set-Cookie indesejado que expulsa objetos do cache ou um Cache-Control mal configurado. Na prática, você pode criar uma regra que, ao detectar determinado path e status 200, sobrescreva o cabeçalho para Cache-Control: public, max-age=86400 e remova cookies antes de entregar ao cliente. Isso é executado na borda, sem round-trip à origem, e se integra com a lógica de Cloudflare One Workers quando você precisa de transformações ainda mais complexas.
Outro bloco importante é o Cloudflare Internal DNS, agora geralmente disponível. Ele traz DNS autoritativo e recursivo para redes privadas para a mesma infraestrutura que roda o DNS público da Cloudflare e o Gateway do Cloudflare One. Isso significa que políticas de filtragem DNS que bloqueiam phishing antes da resolução — como as que a Area 1 Email Security aplica ao e-mail corporativo — agora podem alcançar também recursos internos, fechando uma lacuna que forçava muitas empresas a manterem duas camadas de DNS desconexas. A convergência de DNS público, DNS interno e filtering no mesmo plano de controle é exatamente o tipo de integração que torna o Cloudflare Cloudflare One Workers tão relevante: você pode escrever um Worker que consulta o DNS interno, aplica políticas de acesso baseadas em identidade e retorna uma resposta HTTP customizada, tudo na borda e sem mover tráfego para dentro da rede privada.
A anatomia do Cloudflare Cloudflare One Workers na plataforma unificada
Para compreender o que significa Cloudflare Cloudflare One Workers, é preciso desmontar as camadas. Cloudflare One é o guarda-chuva SASE e Zero Trust — inclui Access (substituto de VPN), Gateway (DNS/HTTP filtering), WARP (cliente Zero Trust), CASB (visibilidade de SaaS), Browser Isolation (sandbox de navegação) e Network Interconnect (conexão privada via MPLS/BGP). Workers, por sua vez, é a camada de computação na borda que executa JavaScript, WebAssembly e agora Python em cada um dos mais de 275 pontos de presença. Quando você junta os dois, obtém a capacidade de executar lógica de negócio na borda ao mesmo tempo em que impõe autenticação, inspeciona tráfego, aplica políticas de segurança e roteia dinamicamente — tudo no mesmo request flow, sem proxies adicionais.
O coração técnico dessa integração está na ordem de execução dos handlers. Em um site configurado com Cloudflare, a requisição passa primeiro pelo DDoS Protection (L3/4/7), depois pelo WAF (regras gerenciadas OWASP, custom rules, rate limiting), em seguida pelo Bot Management (ML e fingerprinting), e só então encontra o Worker associado à rota. O Worker pode, nesse ponto, decidir responder diretamente do KV (key-value store), consultar o D1 (banco SQLite na borda), acionar um Durable Object para manter estado via WebSocket, ou encaminhar a requisição para a origem — potencialmente via Argo Smart Routing, que usa o backbone privado da Cloudflare para reduzir a latência em 30–40%. Essa sequência não é apenas performática; é uma cadeia de segurança completa que elimina a necessidade de configurar WAFs separados, balanceadores de carga e gateways de API.
Para provedores de conteúdo e plataformas SaaS brasileiras, a implicação é clara: uma única configuração no dashboard da Cloudflare substitui o que antes exigia CloudFront + WAF + API Gateway + Route 53 + Global Accelerator na AWS, ou uma combinação semelhante no GCP. A diferença de complexidade operacional é brutal. E como os Workers suportam agora o AI SDK v7 e empacotamentos como @cloudflare/think e @cloudflare/codemode — com exposição controlada de ferramentas MCP e execução de código durável fora do ciclo AI — os cenários de agentes autônomos e pipelines de IA rodando inteiramente na borda passam a ser viáveis sem sair da rede da Cloudflare.
Edge computing sem cold starts: o runtime que mudou o jogo
O conceito de “serverless na borda” é frequentemente mal compreendido. Em arquiteturas tradicionais como AWS Lambda, o código reside em um ambiente que precisa ser provisionado — container, runtime, dependências — cada vez que uma função é invocada após um período de inatividade. Esse cold start pode levar de centenas de milissegundos a vários segundos, inviabilizando aplicações sensíveis à latência. A abordagem da Cloudflare é radicalmente diferente: cada Worker é compilado para um formato intermediário (baseado em V8 isolates) e distribuído proativamente para todos os PoPs da rede. O isolate é criado em menos de um milissegundo, e não há container para subir. O resultado é um cold start praticamente imperceptível, mesmo em tráfego esporádico.
Essa característica técnica tem implicações profundas para aplicações que dependem de consistência de latência: APIs de autenticação, personalização de conteúdo em tempo real, e manipulação de cabeçalhos de segurança são exemplos clássicos. Com Cloudflare Cloudflare One Workers, você pode adicionar validação de token JWT, consulta a um banco D1 para verificar permissões, e injeção de headers CSP e Permissions-Policy com latência adicional inferior a 5 ms no percentil 95, mesmo para usuários na América do Sul. Para uma fintech que processa milhares de requisições por segundo durante o Pix ou o Open Finance, essa previsibilidade é um diferencial competitivo — e um argumento de SLA que os hiperescalares tradicionais têm dificuldade em igualar sem custos proibitivos.
A tabela a seguir sintetiza as diferenças arquiteturais fundamentais entre Workers, funções serverless tradicionais e containers na borda:
Para completar a radiografia, vale listar os serviços de armazenamento e estado que orbitam os Workers:
- KV: key-value store de consistência eventual, replicado globalmente. Ideal para feature flags, configurações e dados de sessão que toleram alguns segundos de propagação.
- D1: banco SQLite distribuído, com queries em menos de 1 ms. Suporta transações e índices, perfeito para catálogos de produtos, perfis de usuário e metadados estruturados.
- R2: object storage compatível com API S3, mas sem taxas de egress. Isso muda radicalmente a matemática de custos para quem serve muitos arquivos (imagens, vídeos, pacotes estáticos).
- Durable Objects: atores com estado forte, garantia de consistência e suporte a WebSockets. Usados para salas colaborativas, controle de inventário em tempo real e sincronização de estado entre clientes.
- Queues: message queue gerenciado, compatível com SQS, com entrega garantida e retry automático. Permite desacoplar Workers sem recorrer a filas externas.
- Workers AI: inferência de modelos como Llama, Mistral, Whisper e Stable Diffusion diretamente na borda, sem necessidade de aquecer GPUs.
- AI Gateway: proxy com observabilidade para APIs de IA externas (OpenAI, Anthropic, HuggingFace), armazenando métricas e controlando custos.
- Vectorize: banco vetorial para busca semântica e RAG, operando sobre embeddings gerados na borda.
Cloudflare One Workers e a malha Zero Trust: por que isso redefine o acesso a aplicações
Um erro comum é tratar Cloudflare One Workers como um mero executor de funções que substitui APIs em container. A verdadeira potência surge quando os Workers são posicionados dentro da malha Zero Trust do Cloudflare One. Imagine um cenário real: uma empresa de saúde brasileira precisa expor um portal de resultados de exames para pacientes, médicos e operadoras de saúde. Cada perfil vê dados diferentes, e a LGPD exige controle granular e rastreabilidade de acesso. Usando Cloudflare Access, cada requisição chega à borda já autenticada via integração com o Azure AD ou Okta da empresa. Um Worker consulta o perfil do usuário no D1, monta os headers de autorização corretos e encaminha a requisição para o backend interno — que está conectado via Cloudflare Tunnel ou Network Interconnect, sem expor portas na internet pública. Toda a comunicação entre o Worker e o backend é protegida pelo túnel, e as políticas de Gateway bloqueiam exfiltração de dados acidental para domínios não autorizados.
Esse padrão — autenticar na borda com identidade federada, aplicar lógica de negócio com Worker e conectar ao backend privado sem VPN — reduz a superfície de ataque a praticamente zero. Não há IP público de origem, não há listener exposto, não há túnel IPSec que alguém esqueceu de rotacionar a chave. E como o Worker pode emitir logs estruturados para R2 ou Datadog, a rastreabilidade exigida pela LGPD (artigos 37 e 38) é cumprida com registros imutáveis de quem acessou qual recurso, quando e com qual propósito declarado.
A recente correção nos clientes Cloudflare One Client (versão 2026.6.880.0 para Windows, macOS e Linux) que resolveu um aumento massivo de queries DNS-over-TCP para servidores de fallback é outro exemplo de como a plataforma amadurece sem alarde. O bug fazia com que o cliente enviasse consultas DNS em TCP e UDP simultaneamente para servidores internos, gerando carga desnecessária e lentidão. Agora, o cliente consulta UDP primeiro e só escala para TCP se a resposta for truncada — exatamente como manda o RFC. Esse nível de polimento é o que diferencia uma plataforma que está sendo usada em escala planetária e que precisa atender desde o desenvolvedor individual no plano gratuito até bancos centrais e ministérios.
Comparativo de custo e performance: Workers versus AWS versus GCP
A análise de custo-benefício é frequentemente o fator decisivo na escolha da plataforma de borda. A tabela abaixo projeta um cenário típico — uma API com 50 milhões de requisições por mês, cada uma com 20 ms de tempo de CPU — e compara o custo mensal estimado entre Cloudflare Workers, AWS Lambda (com CloudFront e API Gateway) e Google Cloud Functions (com Cloud CDN).
