Quedas da Cloudflare e da AWS expõem fragilidade estrutural da internet moderna

Por Yohan Consani

As instabilidades registradas na última semana, na infraestrutura global da Cloudflare, que deixaram serviços como X, ChatGPT, Canva e dezenas de outras plataformas inacessíveis por algumas horas, acenderam mais uma luz vermelha sobre um problema que não é novo, mas está se tornando cada vez mais visível: a dependência concentrada de poucos pontos críticos da internet.

Diferentemente do que se imaginou nos primeiros minutos, não se tratou de um ataque ou de um simples “pico de tráfego”. A própria Cloudflare revelou que o incidente foi causado por uma combinação de mudanças de permissões em um banco de dados interno e um bug latente no módulo de Bot Management, o sistema que ajuda a diferenciar humanos de bots. Essa alteração passou a gerar um arquivo de configuração maior do que o limite suportado pelo software de proxy de borda. Quando esse arquivo inflado foi distribuído para os servidores ao redor do mundo, o módulo começou a falhar e o proxy passou a devolver erros em massa.

Em outras palavras: um problema em um componente “na borda” rapidamente se espalhou para toda a infraestrutura que depende dele. E isso, hoje, significa uma fatia enorme da internet: algo em torno de 20% dos sites usam Cloudflare como camada de segurança e performance.

Há pouco tempo, vimos algo semelhante ocorrer com a AWS. Em 20 de outubro, uma falha na região US-EAST-1, na Virgínia, provocou indisponibilidade de serviços como Reddit, Snapchat, Fortnite, Alexa e dezenas de outros, por cerca de 15 horas, por causa de problemas internos de DNS e de serviços de suporte na região. As causas técnicas são diferentes, mas o efeito para o usuário foi parecido: um único ponto crítico em um grande provedor tirou do ar serviços que atendem gente no mundo inteiro.

O padrão é claro, e é aqui que vale fazer uma distinção importante: o problema não é “depender da AWS” ou de qualquer outro grande provedor de nuvem. O problema é concentrar tudo em poucos pontos de falha, como uma única região de cloud ou um único provedor de borda, sem uma arquitetura preparada para continuar de pé quando uma dessas peças cai.

Leia também: Proofpoint conclui compra da Hornetsecurity por US$ 1,8 bilhão

Um ponto único de falha que ninguém deveria aceitar

Quando empresas colocam toda a sua operação atrás de um único provedor de CDN, DNS ou segurança, estão, na prática, construindo um ponto único de falha. Quando esse ponto falha, falha tudo junto. Isso ficou cristalino tanto no incidente da Cloudflare quanto no da AWS.

O mesmo raciocínio vale para a nuvem: não é o fato de usar “só AWS” ou “só GCP” que torna o ambiente frágil, e sim concentrar 100% do tráfego, bancos de dados e serviços críticos em uma única região, como a famosa us-east-1. Se aquela região entrar em colapso, o negócio para.

Uma arquitetura madura assume, desde o desenho inicial, que regiões, zonas de disponibilidade, data centers e provedores podem falhar. Para sistemas realmente críticos, a pergunta certa não é “qual cloud eu uso?”, mas sim: “se uma região inteira desaparecer, quem assume o serviço e em quanto tempo?”

As camadas que você não vê (mas que também quebram)

O problema é ainda mais profundo porque os próprios provedores de borda e nuvem também se apoiam em terceiros: rotas de peering, serviços de DNS gerenciados, bancos de dados, sistemas de filas e armazenamento, entre outros. Ou seja, mesmo que você monitore seu fornecedor principal, pode ser surpreendido por uma falha em uma camada que sequer aparece no seu diagrama de arquitetura.

Esse encadeamento invisível faz com que um incidente aparentemente “local”, um arquivo de configuração malformado ou um erro em um cluster de banco de dados, ganhe proporções globais em minutos, como vimos no 18 de novembro com a Cloudflare.

Prevenir falhas é mais importante do que corrigi-las

Para reduzir essa vulnerabilidade sistêmica, não basta “escolher um provedor confiável”. A estratégia precisa ser ativa, não reativa. Isso passa por:

