Várias falhas de serviço na região us-east-1 da AWS

• Diversos serviços no us-east-1 da AWS apresentaram interrupção
• Empresas que usam infraestrutura em nuvem relataram interrupção de serviço por causa do incidente
• Foram reportados problemas de disponibilidade em serviços principais como API Gateway, Lambda
• Engenheiros destacaram a necessidade de preparar rotas alternativas e revisar planos de contingência
• O AWS Health Dashboard passou a fornecer informações e atualizações de incidente em tempo real

---

Visão geral da interrupção na região AWS us-east-1

• Em 21 de outubro de 2025, o AWS Health Dashboard reportou falhas em vários serviços da região us-east-1
• Serviços críticos como API Gateway, Lambda, S3 foram afetados, e muitos clientes sofreram interrupção de serviço
• Desde o início da falha, a AWS iniciou imediatamente a análise de causa raiz e os trabalhos de recuperação
• Empresas de SaaS, startups e TI dependentes dessa região relataram atraso de serviço e downtime
• Engenheiros e gerentes de TI destacaram a necessidade de criar rotas de contingência e estratégias de múltiplas regiões para serviços críticos

Impacto e resposta

• A região us-east-1 é uma das áreas com maior tráfego na infraestrutura de nuvem global, então o impacto é muito grande em caso de falha
• Na prática, vários clientes relataram problemas simultâneos, como interrupção da prestação de serviço, latência de resposta da API e falha de processamento de dados
• A AWS informou o status em tempo real e forneceu documentação de suporte e atualizações por meio do Health Dashboard
• Times de TI de clientes agiram para minimizar danos por meio de monitoramento da situação de falha, alternativas temporárias e avisos aos usuários

Implicações para engenheiros

• A ocorrência reforçou a necessidade de validar a importância de sistemas de monitoramento e sistemas de notificação de incidentes
• O valor do projeto de arquiteturas resilientes como implantação multi-região, mitigação de falhas automatizada e estratégias de backup ficou evidenciado
• O AWS Health Dashboard é utilizado como ferramenta para obter informações rapidamente e apoiar decisões em situações de falha

Conclusão

• Operadores de serviços de nuvem em grande escala precisam preparar contramedidas para a possibilidade de interrupção de serviço de forma essencial
• A importância de um processo de recuperação ágil, comunicação transparente e capacidade eficaz de resposta a incidentes de infraestrutura foi novamente destacada durante a falha

[GN⁺]

Opinião no Hacker News

• Hoje foi realmente um dia interessante. Fiquei no bridge de resposta a incidentes desde as 3h da manhã. O sistema já foi recuperado quase por completo, mas ainda há uma equipe no backoffice tendo dificuldade com falta de recursos. O maior erro do nosso lado foi que, embora tivéssemos projetado para funcionar em múltiplas regiões, não conseguimos executar o processo de failover. Isso aconteceu porque a equipe de segurança nos moveu para o Identity Center e o colocou apenas no us-east-1, deixando a empresa inteira totalmente presa no AWS control plane. Quando pegamos as credenciais root do cofre, o sistema já estava praticamente recuperado. Isso me relembrou, mais uma vez, que o elo mais fraco decide a robustez do conjunto.
  • Faz sentido eu lembrar de alguns anos atrás, quando o data center do Google em Paris alagou e pegou fogo. Não tínhamos recursos de compute lá diretamente, mas estávamos computando em data centers da AWS EU, e o resolvedor de DNS dos serviços do Google estava hospedado em Paris, então o tráfego era roteado para lá primeiro. A solução alternativa foi bem interessante. Foi quando descobrimos que dá para editar o arquivo /etc/hosts implantado no Kubernetes de forma global com facilidade, e foi preciso fazer isso na prática. Normalmente não usamos /etc/hosts para esse tipo de situação, mas como hotfix foi uma abstração muito adequada.
  • Lembro de um caso semelhante no Facebook, em que uma atualização de BGP tornou completamente impossível o acesso ao cofre. Se a cadeia do caminho de autenticação é circular, quando o DNS quebra nada pode ser feito.
  • No fim, chega o momento em que alguém precisa pegar um token de hardware e pegar um avião até outro data center para resetar um componente crítico e fazer o sistema global voltar a funcionar.
  • Mencionaram que o Identity Center ficou só no us-east-1; fiquei curioso se dá para distribuir em várias regiões. Da última vez que verifiquei, só era possível usar em uma região, e para mover era necessário excluí-lo antes.
  • Excesso de segurança acaba travando o movimento. Fico curioso se o time de segurança vai assumir a responsabilidade por isso. Isso deve fazer todos os projetos seguirem mais devagar. Parece que andaram em alta velocidade demais com segurança. Quem monitora os monitores?
