Cloudflare, AWS e CrowdStrike: os incidentes que obrigam a repensar as dependências

Três horas de downtime na Cloudflare esta terça-feira, dia 18 de novembro, afetaram cerca de 20% do tráfego global. Há cerca de um mês, uma falha na AWS acabou por paralisar milhares de serviços durante aproximadamente 15 horas. Em julho de 2024, uma atualização defeituosa da CrowdStrike deixou perto de 8,5 milhões de dispositivos Windows em loop de reinicialização. O padrão mostra que há uma dependência excessiva em fornecedores dominantes que cria um risco que as organizações não devem ignorar.

O incidente da CrowdStrike em julho de 2024 resultou de uma falha na atualização do Falcon Sensor que causou o famoso ‘Blue Screen of Death’ em milhões de sistemas Windows, afetando múltiplos setores em todo o mundo; aviação, finanças, saúde ou administrações públicas foram apenas alguns. De acordo com a Parametrix, as empresas do Fortune 500 (excluindo a Microsoft) tiveram 5,4 mil milhões de dólares em perdas diretas.

A AWS, que detém cerca de 30% da quota de mercado global de cloud, sofreu em outubro de 2025 uma interrupção de serviço durante 15 horas na região US-EAST-1 (Virgínia do Norte, Estados Unidos), causada por uma race condition num sistema de automação que provocou falhas de resolução DNS no DynamoDB que desencadeou falhas em serviços dependentes, como EC2 e Lambda. Estima-se que afetou milhares de empresas (como Snapchat, Delta e United Airlines e serviços bancários no Reino Unido) e milhões de utilizadores em todo o mundo. Estima-se que, durante as 15 horas de interrupção, as organizações tenham perdido cerca de 1,1 mil milhões de dólares.

O incidente mais recente é o da Cloudflare, que durou aproximadamente três horas e teve uma recuperação faseada dos diferentes serviços. Até ao momento de publicação deste artigo, a informação ainda é escassa, mas, em determinado momento, a empresa decidiu desativar temporariamente o acesso WARP em Londres, que sugere problemas localizados de routing com potencial impacto em cascata. O impacto financeiro ainda vai ser apurado.

Um problema estratégico

A consolidação em fabricantes dominantes oferece economia de escala e conhecimento técnico superior, mas também cria um risco. A AWS, a Microsoft Azure e a Google Cloud controlam, em conjunto, cerca de 62% do mercado global de cloud, segundo dados do Q2 de 2025 da Statista. Do lado dos CDN e DNS, a Cloudflare, a Akamai e a Fastly dominam uma fatia significativa do tráfego web mundial. Quando um destes fornecedores falha, o impacto não é localizado, mas sim generalizado e simultâneo. Esta concentração significa que a maioria das organizações depende de um destes fornecedores para operações críticas.

Os incidentes recentes demonstram a magnitude dos riscos. A interrupção de serviço de 15 horas da AWS em outubro custou às organizações uma média estimada de 75 milhões de dólares por hora. O incidente da CrowdStrike afetou 60% das empresas do Fortune 500. Esta concentração transforma falhas técnicas em eventos com impacto económico em milhares de organizações.

O problema não é a fiabilidade técnica dos fornecedores, até porque os SLA de 99,99% são, na larga maioria das vezes, cumpridos. O problema é que, quando falham, não existe uma alternativa imediata para a maioria das organizações. A questão que importa fazer é “quanto tempo a organização aguenta quando o fornecedor principal falhar?”

Para responder à pergunta é necessário calcular o custo real de downtime: receita perdida por hora de serviços inacessíveis; impacto reputacional e perda de clientes; custos operacionais de equipas em modo de crise; e eventuais penalizações contratuais e obrigações regulatórias.

Uma PME com cinco milhões de receita anual dependente de sistemas digitais críticos perde aproximadamente 570 euros por hora de interrupção de serviço. Três horas custam 1.710 euros e 15 horas 8.550 euros. Uma empresa de média dimensão com 20 milhões de euros de receita dependente de infraestrutura digital perde 2.280 euros por hora, 6.840 euros em três horas e 34.200 euros em 15 horas. Se estes valores forem considerados aceitáveis tendo em conta a probabilidade de ocorrência, a organização pode optar por aceitar o risco. Se não forem, a estratégia tem de incluir redundância e o custo dessa redundância tem de ser inferior ao custo esperado de interrupção de serviço.

Estratégias para as organizações

O primeiro passo é ter uma visibilidade total. Isto significa documentar que serviços dependem de que fornecedores externos e identificar os pontos únicos de falha. A questão é simples: se um determinado fornecedor falhar, que serviços da organização param imediatamente? Esta visibilidade é a base para qualquer estratégia de resiliência.

Depois de identificar as dependências críticas, é necessário avaliar onde faz sentido implementar redundância. Uma estratégia multi-CDN, por exemplo, pode não fazer sentido para todos os ativos, mas é crítica para serviços que geram receita direta.

A maioria das organizações já utiliza múltiplos fornecedores. Segundo a Flexera, 92% das empresas adotaram estratégias multicloud, mas frequentemente por razões de custo ou flexibilidade, não resiliência. O problema é que a multicloud sem um failover automatizado não oferece proteção real; se a AWS cai, ter conta na Azure não ajuda se não houver um mecanismo de switching automático entre as duas.

No entanto, a redundância total não é, para a maioria das empresas, economicamente viável. A abordagem correta (conhecida por todos os CISO, mas que importa sempre relembrar) passa por identificar os serviços críticos (como autenticação, pagamentos e API públicas) e implementar um failover apenas para esses. Uma resiliência maior requer um custo maior e o investimento deve ser proporcional ao impacto real do downtime.

Por fim, ter redundância não basta; é necessário testá-la regularmente. Testar falhas propositadamente em ambientes controlados e simulacros de disaster recovery identificam falhas antes de ser crítico. A pergunta não é se há um backup, mas sim se a recuperação desse backup foi testada nos últimos seis meses (e funcionou).

Aceitar o risco de forma consciente

A dependência cega num único fabricante ou serviço não é aceitável para a infraestrutura crítica de uma determinada organização. No entanto, eliminar todos os pontos de falha é impossível. O objetivo passa por aceitar o risco de forma consciente e informada.

As organizações devem avaliar o risco e o impacto da falha de cada aplicação. Para workloads que não são críticos, é provável que depender de um só fabricante seja aceitável. Para sistemas que geram receitas recorrentes para o negócio a redundância deixa de ser opcional.

Estes incidentes (Cloudflare, AWS e CrowdStrike, entre outros) demonstram que falhas em fornecedores dominantes não são apenas possibilidades teóricas. O ponto importante a reter é sempre o mesmo: não é uma questão de ‘se’ vai acontecer, mas sim ‘quando’ vai acontecer.