• Monitoramento contínuo e detalhado de latência, taxa de erros, origem e volume do tráfego, não só da aplicação, mas também da CDN, DNS, filas e demais componentes de borda;

• Observabilidade real em logs e métricas de edge, como as regras de Bot Management e WAF no caso da Cloudflare, que muitas vezes antecipam anomalias de tráfego ou de configuração;

• Testes sintéticos e monitoramento de experiência do usuário, para flagrar degradações antes que elas virem indisponibilidade completa;

• Baselines claros de comportamento normal, permitindo detectar rapidamente desvios que indiquem regressões de configuração ou bugs latentes;

• Arquiteturas multi-região dentro do mesmo provedor de cloud, com replicação de dados, planos de recuperação de desastre e orquestração de failover automático entre regiões de forma que, se uma região inteira cair, outra assuma sem intervenção manual;

• Caminhos alternativos na borda, como o uso de mais de uma CDN, DNS com políticas de failover, e planos de fallback automatizados para serviços de autenticação, API gateways e roteamento.

Essas práticas não eliminam incidentes, mas impedem que eles se transformem em apagões completos. A diferença entre “meu site ficou lento” e “meu negócio parou” costuma estar justamente nessa capacidade de absorver falhas regionais ou de um fornecedor sem que o usuário final perceba.

Multi-região antes de multi-cloud

Muitos debates em tecnologia giram em torno do “multi-cloud versus single-cloud”, como se a resposta fosse trocar AWS por GCP, ou operar tudo em três clouds ao mesmo tempo. O incidente da Cloudflare e a queda recente da AWS mostram outra coisa:

• Se toda a sua operação está presa a uma única região, você continua vulnerável, mesmo estando em três provedores diferentes.

• Se você tem replicação entre regiões, automação de failover, testes regulares de caos (simular a queda de uma região) e dados preparados para isso, você já resolveu uma parte enorme do problema, mesmo estando em um único provedor.

Ou seja: antes de correr para uma estratégia multi-cloud complexa e cara, muitas empresas ganhariam muito mais resiliência simplesmente espalhando suas cargas de trabalho entre regiões e desenhando o plano de continuidade de negócio para o cenário em que “a região principal sumiu do mapa”.

A responsabilidade pela dependência é de quem a escolhe

Mesmo quando a causa está em um fornecedor distante da visibilidade do cliente, um bug em um módulo de Bot Management ou uma falha em DNS dentro de uma região da cloud, a responsabilidade pela cadeia de dependências continua sendo da empresa que a escolheu.

Gerenciar risco de terceiros é, antes de tudo, reconhecer que falhas vão acontecer. E que a arquitetura precisa estar pronta para absorvê-las. Dois pontos são essenciais:

• Mapear dependências explícitas e implícitas, inclusive camadas inferiores e integrações que o seu fornecedor principal utiliza;

• Simular falhas e testar rotas alternativas regularmente, em vez de confiar apenas em SLAs e promessas comerciais que, sozinhos, não garantem resiliência.

Um alerta claro e uma oportunidade de amadurecimento

A repetição de grandes incidentes em tão pouco tempo, primeiro em uma região crítica da AWS, agora na borda global da Cloudflare, mostra que a internet que usamos hoje é poderosa, mas frágil. Não por falta de tecnologia, e sim por excesso de concentração em poucos pontos e regiões.

Se há algo a tirar da queda da Cloudflare e do problema recente da AWS é a urgência de repensar como distribuímos, monitoramos e protegemos o tráfego que sustenta nossas operações digitais. A pergunta não pode mais ser “qual é o meu provedor?”, e sim: “quais são os meus pontos de falha e como eu sobrevivo à perda de cada um deles?”

No meu dia a dia profissional, tenho apoiado empresas justamente neste ponto: entender suas cadeias de dependência, reduzir riscos e construir arquiteturas que continuem de pé mesmo quando uma região inteira de cloud ou um grande provedor de borda falha.

A resiliência que o mercado precisa não virá da expectativa de que “não vai cair”. Ela virá da certeza de que, quando cair, e vai cair, o negócio seguirá funcionando, porque foi desenhado para isso desde o início.

Siga o IT Forum no LinkedIn e fique por dentro de todas as notícias!