- A falha da AWS, maior serviço de nuvem do mundo, deixou milhares de sites e apps fora do ar e levantou o alerta de que a infraestrutura da internet está excessivamente dependente de poucas empresas
- Serviços principais como Snapchat, Roblox, Signal e Duolingo e até instituições públicas e financeiras como Lloyds Bank, Ring e HMRC foram incluídos no escopo de impacto
- A AWS atribuiu o incidente a um erro interno na região do leste dos EUA, descartando a possibilidade de ataque cibernético, e a maior parte já foi recuperada em poucas horas
- Especialistas afirmaram que o “debate democrático e o jornalismo não deveriam ficar subordinados à infraestrutura de poucas empresas”, destacando a necessidade de diversificação da infraestrutura em nuvem
- A estrutura concentrada em grandes empresas de nuvem revelou a fragilidade da internet global, impulsionando o debate sobre soberania tecnológica da infraestrutura pública
Visão geral da falha
- A partir de aproximadamente 8h de segunda-feira no horário local (16h no horário do Reino Unido), houve uma interrupção massiva de serviços globais causada por um erro interno em US-East-1 (região leste dos EUA) da AWS
- A Amazon anunciou que a taxa de erros e a latência da API aumentaram
- Segundo o Downdetector, mais de 2.000 empresas foram impactadas no mundo todo, com mais de 1,9 milhão de relatos nos EUA, 1 milhão no Reino Unido e 410 mil na Austrália
- A AWS apontou como causa um problema no subsistema de monitoramento do balanceador de carga interno, descartando a possibilidade de um ataque cibernético
- Foi relatado que houve falhas em respostas da API relacionadas ao DynamoDB da AWS
- Foi implementado temporariamente um limite de solicitações para evitar picos de tráfego
- A AWS anunciou oficialmente o retorno ao funcionamento normal no fim da tarde, mas alguns serviços continuaram recebendo relatos de falhas persistentes
Escopo de impacto
- Principais serviços: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton, entre outros
- No Reino Unido, houve indisponibilidade de acesso a serviços financeiros como Lloyds, Halifax e Bank of Scotland, além do site do HMRC (Inland Revenue)
- Usuários do Ring Doorbell relataram desconforto ao afirmar que o serviço de monitoramento de abertura de portas ficou indisponível
- Também foram relatadas falhas de acesso em plataformas globais como Epic Games, Pokémon Go e Wordle
Análise de especialistas
- Dr. Corinne Cath-Speth (Article 19): “É arriscado que as bases do discurso democrático e do jornalismo independente dependam da infraestrutura de poucas empresas. A diversificação da nuvem é urgente”
- Cori Crider (Future of Technology Institute): “O Reino Unido precisa se afastar da dependência da big tech americana. A falha em um único ponto da AWS deixou de forma clara a economia moderna em pausa”
- Madeline Carr (UCL): “Embora o capital das grandes empresas de nuvem mantenha segurança e escalabilidade, a estrutura que prende o mundo inteiro a um único risco é extremamente perigosa”
- Steven Murdoch (UCL): “A causa parece ser um erro operacional interno da AWS, e não um ataque cibernético”
Resposta governamental e regulatória
- O governo britânico informou que ativou um contato de emergência com a AWS e monitorou a evolução da recuperação
- A Comissão de Finanças da Câmara dos Comuns do Reino Unido pediu que a AWS seja classificada como “terceira parte crítica” no setor financeiro
- Com a classificação, a empresa passaria sob supervisão das autoridades regulatórias financeiras e possibilitaria garantir maior estabilidade da infraestrutura financeira
- O presidente Meg Hillier criticou que, embora a AWS prometa “resiliência”, na prática expôs vulnerabilidades
Contexto e implicações
- A AWS lidera com mais de 30% de participação no mercado global de nuvem
- Junto com Microsoft Azure e Google Cloud, está se consolidando uma estrutura dominante de três grandes fornecedores de nuvem
- Em 2024, houve também o incidente de tela azul em PCs Windows em escala global causado por um erro de software da CrowdStrike
- Este episódio novamente destacou os riscos sistêmicos da concentração da infraestrutura digital e reacendeu o debate sobre soberania tecnológica e estratégias de diversificação da nuvem em diversos países
3 comentários
Força, Naver Cloud!
"Se você não gosta de nuvem, então construa e use por conta própria." Fico me perguntando se ainda é possível discutir isso.
Multicloud? Nem o seu avô vai te ajudar a montar e administrar isso.
Opinião do Hacker News
Estamos discutindo que vários serviços estão fora do ar na AWS us-east-1, e há um fio longo sobre isso aqui.
Mesmo na falha da Fastly em 2021, os “especialistas” fizeram críticas parecidas, mas não houve mudanças concretas. Uma semana depois, esse tipo de assunto não aparece mais no noticiário. Quem está no dia a dia sabe o quão difícil é operar na escala da AWS. Os verdadeiros contramedidas para se preparar para esse cenário custam caro demais, então o retorno é mínimo para a maioria das empresas. Se um serviço é realmente “crítico”, faz sentido projetá-lo para tolerar esse tipo de falha. Não conseguir fazer login no Fortnite mostra como é pouco factível, na prática, fazer esse tipo de preparo e qual é o custo envolvido. A imprensa também não trata de multi-região ou multi-cloud no dia a dia; só menciona quando ocorre um incidente e logo esquece. No fim, o que se quer é entender a causa técnica. Críticas de “especialistas” sem follow-up não significam muito. O importante é uma análise de incidente construtiva, sem culpados, em vez de meras críticas sem ação.
Os “especialistas” mencionados aqui são pessoas sem experiência real em infraestrutura ou operação de nuvem. Por exemplo, Dr. Corinne Cath-Speth é doutora em antropologia, Cori Crider é advogada, e Madeline Carr é professora de ciência política. Ou seja, são pessoas que escrevem papers e fazem entrevistas na mídia, não de fato operam serviços de hospedagem.
Ao criticar a dependência da nuvem, acaba-se aceitando a ideia de que é preciso tolerar mais de 16 horas de indisponibilidade por ano. Uma queda de algumas horas é altamente perceptível para um usuário, mas a degradação de desempenho nas outras 8.742 horas pode ser ainda mais grave. Se uma empresa quebra com apenas 16 horas de downtime, talvez eu e você estejamos ignorando a realidade do negócio dela. Tenho mais interesse em alta disponibilidade, geo-redundância e sistemas com alta durabilidade.
Não é necessário gastar uma fortuna para isso. Nem todo serviço precisa aguentar esse nível de impacto. Ao usar fornecedores diferentes, dá para reduzir a chance de todos caírem ao mesmo tempo.
O que a mídia chama de redundância multi-região/multi-cloud costuma ter baixa efetividade. Mesmo quando parece que só uma região foi afetada, na prática vários serviços se espalhados entre regiões acabam impactados. Hot stand-by multicloud tende a ficar caríssimo conforme a infraestrutura cresce em complexidade. Implementar depois, sem planejamento inicial, é muito difícil.
Nos relatórios que a própria AWS publica, vê-se uma concentração excessiva em uma região específica e em serviços específicos (como DynamoDB). Essa arquitetura centralizada vem sendo observada há mais de dez anos. Ainda assim, não muda. Neste incidente, mais de 2.000 serviços ficaram indisponíveis por um longo período. Veja o status da AWS.
Talvez valha a pena pensar em substituir “cloud” ou “internet” por “armazém na Virgínia”. Por exemplo: “Nosso serviço está inteiramente no armazém da Virgínia”, “todos os meus arquivos estão no armazém da Virgínia”, “o armazém da Virgínia foi projetado para resistir a uma guerra nuclear” etc. original
Já existem vários provedores de VPS, e há relatos frequentes de redução de custo ao migrar para esse lado; na prática, isso parece ser mais questão de lock-in de nuvem e marketing.
Hoje em dia, as empresas usam serviços de alto nível da AWS como DynamoDB, RedShift, em vez de IaaS de baixo nível como EC2. Azure e Google Cloud estão em situação semelhante. Quando se fica preso a esses serviços de alto nível, migrar para algo como VPS da Hetzner ou self-hosting fica monstruosamente complexo, porque seria preciso reinstalar e operar praticamente toda a stack da AWS novamente. Não adianta só colocar PostgreSQL.
Sempre que aparece alguém dizendo que economizou com VPS, costuma vir o contraponto de que “AWS é web scale e não quebra, e VPS é uptime de 1 dia no mês”.
Também estou curioso se a EC2 também foi afetada nesse incidente.
A opinião de especialistas, de fato, parece focar mais no contexto geopolítico (por exemplo, sistemas nacionais inteiros dependendo em tempo real de empresas estrangeiras) do que na parte técnica. Normalmente, para uma empresa comum, depender de um único fornecedor simplifica a complexidade e não é ruim em termos de frequência de falhas. Não é obrigatório usar multi-cloud. Ficar em um fornecedor pode até melhorar a frequência de indisponibilidade.
Acho que a indústria toda está presa ao lock-in de cloud. Fico me perguntando como conseguir inverter isso daqui para frente. Vejo o Docker como um dos responsáveis por lock-in, junto com as grandes clouds.
Para quem trabalha na linha de frente de operação de cloud, a realidade é que ao descobrir às 1h da manhã que tudo desmoronou por uma pane global da AWS, ninguém está interessado em mudar isso naquele momento.
Fico curioso por que o Docker é citado como problema.
Já não estou há muito tempo na operação de cloud, mas na época as funcionalidades básicas (primitives) estavam sendo niveladas entre os provedores. Fico curioso se redundância multi-cloud foi cara demais, se a lacuna tecnológica era grande demais ou se não valia nem discutir do ponto de vista de negócios. slide de pets vs cattle
Colocar, operar e gerenciar em várias clouds pesa demais para a equipe. Manter expertise de infra em dois ou mais provedores demanda muito pessoal. Times pequenos ou ágeis não suportam. A simplicidade de usar uma única cloud se converte diretamente em uptime. Mesmo grandes empresas têm vantagem em comprar em volume numa única cloud e reduzir custo unitário. E ninguém é demitido por escolher AWS.
Também há baixa efetividade porque uma outra cloud nem sempre consegue ajudar se a cloud principal sofre pane na própria região. Os fornecedores continuam impondo 100% seus próprios padrões e o control plane ainda é Kubernetes. No fim, todo mundo acabou em Kubernetes.
Todas as clouds entregam compute barato, mas cobram saída de rede (egress) de forma absurda. Montar multicloud faz o custo de tráfego disparar; isso parece intencional.
Na prática, parece que os provedores se sustentam com a receita de egress. Por isso, em muitas nuvens e aplicações, até redundância entre regiões ou AZs dentro de uma mesma cloud é cara demais. Em uma pane global de uma única cloud, redundância entre regiões não ajuda. E, quando uma cloud cai, migrar tráfego para outra cloud também é difícil e a relação custo-benefício do esforço é ruim. Para a maioria das aplicações, é melhor aceitar algumas horas de indisponibilidade e gastar dinheiro e esforço em outra prioridade.
Há muitos clientes que mantêm arquivos/dados na cloud; se estiver num fornecedor e também em outra cloud, operar fica complicado e atrai menos clientes. Como o fornecedor vira padrão de mercado, os clientes concentram dados nele, o que torna difícil justificar custo de armazenamento em duas clouds. Eu também comecei querendo ficar independente de plataforma, mas, na prática, como todos os potenciais clientes usam a mesma cloud, a complexidade ficou menor.
Não dava para prever previamente, este ano, que a AWS us-east-1 ficaria com apenas dois “9” de uptime.
Como alguém que usa AWS há quase 20 anos, não entendo a razão de alguém escolher us-east-1 para o tráfego mais pesado e mais importante. É a região mais antiga e menos estável.
Também fico curioso se instâncias do tipo EC2 foram realmente afetadas.
Muita gente pensa que, se tudo fica indisponível, então todo mundo está coberto; isso não é experiência real para serviço voltado ao usuário comum.
A causa desta falha foi um problema no subsistema interno responsável pelos health checks do network load balancer. status da AWS