A AWS publicou a análise do incidente que afetou a região N. Virginia, us-east-1, e a leitura é um lembrete direto sobre dependências internas em nuvem. A interrupção começou com um problema envolvendo endpoints do DynamoDB e resolução DNS, mas o efeito se espalhou para subsistemas que dependem do serviço para operar controles de EC2, Lambda, Network Load Balancer, STS, console, ECS, EKS, Fargate e Amazon Connect.1
O ponto mais importante do relatório é que a falha não ficou confinada ao serviço originalmente afetado. Em nuvem, APIs de controle, propagação de rede, health checks, autenticação e provisionamento formam uma malha. Quando uma peça central degrada, a recuperação pode depender de filas internas, leases expirados, throttling e reinicialização seletiva de componentes.
EC2 mostra a diferença entre instância rodando e controle plane
Segundo a AWS, instâncias EC2 existentes que haviam sido lançadas antes do evento permaneceram saudáveis. O impacto apareceu principalmente em APIs, latência e lançamento de novas instâncias. Essa distinção é crítica para arquitetura: workload já em execução pode continuar atendendo, enquanto autoscaling, substituição de nós, deploys e recuperação de falhas ficam comprometidos.
O relatório explica que um subsistema chamado DropletWorkflow Manager, responsável por gerenciar servidores físicos usados pelo EC2, dependia do DynamoDB para checagens de estado. Com as falhas, leases entre o DWFM e os droplets começaram a expirar. Quando as APIs do DynamoDB se recuperaram, o sistema precisou reconstruir leases em escala, mas entrou em colapso congestivo porque o volume de trabalho acumulado impedia progresso suficiente.
A resposta envolveu reduzir carga, aplicar throttling e reiniciar seletivamente hosts do DWFM. Esse detalhe operacional é valioso: nem toda recuperação se resume a "serviço voltou". Às vezes, o retorno de uma dependência revela filas, estados expirados e subsistemas saturados que precisam ser estabilizados em ordem.
DNS, health checks e NLB ampliam o raio de impacto
A propagação de configuração de rede também sofreu atraso. Novas instâncias podiam ser criadas, mas não recebiam conectividade completa enquanto o Network Manager processava backlog de estado. Isso afetou Network Load Balancer e serviços que dependem dele. Health checks alternavam entre falha e sucesso, removendo e recolocando nós em DNS, o que reduziu capacidade efetiva em aplicações multi-AZ.
Lambda, ECS, EKS e Fargate também registraram erros, atrasos de escala ou falhas de criação de recursos. STS teve aumento de erros e latência, e clientes enfrentaram problemas de login no console quando fluxos de autenticação dependiam de componentes afetados na região.
Para equipes de engenharia, a lição não é abandonar us-east-1 ou imaginar que multi-AZ resolve tudo. Multi-AZ protege contra classes importantes de falha, mas continua dentro de uma região e compartilha planos de controle. Sistemas críticos precisam discutir multi-região, degradação controlada, capacidade pré-aquecida, limites de dependência em autoscaling, filas tolerantes a atraso e runbooks para quando a criação de novos recursos não é confiável.
O relatório também reforça a importância de testar cenários em que o dado está disponível, mas o plano de controle não. Uma aplicação pode sobreviver com instâncias existentes, caches e filas. Ela sofre quando precisa escalar, trocar nós, renovar credenciais, consultar APIs administrativas ou depender de balanceadores recalculando saúde sob pressão. Resiliência em nuvem continua sendo engenharia de dependências, não apenas escolha de serviços gerenciados.