• Parece que ainda há falhas críticas em andamento. A situação está pior do que há quatro horas. Sou engenheiro de dados e Redshift e Airflow (serviço gerenciado da AWS) estão um caos completo.
  • A pane já está há bastante tempo. Fico curioso para saber quantos 9s se foram. 365 dias * 24 horas * 0,0001 dá cerca de 8 horas, então já perdemos 99,99% de disponibilidade.
  • Não entendo por que tantas empresas continuam apostando em us-east-1. Em frequência de incidentes, ela é amplamente a pior. Nossa empresa, anteriormente, decidiu evitar us-east-1 e usar só outras regiões. Claro, quando um serviço é dito “global”, em muitos casos isso significa us-east-1 na prática, então isso pode não ajudar.
  • As operações de plano de controle do Lambda create-function ainda falham com InternalError. Outros serviços (Lambda, SNS, SQS, EFS, EBS, CloudFront) foram restaurados. Eu curso mestrado em Ciência da Computação com foco em disponibilidade em nuvem, então testei isso em várias contas AWS e registrei o cronograma do impacto em um texto. Post de análise
  • O Down Detector continua mostrando que a falha da AWS ainda é grave. A Amazon diz que “a recuperação está em andamento”, mas, na prática, a busca no Amazon.com também não funciona. AWS Health
  • No Down Detector, às 12:52 AM PT (3:53 AM ET) houve 5.755 relatos de problema da AWS; às 4:22 AM PT (7:22 AM ET), caiu para 1.190, e às 9:32 AM PT (12:32 PM ET) subiu de novo para 9.230. Parte disso pode ser que o oeste dos EUA acordou e aumentou os relatórios, mas parece que a AWS ainda não controlou a situação de fato.
• Esta pane teve impacto direto no meu dia a dia. Eu fui ao Whole Foods do Hudson Yards, em Nova York, comprar uma barra de chocolate, e não consegui aplicar o desconto Prime; acabei não comprando, então meu nível de chocolate ficou bem baixo.
  • Hoje de manhã, "Alexa, liga a chaleira de café" também não funcionou. Fiquei com a cabeça apagada.
  • No almoço, peguei comida no hot bar e tentei passar no auto checkout; fiquei pensando por um bom tempo por que o código de barras do Whole Foods não funcionava. Só depois de uns 20 segundos percebi que era por causa da pane.
  • Foi ótimo compartilhar um caso curioso. Mas isso me deixou curioso sobre o que aconteceu com as pessoas que estavam em lojas Amazon Go durante a pane da AWS.
• Hoje tenho reunião com o responsável pela conta da AWS. Vou explicar a ideia de sair do “all-in on AWS” e distribuir as cargas de trabalho. O principal motivo é que a inovação nos serviços core está mais lenta e as ofertas de IA estão muito atrás dos concorrentes. A equipe da AWS sempre argumenta para não fazer multicloud por causa da estabilidade extrema da AWS. Estou ansioso por essa reunião.
  • AWS, Cloudflare, Google Cloud, Akismet e outras plataformas sofrem pane de vez em quando. Cada vez que isso acontece, a gente até pensa em migrar para hospedagem interna. No fim das contas, acaba voltando a operar novamente. O resultado costuma ser parecido, então não parece valer a pena se estressar mais do que o necessário.
  • No último release da AWS, quando criticaram o Andy Jassy por dizer que a AWS ficou para trás em inovação, ele destacou estabilidade, confiabilidade e durabilidade. Mas o que estamos vendo agora não sustenta essa justificativa.
  • Fora o us-east-1, as outras regiões parecem bastante estáveis. A nossa empresa também está quase toda no eu-west-1, e está rodando sem problemas.
  • A AWS está em declínio no longo prazo. Hoje parece que só está mantendo os serviços existentes. Os talentos inovadores estão sendo esmagados pela burocracia interna e pela pressão por desempenho, e isso também os deixa para trás em IA.
  • A tese de que a AWS tinha extrema estabilidade não era verdadeira desde o início. Antes, montei uma monitoria multicloud com várias clouds e servidores dedicados, e dava para ver claramente qual cai primeiro quando dá problema. Os resultados mostraram que a AWS não era sempre #1. Isso bateu quase exatamente com os dados da netcraft.com.
  • Hoje a Premier League terá VAR e o sistema de impedimento automático operando de forma limitada por causa da pane da AWS. Estamos vivendo uma era realmente estranha. link da BBC
  • É curioso ver que até em “nuvem (pane)” existe um aspecto positivo
• Se você usa us-east-1 como região principal, quando há pane ninguém fica de fora da indisponibilidade. As outras regiões dos EUA não oferecem esse “privilégio”.
  • Uma das vantagens inesperadas de migrar do data center próprio para AWS é que, quando uma região inteira cai, os clientes ficam bem mais compreensivos. Como todo mundo sente o impacto ao mesmo tempo, a reação tende a ser de aceitação.
  • Às vezes, todo mundo precisa passar por uma vez por downtime técnico.
  • Ok, vamos subir a infraestrutura de todos em US-East-1.
  • Perceber o que realmente importa em ambiente corporativo demora. Na prática, o que pesa mais não é disponibilidade, e sim uma arquitetura em que sempre dê para culpar alguém. Um erro humano que derruba cinco minutos vira responsabilidade do CTO; uma pane de cinco horas na AWS é “impossível evitar”, porque todo mundo sofre com isso. AWS, Crowdstrike e companhia não vencem por estabilidade, custo-benefício ou gestão de risco no fim das contas — vencem quando é a fase em que todo mundo sofre junto. É inconveniente, mas é a realidade. Quem gosta de tecnologia funcionando bem fica puto.
  • A região de Tóquio está bem agora! Só algumas funções, como login no console, ainda têm problemas.
