Se você não conseguiu usar o Snapchat, pagar um amigo pelo Venmo ou se conectar a uma chamada no Zoom na segunda-feira, você não estava sozinho. Uma grande queda no AWS (Amazon Web Services) — o maior provedor de nuvem do mundo — provocou um verdadeiro caos digital, jogando luz, mais uma vez, na fragilidade da nossa internet hiperconectada e dependente de poucos provedores.
US-EAST-1: o “calcanhar de Aquiles” da Amazon
O epicentro da interrupção foi, de novo, o US-EAST-1, cluster localizado no norte da Virgínia — o data center mais antigo e um dos maiores da Amazon, frequentemente apontado em incidentes de grande repercussão. Em pelo menos três ocasiões nos últimos cinco anos, problemas ali se espalharam como dominó pela rede. A própria Amazon reconheceu que a falha desta segunda-feira se originou na região, mas não explicou por que esse site segue como um ponto recorrente de risco.
Serviços que ficaram fora do ar no Brasil e no mundo com a queda da Amazon
Quando tudo parou, vários serviços foram afetados globalmente e também no Brasil, confira o que ficou fora do ar com a queda:
- Globais: Snapchat; Reddit; Zoom; Venmo; Fortnite; Roblox; Duolingo; Coinbase; Robinhood; Signal; Prime Video; Alexa; Amazon.com (varejo); Ring; Epic Games Store; Perplexity; Canva; Airtable; Zapier; Microsoft Teams; Slack.
- No Brasil: Prime Video; Snapchat; Fortnite; Duolingo; Reddit; Facebook/Meta.
- Pix (BR): registrou lentidão e falhas ao longo do dia 20/out; a coincidência com a queda da AWS foi reportada por diversos veículos, embora o BC não tenha confirmado relação causal direta.
- Carteiras e meios de pagamento (BR): Mercado Pago e PicPay tiveram picos de reclamações durante a janela do incidente.
- Bancos (BR): houve picos de relatos de instabilidade em alguns apps bancários (ex.: Itaú, Santander, Bradesco) no período — sem confirmação oficial de vínculo com a AWS; relatos baseados em medidores públicos de indisponibilidade.
A pane na US-EAST-1 (falha no monitoramento dos load balancers com efeito em DNS e DynamoDB) gerou impacto em pagamentos digitais e back-ends de instituições/fintechs que dependem da AWS.
O que quebrou: monitoramento de rede e DNS em cascata
Tecnicamente, a causa raiz foi atribuída a um subsistema interno que monitora a saúde dos network load balancers — equipamentos (e serviços) que distribuem o tráfego entre vários servidores. Quando esse “vigia” interno falhou dentro da rede interna do EC2, efeitos colaterais atingiram a resolução de nomes do DNS, impedindo que aplicações encontrassem o endpoint correto da API do DynamoDB, serviço de banco de dados usado por milhares de apps para armazenar dados de usuários e operações críticas. Resultado: mesmo quem não usa DynamoDB diretamente sentiu o tranco, porque inúmeros serviços de back-end pararam de responder.
Foi um ataque hacker que derrubou a Amazon Web Services?
Até o momento não há indícios confiáveis de ataque hacker: os comunicados oficiais da AWS e a cobertura de veículos de alta credibilidade descrevem o incidente como falha interna — um problema no subsistema que monitora a saúde dos network load balancers dentro da rede do EC2, que desencadeou erros de DNS afetando endpoints do DynamoDB na região US-EAST-1 — e não mencionam intrusão. Embora sempre surjam especulações em redes sociais em eventos dessa magnitude, não existe evidência pública que aponte para ataque; se um pós-mortem oficial trouxer algo diferente, vale atualizar o texto com os detalhes.
Do cabeamento a você: como a falha virou um blecaute mundial
Pense na internet como uma metrópole em horário de pico: se um grande cruzamento apaga, o trânsito trava quilômetros adiante. Foi o que aconteceu. A interrupção no US-EAST-1 gerou um efeito cascata global. No Reino Unido, bancos como o Lloyds e serviços do governo (HMRC) ficaram intermitentes; operadoras como a Vodafone e a BT relataram problemas. Nos EUA e em outros países, apps populares como Snapchat, Reddit, Roblox, Duolingo, Coinbase, Robinhood e até serviços da própria Amazon — Prime Video e Alexa — caíram ou degradaram. Plataformas de videoconferência como Zoom e carteiras digitais como Venmo também patinaram. Segundo a Ookla (Downdetector), mais de 4 milhões de usuários reportaram falhas.
“AWS outage” e a dependência perigosa de poucos provedores
A cena reforça uma realidade desconfortável: a internet moderna roda, de ponta a ponta, sobre um punhado de grandes nuvens. Quando uma delas tropeça, sentimos o abalo — de pedir um carro no app a processar pagamentos ou checar um bilhete de embarque. Especialistas voltaram a alertar que, embora a nuvem ofereça ferramentas robustas de resiliência, muitas empresas ainda implantam sistemas “apertando prazos e cortando redundâncias”, e ficam expostas quando um AWS outage dessa escala acontece. Como disse o professor Ken Birman, da Cornell: quem pula a etapa de tolerância a falhas “é quem deveria ser mais cobrado depois”.
Por que o DNS dói tanto?
O DNS é o “catálogo telefônico” da internet: traduz nomes amigáveis (como api.servico.com) em endereços reais. Se a infraestrutura de DNS usada por um serviço falha — ou se componentes que alimentam essa resolução entram em estado inconsistente — aplicações não “sabem” para onde enviar as requisições. No episódio de segunda-feira, a combinação de falha no monitoramento dos balanceadores e impacto na resolução para o DynamoDB fez com que filas de mensagens entupissem e funções que dependem de endpoints em US-EAST-1 simplesmente parassem. Mesmo depois da recuperação, a Amazon admitiu que alguns serviços (como AWS Config, Redshift e Connect) ficaram com “backlogs” para processar por horas.
Um ecossistema digital frágil
Se você trabalha com nuvem, a pergunta que fica é: “isso era evitável?” Em parte, sim — e não. Sim, porque multi-AZ, multi-região, filas com retry e backoff, circuit breakers e até multi-cloud são práticas conhecidas para mitigar pontos únicos de falha. Não, porque a própria arquitetura de muitos serviços globais centraliza metadados, identidades e controle em regiões “padrão” — e a própria documentação da AWS lembra que o US-EAST-1 costuma ser o default em diversos serviços, o que amplia o impacto quando há problemas ali.
Negócios, dinheiro e confiança
Horas de indisponibilidade em cloud se traduzem em milhões de dólares em produtividade perdida e receitas atrasadas — sem contar o dano à reputação e o custo de suporte emergencial. Mesmo assim, o mercado financeiro foi pragmático: as ações da Amazon fecharam em alta modesta no dia, reflexo da leitura de que, apesar do solavanco, a dominância da AWS se mantém. Mas para quem opera plataformas críticas — de bancos a companhias aéreas e marketplaces — o recado é claro: resiliência não é luxo; é requisito de negócio.
Lições práticas (sem “pular etapas”)
O que muda amanhã? Primeiro, revisar dependências ocultas de US-EAST-1 (inclusive serviços globais que, na prática, ancoram controles na região). Segundo, validar planos de falha: testes de caos (chaos engineering), simulações de failover real e políticas de degradação graciosa que mantenham o essencial funcionando (ex.: “modo offline” com cache local). Terceiro, avaliar diversificação — nem sempre multi-cloud é viável, mas pensar em multi-região e desacoplamento por filas/eventos costuma caber no orçamento. Por último, monitorar sinais amarelados: latências de API, picos de erro em serviços de identidade e metadados, e alertas dos health dashboards da nuvem. Numa infraestrutura tão concentrada, minutos de vantagem fazem diferença.
