Ataques DDoS estão maiores, mais frequentes e mais distribuídos do que nunca, enquanto aplicações modernas dependem cada vez mais de baixa latência para manter desempenho, conversão e experiência do usuário.
Nesse cenário, o desafio passou a ser bloquear ataques sem transformar a própria camada de segurança em uma fonte de degradação de performance.
Entre os componentes que mais geram preocupação para equipes de infraestrutura estão o WAF e os mecanismos de mitigação DDoS. Ambos são fundamentais para proteger aplicações, mas também frequentemente associados a impactos de performance.
Em arquiteturas tradicionais, a inspeção realizada por essas soluções pode exigir redirecionamentos de tráfego, processamento remoto, gargalos devido à concentração da análise em um ou poucos pontos, e múltiplas etapas de validação antes que a requisição chegue à aplicação. Quando isso acontece, a proteção continua funcionando, mas a experiência do usuário pode ser afetada.
Os mecanismos de proteção continuam funcionando corretamente, mas o tempo de resposta aumenta enquanto a origem da latência permanece difícil de identificar.
Quando WAF e Mitigação DDoS Impactam a Performance?
Durante muito tempo, a indústria tratou segurança e performance como objetivos conflitantes. Essa percepção surgiu porque grande parte das soluções de segurança foi construída para arquiteturas centralizadas.
Nesse modelo, o tráfego não é analisado necessariamente onde entra na rede. Antes de chegar à aplicação, ele pode ser redirecionado para centros específicos de inspeção responsáveis por aplicar regras de WAF, mitigação DDoS, gerenciamento de bots e outras camadas de proteção.
Na prática, isso significa que uma requisição nem sempre percorre o caminho mais curto entre usuário e aplicação.
Em muitos casos, o tráfego faz um desvio para ser inspecionado antes de seguir para seu destino final. Esse comportamento é conhecido como hairpinning.
Usuário → PoP mais próximo → Centro de processamento centralizado → Origem → UsuárioEmbora esse processo aconteça em milissegundos, ele adiciona uma etapa extra ao fluxo da requisição. E quanto maior a distância entre o ponto de entrada do tráfego e o local onde a inspeção acontece, maior tende a ser o impacto acumulado.
O problema se torna ainda mais relevante à medida que as políticas de proteção ficam mais sofisticadas. Regras avançadas de WAF, análise comportamental de bots e mecanismos adaptativos de rate limiting aumentam a capacidade de defesa da aplicação, mas também ampliam a dependência de uma arquitetura eficiente para processar essas decisões em tempo real.
Como Hairpinning e Backhauling Criam Latência
O hairpinning é apenas um sintoma de um problema maior: a necessidade de transportar o tráfego para um local diferente daquele onde ele entrou na rede para que a inspeção aconteça, e na maioria das vezes, centralizado.
Esse processo é conhecido como backhauling.
Em arquiteturas centralizadas, o tráfego frequentemente precisa percorrer centenas ou até milhares de quilômetros adicionais antes de chegar à aplicação.
Esse comportamento é particularmente comum em estratégias tradicionais de mitigação DDoS que dependem de scrubbing centers centralizados para filtrar tráfego malicioso antes de encaminhá-lo à origem.
Embora eficazes para absorver ataques volumétricos, esses modelos frequentemente aumentam a distância percorrida pelas requisições legítimas, introduzindo latência adicional no processo.
O impacto costuma aparecer em métricas como aumento do tempo de resposta, piora do Time to First Byte (TTFB) e degradação dos Core Web Vitals.
O desafio é que essas métricas mostram o sintoma, mas nem sempre revelam a causa.
Por isso, problemas relacionados ao backhauling costumam ser difíceis de diagnosticar. A aplicação continua saudável. Os servidores não apresentam gargalos. O banco de dados responde normalmente. Ainda assim, os usuários percebem lentidão.
Como Arquiteturas Distribuídas Reduzem a Latência de Segurança
Se o principal problema está no caminho adicional percorrido pelo tráfego durante a inspeção, a solução não é reduzir a profundidade da análise. O desafio é aproximar a mitigação do local onde o tráfego entra na rede.
É justamente isso que diferencia uma arquitetura distribuída de modelos tradicionais de WAF e mitigação DDoS baseados em processamento centralizado.
Na Azion Web Platform, WAF, DDoS Protection, Bot Manager e Network Shield operam em mais de 100 data centers distribuídos globalmente.
Isso significa que a inspeção acontece localmente, no mesmo ambiente responsável por receber a conexão do usuário. O fluxo passa a ser:
Usuário → Data center mais próximo (inspeção e mitigação) → OrigemÀ primeira vista, a diferença em relação ao modelo centralizado pode parecer pequena. Na prática, ela elimina os desvios que caracterizam o hairpinning e o backhauling.
Como a inspeção acontece no ponto de entrada da requisição, o tráfego segue diretamente para a aplicação, reduzindo a latência introduzida pela própria camada de segurança.
Distributed Scrubbing: Como Mitigar Ataques DDoS Sem Redirecionar Tráfego
Ao contrário de modelos que dependem exclusivamente de scrubbing centers centralizados para processar tráfego suspeito, a arquitetura da Azion permite que cada data center da rede realize scrubbing localmente.
Isso significa que, durante um ataque DDoS volumétrico, o tráfego malicioso é filtrado no próprio ponto de entrada, sem necessidade de redirecionamento para centros remotos de processamento.
O tráfego legítimo segue diretamente para a origem, preservando a performance mesmo durante ataques massivos.
Esse modelo distribui a capacidade de mitigação pela rede global. Em vez de concentrar toda a carga de processamento em poucos pontos, cada data center absorve sua parcela do ataque, mantendo a operação estável para usuários legítimos.
Case: GPA Mitigou Ataque DDoS e Protegeu 100+ Aplicações em 15 Dias
A diferença entre arquiteturas centralizadas e distribuídas não é apenas teórica. Ela se materializa em situações reais de crise.
O Grupo Pão de Açúcar (GPA), uma das maiores redes de varejo alimentício da América Latina, enfrentou um ataque DDoS direcionado aos seus serviços de DNS. Durante o incidente, a equipe precisava responder rapidamente enquanto mantinha a operação de e-commerce funcionando.
A solução veio através da migração para a Azion Web Platform, que incluiu:
- DDoS Protection para mitigar o ataque em tempo real
- Web Application Firewall (WAF) para proteger contra SQL Injection e XSS
- Bot Manager para prevenir ameaças automatizadas e fraudes
- Integração com SIEM para visibilidade de ameaças
Em 3 dias sob ataque, a equipe conseguiu estabilizar a operação. Em 15 dias, mais de 100 aplicações mission-critical estavam migradas e protegidas, sem downtime.
O resultado: 92% das requisições passaram a ser entregues através da plataforma distribuída da Azion, com latência significativamente reduzida. A empresa também alcançou uma redução de 30% nos custos de cloud.
Migrar para a Azion Platform foi uma decisão crucial. Deixamos para trás as limitações de um provedor legado e conquistamos maior agilidade e resiliência. A Azion nos protegeu de ataques cibernéticos sofisticados e nos permitiu modernizar nossa infraestrutura, reduzir custos e entregar as melhores experiências de compra para milhões de clientes.
— Allan Monteiro, CISO & Head of Technology na GPA
Como Identificar Latência Causada pela Camada de Segurança
Identificar quando a própria camada de segurança está causando degradação nem sempre é simples.
Enquanto aplicações, infraestrutura e bancos de dados costumam estar cobertos por ferramentas de monitoramento, eventos de segurança frequentemente ficam distribuídos entre diferentes sistemas.
O resultado é um processo de investigação mais lento e com menos contexto. Sem visibilidade unificada, correlacionar anomalias de performance com eventos de segurança pode exigir horas ou até dias de análise.
Com Real-Time Events, a Azion centraliza dados de tráfego e segurança em um único ambiente de observabilidade. Eventos gerados por WAF, DDoS Protection, Bot Manager, Network Shield e Functions podem ser analisados de forma integrada, permitindo que equipes investiguem anomalias sem alternar entre múltiplos consoles.
Os eventos ficam disponíveis em menos de um minuto na maioria dos casos, permitindo identificar rapidamente se uma anomalia de performance está relacionada a uma política de segurança, a um comportamento de bot detectado ou a uma configuração específica.
É Possível Mitigar Ataques Sem Comprometer a Performance?
Durante muito tempo, organizações acreditaram que proteger aplicações contra ataques DDoS e ameaças identificadas por WAF exigia aceitar algum impacto de performance.
Essa percepção fazia sentido em um cenário onde a inspeção dependia de centros remotos de processamento e scrubbing centers centralizados.
Hoje, o desafio não é apenas bloquear ataques. É fazer isso sem adicionar latência, complexidade operacional ou pontos cegos durante investigações de performance.
Arquiteturas distribuídas mudam essa equação ao aproximar a mitigação do local onde o tráfego entra na rede. Ao eliminar hairpinning, backhauling e a dependência de centros centralizados de inspeção, torna-se possível proteger aplicações sem comprometer a experiência dos usuários.
Se sua equipe está enfrentando problemas de latência sem causa aparente, vale a pena olhar além da aplicação. Em muitos casos, o gargalo não está no código, no banco de dados ou na infraestrutura de origem, mas na forma como a camada de segurança foi projetada para operar.
Descubra como a Azion pode ajudar sua organização a implementar mitigação de ataques em tempo real sem comprometer a performance.
Quer ver essa arquitetura em ação? Assista ao webinar “How to Mitigate Attacks on Web Applications and APIs” para uma demonstração técnica de mitigação distribuída.
