Em maio de 2025, a Cloudflare travou o maior ataque DDoS alguma vez registado: 7,3 terabits por segundo a atingir um único cliente, o suficiente para saturar milhares de ligações empresariais em simultâneo. Menos de um ano depois, esse recorde já tinha sido pulverizado por um ataque de 31,4 Tbps no quarto trimestre de 2025, segundo o relatório trimestral da própria Cloudflare. Para quem gere infraestrutura online em Portugal ou no resto da Europa, a pergunta deixou de ser “preciso de proteção DDoS?” e passou a ser “qual das três grandes opções cloud escolho: Cloudflare, AWS Shield ou Google Cloud Armor?”
Este artigo compara os três serviços lado a lado, com preços atuais, capacidade de mitigação documentada por múltiplas fontes, exemplos reais de ataques mitigados e um guia prático para quem precisa de migrar de fornecedor. A comparação foca-se especificamente em proteção contra negação de serviço distribuída (DDoS), um controlo diferente de uma firewall de aplicação web (WAF): o DDoS trava volume e inundação de tráfego nas camadas de rede e transporte, enquanto o WAF filtra pedidos individuais maliciosos na camada de aplicação. Muitas equipas acabam por precisar dos dois, mas raramente do mesmo fornecedor.
Porque é que a proteção DDoS voltou a ser prioridade em 2026
Os números do setor mudaram de escala nos últimos dois anos. A Cloudflare bloqueou 21,3 milhões de ataques DDoS em 2024 e já tinha ultrapassado esse total só no segundo trimestre de 2025, com 27,8 milhões de ataques bloqueados nesse período, segundo a própria empresa. A Netscout, numa análise independente do panorama global de ameaças, confirma mais de oito milhões de ataques DDoS registados em todo o mundo em 2025, alguns com picos que chegaram aos 30 Tbps. Estes dois relatórios, de empresas com metodologias distintas, apontam para a mesma conclusão: o volume e a intensidade dos ataques cresceram de forma consistente ano após ano.
Também mudou o contexto regulatório. Portugal transpôs a diretiva europeia NIS2 através do Decreto-Lei n.º 125/2025, que criou o Regime Jurídico da Cibersegurança e entrou em vigor a 3 de abril de 2026. Empresas classificadas como entidades essenciais ou importantes, incluindo prestadores de serviços cloud, centros de dados e redes de distribuição de conteúdo, passaram a ter obrigações concretas de gestão de risco e de notificação de incidentes significativos: aviso prévio em 24 horas, notificação em 72 horas e relatório final num mês. A escolha do fornecedor de proteção DDoS deixou de ser apenas uma decisão técnica e passou a ter peso na conformidade legal, com coimas que podem chegar aos 10 milhões de euros ou 2% do volume de negócios global.
Soma-se a isto um mercado que continua a crescer a bom ritmo. Segundo a consultora Mordor Intelligence, o mercado global de proteção DDoS valia 7,21 mil milhões de dólares em 2025, deve chegar a 8,48 mil milhões em 2026 e projeta-se em 18,17 mil milhões até 2031. As plataformas cloud já representam 63,21% desta fatia, com cinco fornecedores (Cloudflare, Akamai, AWS, Microsoft e Google) a controlarem cerca de 45% da receita global do setor.
Cloudflare, AWS Shield e Google Cloud Armor: visão geral rápida
Antes de entrar em números, vale a pena perceber a filosofia de cada serviço, porque isso explica praticamente todas as diferenças de preço e de arquitetura que se seguem. A Cloudflare funciona como um proxy reverso e CDN independente de qualquer cloud: o tráfego passa primeiro pela rede Anycast global da empresa antes de chegar à origem, seja essa origem AWS, Google Cloud, um centro de dados próprio ou um servidor alugado numa qualquer operadora portuguesa. Isto torna a Cloudflare a opção mais flexível para ambientes híbridos ou multicloud, algo comum entre empresas portuguesas que combinam infraestrutura on-premise com cloud pública.
O AWS Shield segue a lógica oposta: protege exclusivamente recursos dentro do ecossistema AWS, como distribuições CloudFront, balanceadores de carga Elastic Load Balancing, instâncias EC2, Global Accelerator e zonas Route 53. A versão Standard vem ativada automaticamente e sem custo em todas as contas AWS. A versão Advanced acrescenta deteção mais fina, mitigação ao nível da aplicação e acesso direto à equipa de resposta da AWS, mas amarra o cliente à AWS: não protege nada fora dela.
O Google Cloud Armor ocupa uma posição intermédia. É nativo do Google Cloud e integra-se com os balanceadores de carga globais da Google, mas o seu modelo de preços é o mais granular dos três, cobrando por pedido, por política de segurança e por regra, com opções de subscrição fixa para quem prefere previsibilidade de custos. É a escolha natural para quem já vive dentro do ecossistema GCP e quer manter a gestão de rede e de segurança no mesmo painel.
Tabela comparativa de especificações técnicas
A tabela seguinte resume as características técnicas e operacionais mais relevantes para quem está a avaliar os três serviços, com a Azure DDoS Protection incluída como referência adicional por ser a quarta opção mais procurada por equipas com presença multicloud.
| Característica | Cloudflare | AWS Shield | Google Cloud Armor | Azure DDoS Protection |
|---|---|---|---|---|
| Âmbito de proteção | Qualquer infraestrutura (proxy/CDN) | Apenas recursos AWS | Apenas recursos Google Cloud | Apenas recursos Azure |
| Camadas cobertas | L3/L4/L7 | L3/L4 nativo, L7 com AWS WAF | L3/L4/L7 | L3/L4 (L7 requer Application Gateway WAF) |
| Maior ataque mitigado divulgado | 31,4 Tbps (Q4 2025) | Não publica cifras por incidente | 398 milhões de req/s (L7) | Não publica cifras por incidente |
| Ativação automática | Sim, em todos os planos | Sim (Standard) | Requer configuração de política | Sim (Infrastructure Protection) |
| Modelo de rede | Anycast global, proxy reverso | Integrado na borda AWS | Integrado no Google Front End | Integrado na rede virtual Azure |
| Proteção de rede inteira (BGP) | Sim, via Magic Transit | Sim, via Shield Advanced + Global Accelerator | Não (foco em cargas HTTP/HTTPS) | Sim, via DDoS Network Protection |
| SLA de deteção/mitigação | Inferior a 10 segundos | Segundos (não publicado em detalhe) | Praticamente em tempo real | Segundos a dezenas de segundos |
| Suporte a incidentes dedicado | Incluído a partir do Business | Equipa DRT no Advanced | Suporte Google Cloud standard/premium | Suporte de resposta rápida no plano pago |
| Compromisso mínimo | Mensal (planos pagos) | 1 ano (Advanced) | Nenhum (Standard) / anual opcional | Nenhum |
| Integração WAF nativa | Sim, no mesmo painel | Sim, via AWS WAF (separado) | Sim, no mesmo produto | Via Application Gateway (separado) |
| Melhor cenário de uso | Multicloud, on-premise, sites públicos | Cargas 100% AWS críticas | Cargas 100% Google Cloud | Cargas 100% Azure |
Um ponto que costuma gerar confusão: a ausência de números públicos por incidente da AWS e da Azure não significa capacidade inferior à da Cloudflare. Significa apenas uma política de comunicação diferente. A AWS integra a proteção DDoS na escala geral da sua rede global, sem publicar relatórios trimestrais dedicados como faz a Cloudflare, o que dificulta comparações diretas de “quem aguenta mais Tbps”.
Preços em 2026: quanto custa cada opção
Os modelos de preços são talvez a maior diferença prática entre os três serviços, e explicam porque a escolha raramente é apenas técnica. A Cloudflare cobra por domínio com planos fixos; a AWS cobra uma taxa fixa por organização; a Google cobra ao consumo, com opção de subscrição. Eis os valores atuais.
| Serviço / plano | Preço | Modelo de cobrança | Inclui |
|---|---|---|---|
| Cloudflare Free | 0 $/mês | Por domínio | DDoS L7 ilimitado e não medido, WAF básico |
| Cloudflare Pro | 20 $/mês (anual) ou 25 $/mês (mensal) | Por domínio | WAF com mais regras, análise de tráfego |
| Cloudflare Business | 200 $/mês (anual) ou 250 $/mês (mensal) | Por domínio | SLA de 100%, regras WAF personalizadas, suporte prioritário |
| Cloudflare Enterprise | Personalizado (tipicamente 50 mil a 150 mil $/ano só para CDN+DDoS) | Contrato anual | Proteção “ilimitada e não medida” em toda a rede |
| AWS Shield Standard | 0 $/mês | Incluído em todas as contas | Mitigação automática L3/L4 |
| AWS Shield Advanced | 3.000 $/mês por organização | Subscrição anual + tráfego de saída | Deteção avançada, equipa DRT, proteção de custos |
| Google Cloud Armor Standard | 0,75 $ por milhão de pedidos (política global) / 0,60 $ (regional) | Pré-pago por consumo | Regras e políticas ao consumo |
| Google Cloud Armor Enterprise (Paygo) | ≈ 200 $/mês por projeto | Por hora de utilização | Pedidos, políticas e regras incluídos |
| Google Cloud Armor Enterprise (anual) | ≈ 3.000 $/mês por projeto | Subscrição anual | Tudo incluído, sem custos por pedido |
| Azure DDoS Network Protection | ≈ 2.944 $/mês (até 100 IPs) | Por plano de proteção | 29,50 $/mês por IP adicional |
| Akamai Prolexic | 15 mil a 30 mil $/ano de entrada | Contrato empresarial | Scrubbing dedicado, sem tabela pública |
Na prática, uma pequena empresa portuguesa com um site institucional fica coberta gratuitamente pela Cloudflare Free ou pelo AWS Shield Standard. O ponto de viragem acontece quando se precisa de garantias contratuais e suporte dedicado: aí, a Cloudflare Business a 200-250 dólares mensais compete diretamente com o Google Cloud Armor Enterprise Paygo a cerca de 200 dólares mensais, enquanto o AWS Shield Advanced e o Azure DDoS Network Protection ficam praticamente empatados nos 3.000 dólares mensais. A Akamai Prolexic só faz sentido para quem já ultrapassou os 100 mil euros anuais em orçamento de segurança de rede.
Capacidade de mitigação: o que dizem três fontes independentes
Para avaliar capacidade real, cruzámos três fontes distintas: os relatórios trimestrais da própria Cloudflare, o relatório de ameaças da Netscout e a documentação oficial da Google Cloud sobre o Cloud Armor. Nenhuma delas usa a mesma metodologia, o que aliás reforça a credibilidade quando os números apontam na mesma direção.
A Cloudflare documenta no seu relatório do quarto trimestre de 2025 um ataque recorde de 31,4 Tbps, poucas semanas depois de já ter reportado picos de 29,7 Tbps e 14,1 mil milhões de pacotes por segundo no terceiro trimestre. Em maio de 2025, a empresa já tinha travado o que na altura chamou de “maior ataque DDoS alguma vez registado”, com 7,3 Tbps, 12% acima do recorde anterior e mitigado sem intervenção humana. A progressão é constante: 2 Tbps no primeiro trimestre de 2024, 3,8 Tbps em setembro desse ano, 4,2 Tbps em outubro, 5,6 Tbps no final do ano, 7,3 Tbps em maio de 2025 e 31,4 Tbps no final de 2025.
A Netscout, cujo relatório de ameaças cobre o segundo semestre de 2025, confirma de forma independente mais de oito milhões de ataques DDoS a nível mundial, com picos que a empresa descreve como chegando aos 30 Tbps, e caracteriza o período como uma nova era de “atividade coordenada em hiper-escala” que ultrapassa a capacidade de resposta de muitas operadoras. O facto de duas empresas com telemetria e clientela diferentes chegarem a ordens de grandeza semelhantes (30 Tbps de um lado, 31,4 Tbps do outro) reforça que não se trata de marketing isolado de um fornecedor.
A Google, por seu turno, foca a comunicação na camada 7 em vez de volume bruto de rede. No blog oficial do Google Cloud, a empresa refere ter mitigado, através do Cloud Armor, um ataque de 398 milhões de pedidos por segundo, descrito como o maior ataque HTTP(S) documentado até à data. É uma métrica diferente da usada pela Cloudflare (Tbps de tráfego bruto) mas igualmente relevante: mede a capacidade de aguentar inundações de pedidos aplicacionais legítimos na aparência, um vetor cada vez mais comum à medida que os atacantes desviam de ataques puramente volumétricos.
Cinco ataques DDoS reais que puseram estes serviços à prova
Números de capacidade teórica são úteis, mas o que interessa a quem decide é saber como estes serviços se comportaram sob ataque real. Eis cinco casos documentados entre 2024 e 2025.
- Operadora de internet no leste asiático, 29 de outubro de 2024: um botnet variante do Mirai lançou um ataque UDP de 5,6 Tbps e 666 milhões de pacotes por segundo contra um cliente Cloudflare Magic Transit. O ataque durou cerca de 80 segundos e foi travado de forma totalmente autónoma, sem impacto percetível para os utilizadores finais da operadora.
- Cliente Cloudflare não identificado, maio de 2025: ataque recorde de 7,3 Tbps, mitigado sem qualquer intervenção manual da equipa de resposta, servindo de demonstração pública da proteção “não medida” incluída nos planos empresariais da Cloudflare.
- Campanha hiper-volumétrica de outubro de 2024: a Cloudflare registou mais de 200 ataques acima de 3 Tbps e 2 mil milhões de pacotes por segundo no terceiro trimestre de 2024, com o pico individual a atingir 4,2 Tbps e a durar apenas um minuto, um lembrete de que ataques curtos e intensos são hoje a norma, não a exceção.
- Fornecedor de alojamento asiático, início de 2024: outro botnet Mirai gerou um ataque de 2 Tbps, na altura o maior mitigado pela Cloudflare nesse ano, mantendo o serviço do fornecedor de alojamento sempre disponível durante o incidente.
- Cliente Google Cloud, ataque de camada 7: o Cloud Armor mitigou um pico de 398 milhões de pedidos HTTPS por segundo, um dos maiores ataques de aplicação já documentados publicamente, sem que o serviço do cliente ficasse indisponível.
É importante notar uma limitação honesta desta comparação: a AWS não publica estudos de caso detalhados por incidente com cifras de Tbps, ao contrário da Cloudflare e da Google. Isso não quer dizer que o Shield falhe mais vezes, apenas que a AWS trata a proteção DDoS como parte da resiliência geral da sua rede, sem relatórios de ameaças trimestrais equivalentes aos da Cloudflare.
Cloudflare em detalhe: vantagens e desvantagens
A Cloudflare continua a ser a opção mais popular para quem quer proteção DDoS sem ficar preso a uma única cloud. A empresa reivindica cerca de 82% de share num segmento específico de software de proteção DDoS e anti-bot medido por uma análise de mercado de 2024/2025, um número que deve ser lido com cautela porque se refere a um segmento restrito e não ao mercado total de serviços de mitigação, mas que ainda assim ilustra a adoção massiva do produto entre programadores e pequenas equipas.
Vantagens da Cloudflare
- Proteção DDoS incluída e não medida em todos os planos, incluindo o gratuito
- Funciona com qualquer infraestrutura de origem, não só AWS ou Google Cloud
- Rede Anycast com presença em centenas de cidades reduz a latência de mitigação
- Painel único para DNS, CDN, WAF e DDoS, o que simplifica a operação para equipas pequenas
- Preço previsível por domínio, fácil de orçamentar
Desvantagens da Cloudflare
- Proteção de rede inteira via BGP (Magic Transit) tem custo empresarial elevado e complexidade de configuração
- Depender de um único fornecedor externo para DNS e tráfego cria um ponto de falha adicional fora do controlo direto da equipa
- Contratos empresariais raramente têm tabela de preços pública, dificultando a comparação antecipada de custos
AWS Shield em detalhe: vantagens e desvantagens
Para equipas que já correm tudo dentro da AWS, o Shield é a opção com menor atrito de integração possível: não há DNS a mudar, não há proxy adicional, não há novo painel para aprender. A ativação do Standard é automática, e o Advanced integra-se diretamente com CloudFront, ELB, EC2, Global Accelerator e Route 53.
Vantagens do AWS Shield
- Standard gratuito e automático em todas as contas AWS, sem configuração
- Advanced dá acesso direto à equipa de resposta da AWS (DRT) e proteção contra custos inesperados durante ataques
- Zero necessidade de mudar DNS ou introduzir um proxy externo
- Integração nativa com AWS WAF para cobertura de camada 7
Desvantagens do AWS Shield
- Não protege absolutamente nada fora da AWS, um problema real para arquiteturas híbridas ou multicloud
- 3.000 dólares mensais fixos por organização tornam o Advanced pouco competitivo para PME com tráfego reduzido
- Compromisso mínimo de um ano de subscrição
- Ausência de relatórios públicos de incidentes dificulta avaliar a capacidade real de mitigação
Google Cloud Armor em detalhe: vantagens e desvantagens
O Cloud Armor é a escolha lógica para quem já usa balanceadores de carga globais da Google e quer manter tudo dentro do mesmo ecossistema de rede. A grande diferença face aos concorrentes é o modelo de preços ao consumo, que pode ser uma vantagem ou uma desvantagem consoante o perfil de tráfego.
Vantagens do Google Cloud Armor
- Modelo ao consumo pode sair mais barato para cargas de tráfego pequenas ou variáveis
- Integração nativa com o Google Front End e balanceadores de carga globais
- Regras avançadas de limitação de taxa (rate limiting) documentadas com casos reais de mitigação
- Sem compromisso mínimo no plano Standard
Desvantagens do Google Cloud Armor
- Exclusivo do Google Cloud, tal como o Shield é exclusivo da AWS
- Preço ao consumo pode tornar-se imprevisível em picos de tráfego legítimo elevado
- Menos casos públicos de ataques volumétricos de rede (L3/L4) documentados do que a Cloudflare
- Requer configuração ativa de políticas; não protege por omissão como o Shield Standard
Azure DDoS Protection e Akamai Prolexic: as alternativas a considerar
Nem toda a gente decide apenas entre os três nomes mais falados. A Azure DDoS Protection segue o mesmo princípio dos concorrentes cloud-nativos: a camada Infrastructure Protection é gratuita e automática em qualquer IP público Azure, enquanto a Network Protection cobra cerca de 2.944 dólares mensais para cobrir até 100 endereços IP públicos, com 29,50 dólares por IP adicional. Existe ainda uma opção IP Protection, a 199 dólares mensais por endereço, pensada para quem só precisa de proteger um número reduzido de recursos críticos sem contratar o plano completo de rede.
A Akamai Prolexic ocupa o extremo oposto do espetro: scrubbing dedicado, contratos empresariais a partir de 15 a 30 mil dólares anuais, com acordos de seis dígitos comuns entre bancos, operadoras de jogo online e grande retalho. Não existe tabela de preços pública, e a implementação normalmente demora semanas em vez de minutos, ao contrário da ativação quase instantânea da Cloudflare ou do AWS Shield Standard. Faz sentido para organizações com requisitos de conformidade muito específicos ou volumes de tráfego que justificam suporte dedicado 24 horas por dia.
NIS2 e o Decreto-Lei 125/2025: o que muda para empresas em Portugal
A diretiva NIS2 (2022/2555) não especifica que produto de proteção DDoS uma empresa deve usar, nem define uma capacidade mínima de mitigação em Tbps. O que exige é gestão de risco numa base de “todos os perigos”, incluindo riscos de disponibilidade, e medidas técnicas e organizacionais proporcionais à dimensão e criticidade da entidade. Na prática, isto significa que uma empresa portuguesa classificada como entidade essencial ou importante precisa de conseguir demonstrar, perante o Centro Nacional de Cibersegurança (CNCS), que tem um plano documentado de deteção e resposta a ataques de negação de serviço, com caminhos de escalonamento claros e retenção de registos suficiente para investigação posterior.
O Decreto-Lei n.º 125/2025, publicado a 4 de dezembro de 2025 e em vigor desde 3 de abril de 2026, estende esta obrigação a prestadores de serviços cloud, centros de dados, redes de distribuição de conteúdo, serviços de DNS e fornecedores de serviços geridos, entre outros. Isto é particularmente relevante porque significa que tanto quem usa Cloudflare, AWS Shield ou Google Cloud Armor como fornecedor de proteção, como as próprias empresas que operam estes serviços como infraestrutura digital, podem cair no âmbito da lei consoante a dimensão e o setor. As coimas previstas chegam aos 10 milhões de euros ou 2% do volume de negócios anual global, o que torna a escolha e a documentação da proteção DDoS uma decisão que já não pertence apenas à equipa técnica.
Cinco cenários de uso: qual escolher
A resposta certa depende quase sempre do ponto de partida da infraestrutura, não de qual serviço é “melhor” em abstrato. Eis cinco cenários comuns entre equipas portuguesas e europeias.
- Site institucional ou blog de pequena empresa: a Cloudflare Free cobre praticamente tudo o que é necessário, com DDoS de camada 7 ilimitado e sem custo, bastando apontar o domínio para os servidores de nomes da Cloudflare.
- Aplicação 100% alojada em AWS com tráfego crítico: o AWS Shield Advanced, apesar dos 3.000 dólares mensais, elimina a necessidade de introduzir um proxy externo e mantém tudo dentro do mesmo painel de gestão, o que simplifica auditorias internas.
- Startup multicloud com origem em GCP e AWS ao mesmo tempo: a Cloudflare como camada única à frente de ambas as clouds simplifica a operação e evita duplicar configuração de DDoS em dois painéis diferentes.
- Empresa já profundamente integrada em Google Cloud, com tráfego variável: o Cloud Armor Standard, ao consumo, evita pagar por capacidade não utilizada em períodos de baixo tráfego, algo comum em comércio eletrónico sazonal.
- Banco, operadora de jogo ou infraestrutura crítica sujeita a auditoria externa: a combinação de Akamai Prolexic (scrubbing dedicado) com um plano de resposta a incidentes documentado tende a ser exigida por seguradoras de risco cibernético e reguladores setoriais.
Guia de migração: de AWS Shield para Cloudflare
Migrar de proteção DDoS nativa da cloud para uma camada baseada em CDN como a Cloudflare costuma acontecer quando uma empresa expande para arquitetura multicloud ou híbrida. O processo tem duas frentes distintas: a camada de aplicação web (DNS e proxy) e a camada de rede (BGP), que raramente precisam de ser migradas ao mesmo tempo.
Corte de DNS para tráfego web
Para cargas HTTP e HTTPS, o processo típico começa por importar a zona DNS existente (normalmente gerida no Route 53) para a Cloudflare, que faz a leitura automática dos registos atuais. O passo seguinte é reduzir o TTL dos registos antes do corte, para acelerar qualquer reversão caso surjam problemas. Só depois se altera, no registador do domínio, os servidores de nomes para os da Cloudflare, tornando-a autoritativa pela zona. Nesse momento, ativa-se o proxy (“nuvem laranja”) nos registos relevantes, o que faz o tráfego passar pela borda da Cloudflare antes de chegar aos recursos AWS.
# Exemplo ilustrativo de fluxo de corte DNS
# 1. Reduzir TTL do registo antes da migração
dig A meuservico.pt
# 2. Confirmar que a zona foi importada corretamente na Cloudflare
# (via painel ou API antes da mudança de nameservers)
curl -s -X GET "https://api.cloudflare.com/client/v4/zones" \
-H "Authorization: Bearer SEU_TOKEN_API" \
-H "Content-Type: application/json"
# 3. Após confirmar propagação, desativar Shield Advanced
# apenas nos recursos já cobertos pela Cloudflare
aws shield list-protections --region eu-west-1Migração de regras WAF e desativação do Shield
Antes de desligar qualquer proteção antiga, documente todas as regras existentes no AWS WAF: listas de IPs permitidos e bloqueados, regras baseadas em taxa, bloqueios geográficos e verificações de cabeçalhos. Cada uma destas regras precisa de um equivalente nas expressões personalizadas da Cloudflare ou nos conjuntos de regras geridos (como o conjunto OWASP). A prática recomendada é implementar as novas regras primeiro em modo de registo apenas (log-only), sem bloquear tráfego, e comparar os alertas gerados durante pelo menos uma semana antes de ativar o bloqueio efetivo. Só depois de confirmar que não há falsos positivos relevantes é que faz sentido remover a proteção Shield Advanced dos recursos já cobertos, respeitando o compromisso mínimo de um ano da subscrição AWS. Para infraestrutura de rede inteira protegida por endereços IP próprios, a migração para Magic Transit da Cloudflare exige coordenação direta com a equipa de rede, incluindo o estabelecimento de túneis GRE ou IPsec entre a Cloudflare e a VPC AWS, um processo tipicamente conduzido em conjunto com o suporte técnico do fornecedor.
Erros comuns na escolha de proteção DDoS
Depois de analisar dezenas de configurações reais, há um padrão de erros que se repete independentemente do serviço escolhido. O primeiro é confundir “ter Cloudflare à frente do site” com “estar protegido contra tudo”. Se o registo DNS não estiver com o proxy ativado (a chamada “nuvem laranja”), o endereço IP real da origem continua exposto, e um atacante que o descubra pode contorná-la por completo e atacar diretamente o servidor. O mesmo vale para quem usa AWS Shield Advanced mas mantém instâncias EC2 com IP público acessível fora dos recursos formalmente protegidos.
O segundo erro é subestimar ataques de camada de aplicação por focar apenas em Tbps. Os números recorde da Cloudflare (31,4 Tbps) e a métrica da Google (398 milhões de pedidos por segundo) medem coisas diferentes, e um ataque de pequeno volume mas com pedidos aplicacionais complexos, como pesquisas de base de dados repetidas, pode derrubar um servidor muito antes de saturar a largura de banda. Isto explica porque tanto a Cloudflare como a Google Cloud Armor investem tanto em limitação de taxa (rate limiting) inteligente e não apenas em capacidade bruta de rede.
O terceiro erro, mais relevante para empresas sujeitas à NIS2 e ao Decreto-Lei 125/2025, é não ter um plano de resposta documentado. Ter o melhor serviço de mitigação do mercado não substitui a obrigação de conseguir notificar um incidente significativo às autoridades dentro dos prazos legais. Equipas que dependem apenas do painel do fornecedor, sem integrar os alertas num sistema de gestão de incidentes próprio, arriscam-se a cumprir a mitigação técnica mas falhar a conformidade regulatória, o que pode gerar coimas mesmo quando o ataque em si foi travado com sucesso.
Veredito final: qual o melhor serviço de proteção DDoS em 2026
Não há um vencedor absoluto, e qualquer artigo que afirme o contrário está a simplificar demasiado. Para a maioria das pequenas e médias empresas portuguesas com presença web pública, a Cloudflare Free ou Pro continua a ser o ponto de partida mais racional: custo zero ou quase zero, ativação em minutos e proteção DDoS de camada 7 sem limites contratuais. Para equipas já comprometidas a 100% com a AWS, o Shield Advanced elimina a fricção de introduzir um novo fornecedor, mesmo custando 3.000 dólares mensais fixos, um valor que só se justifica a partir de um certo volume de tráfego crítico. Para quem vive dentro do Google Cloud com tráfego variável, o Cloud Armor ao consumo evita pagar por capacidade parada.
Os números de capacidade favorecem claramente a Cloudflare em volume bruto documentado (31,4 Tbps no último recorde público, contra a ausência de cifras equivalentes da AWS) e a Google em picos de camada 7 (398 milhões de pedidos por segundo). Mas capacidade de pico raramente é o fator decisivo para uma PME: o que importa mais é a integração com a infraestrutura já existente, o custo previsível e a facilidade de cumprir as obrigações de notificação de incidentes impostas pelo Decreto-Lei 125/2025. Nesse critério prático, a Cloudflare vence pela flexibilidade multicloud, o AWS Shield vence pela ausência de fricção operacional dentro do seu próprio ecossistema, e o Google Cloud Armor vence pelo controlo fino de custos em cargas de tráfego imprevisíveis.
Perguntas frequentes
Preciso de pagar por proteção DDoS se já uso a AWS?
Não necessariamente. O AWS Shield Standard está incluído gratuitamente em todas as contas e cobre a maioria dos ataques de rede e transporte mais comuns. Só compensa pagar pelo Advanced, a 3.000 dólares mensais, quando existe tráfego crítico que justifique acesso à equipa de resposta dedicada da AWS.
A Cloudflare protege servidores que não estão na Cloudflare?
Sim. Ao contrário do AWS Shield e do Google Cloud Armor, que só protegem recursos dentro da respetiva cloud, a Cloudflare funciona como proxy independente e pode proteger qualquer origem, incluindo servidores on-premise ou noutra cloud, desde que o DNS aponte para a Cloudflare.
Qual destes serviços aguenta ataques maiores?
Com base em dados públicos, a Cloudflare documenta os maiores ataques volumétricos mitigados (31,4 Tbps no último recorde), e a Google documenta o maior ataque de camada 7 conhecido (398 milhões de pedidos por segundo). A AWS não publica cifras equivalentes por incidente, o que dificulta uma comparação direta de capacidade máxima.
A NIS2 obriga a usar um destes três serviços especificamente?
Não. A diretiva NIS2 e o Decreto-Lei 125/2025 não indicam produtos ou fornecedores específicos. Exigem apenas que empresas classificadas como entidades essenciais ou importantes tenham medidas de gestão de risco proporcionais e consigam cumprir os prazos de notificação de incidentes significativos.
É possível usar Cloudflare e AWS Shield ao mesmo tempo?
Sim, e é uma configuração comum. A Cloudflare pode ficar à frente do tráfego público como primeira camada de filtragem, enquanto o AWS Shield Standard continua ativo por omissão a proteger os recursos AWS subjacentes como camada adicional.
Quanto tempo demora a migração de AWS Shield para Cloudflare?
Para cargas web simples, o corte de DNS e ativação do proxy pode ficar concluído em poucas horas, incluindo tempo de propagação. Para proteção de rede inteira via BGP com Magic Transit, o processo costuma levar semanas, por envolver coordenação de rede e testes de tráfego em paralelo.
O Google Cloud Armor Standard cobre ataques de rede (L3/L4) ou só de aplicação?
O Cloud Armor cobre ambas as camadas, mas a comunicação pública da Google foca-se sobretudo em casos de camada 7 (pedidos HTTP/HTTPS), como o ataque de 398 milhões de pedidos por segundo. A proteção de camada 3/4 está integrada na infraestrutura de rede da Google, mas com menos estudos de caso publicados.
Vale a pena contratar a Akamai Prolexic em vez das opções cloud?
Só em casos específicos: organizações com requisitos de conformidade rígidos, tráfego que justifique scrubbing dedicado ou setores como banca e jogo online onde reguladores ou seguradoras exigem suporte 24 horas por dia com SLA contratual. Para a maioria das empresas, o custo de entrada de 15 a 30 mil dólares anuais não se justifica face às alternativas cloud.
O plano Cloudflare Free chega para um site de comércio eletrónico?
Para lojas pequenas com tráfego previsível, o plano Free costuma bastar para proteção DDoS básica, mas falta-lhe SLA contratual e regras WAF personalizadas. A maioria das lojas online em crescimento acaba por migrar para o plano Business assim que o volume de vendas justifica garantias de disponibilidade formais.
O que acontece se um ataque DDoS ultrapassar a capacidade contratada?
Nos três serviços analisados, a proteção contra volumetria é apresentada como “ilimitada” nos planos pagos, sem teto contratual de Tbps. Na prática, isto significa que o cliente não paga extra por um ataque maior do que o habitual, ao contrário de modelos antigos de scrubbing por capacidade fixa que ainda existem em alguns fornecedores regionais europeus.