• Houve um anúncio dizendo: “A investigação indica que há relação com um problema de resolução de DNS do endpoint da API do DynamoDB em us-east-1. Estamos trabalhando em paralelo para acelerar a recuperação”. De novo, a causa termina em DNS.
  • Fico curioso se esta pane é realmente problema de resolução de DNS, ou de configuração interna/armazenamento de dados do servidor DNS. Suspeito que seja o segundo.
  • Mais tarde, o comunicado do incidente fala que a causa foi falha do Network Load Balancer. DNS é um sintoma da causa raiz. DNS pode ter prejudicado os health checks, mas, para mim, a causa raiz parece de rede.
  • O BGP pode ser um DNS mascarado.
  • A causa é sempre us-east-1.
  • Mesmo que não seja DNS, no fim é DNS.
• A resiliência, como projetada, funcionou. Tínhamos originários de site estático em múltiplas regiões no CloudFront e essa pane não teve impacto. O control plane também é uma arquitetura nativamente multi-região; apesar de depender de vários serviços, manteve disponibilidade. Cada região opera de forma independente, e a replicação de dados segue, sem impacto se a replicação para o us-east-1 falhar. O serviço em si já é multi-região e faz failover em várias camadas (DNS, roteamento, seleção de destino). Claro que essa abordagem não é perfeita e tem muitos fatores de falha, mas dessa vez funcionou e fico satisfeito. O que fiz não é engenharia de foguete nem caro, mas é uma forma menos convencional. Se houver dúvidas, perguntem sem problema.
  • Ter CloudFront com origens estáticas multi-região para evitar essa falha deveria ser padrão em 2025, e ainda hoje isso ainda é considerado digno de elogio.
  • Fiquei curioso para saber se é active/active, e como está o seu data stack. Acho essa parte especialmente difícil.
  • Queria saber como vocês implementaram a resiliência para chaves e certificados.
• Um grande problema foi que IAM/autenticação ficou sobrecarregado ou indisponível e gerou falha em cadeia. Ouvi dizer que o DynamoDB foi a causa, mas fiquei curioso se o IAM também depende internamente de Dynamo. Em sistemas em escala grande, as dependências se enroscam, e IAM/Autenticação é um ponto único global perigoso. Queremos reduzir dependências, mas escalabilidade e consistência contam, então acabamos usando bancos de dados estabelecidos. Isso me faz pensar que, quando o sistema cai, acabamos tendo que passar por bootstrap complexo. Quero saber como vocês lidam com isso.
  • Houve uma grande pane com DynamoDB por volta de 2017. O EC2 guardava a lista de servidores no DynamoDB; como ele caiu, o EC2 também caiu. Como DynamoDB rodava sobre EC2, recuperar também parecia impossível — não dava para subir novas instâncias para restaurar. Então foi necessário restaurar manualmente por alguns dias. Depois disso venho me esforçando para separar o máximo possível as dependências entre sistemas de 1º nível como S3, DynamoDB e EC2. Claro que não dá para ser perfeito.
  • Muitos clientes da AWS, por política de retry mal configurada, acabam sobrecarregando o outro sistema quando um já está caído. A pane do DynamoDB sobrecarregou até o IAM.
  • Internamente na Amazon existe uma plataforma de armazenamento KV chamada Dynamo separada do DynamoDB. Então a causa pode ser também roteamento DNS ou implantação de nós. Esse tipo de questão aparece repetidamente em postmortems de grandes panes.
  • Quando eu trabalhava na AWS, IAM não dependia de Dynamo. Não sei se isso mudou, não tenho certeza. Mas para mim, o mais provável é impacto de um problema de rede de grande escala. IAM não deve virar um único ponto global, por isso se tenta reduzir dependências. O IAM tem cache somente leitura por região, e o AWS SigV4 foi projetado considerando operação por região. (documentação de referência)
  • O interessante é que o incidente recente da GCP também parece ter essa origem.
• Às 3:03 AM PT, a AWS anunciou que a recuperação estava em andamento. Em seguida, a situação pareceu piorar. Às 9:13 AM PT, novamente disseram que estavam analisando a causa. Isso traz incerteza, porque dá a impressão de que a AWS também não sabe exatamente o que aconteceu.
  • Esta ocorrência também parece ter sido afetada por cair na semana do Diwali, quando engenheiros na Índia costumam estar de férias. Foi um azar incrível.