Interrupção da AWS e por que isso prova mais uma vez que a observabilidade full-stack é imprescindível

Nos dias 19 e 20 de outubro de 2025, o cenário digital, fortemente dependente da Amazon Web Services (AWS), sofreu uma grave interrupção devido a uma falha na região da AWS na Virgínia do Norte (us-east-1). O incidente, que começou por volta das 23h49 PDT em 19 de outubro e durou mais de 15 horas, impactou mais de 140 serviços da AWS. 

Neste blog, vamos explorar o que aconteceu, o impacto causado e o que podemos aprender com o incidente. 

O efeito dominó

Uma única falha de DNS no endpoint da API do DynamoDB na região us-east-1 desencadeou uma ruptura em cascata nesses serviços. Veja a seguir o relatório do incidente da AWS, detalhando a interrupção:

Muitos serviços internos da AWS dependem do DynamoDB para armazenar dados críticos, então a falha inicial do DNS desencadeou uma cascata de interrupções secundárias:

1. Problemas de inicialização do EC2: embora o problema de DNS tenha sido resolvido por volta das 2h24 PDT em 20 de outubro, um novo problema surgiu no subsistema interno do EC2 responsável por iniciar instâncias. A dependência desse sistema no DynamoDB causava erros ao tentar iniciar novas instâncias, muitas vezes resultando em erros de “Capacidade Insuficiente”.
2. Problemas de conectividade de rede: ao trabalhar no problema do EC2, a AWS descobriu que as verificações de integridade dos balanceadores de carga de rede estavam falhando. Isso levou a problemas generalizados de conectividade de rede em vários serviços, incluindo DynamoDB, SQS e Amazon Connect.
3. Esforços de mitigação e backlogs: para conter as falhas em cascata, a AWS limitou temporariamente certas operações, como novos lançamentos de instâncias de EC2, pesquisas do SQS por meio do Lambda Event Source Mappings e invocações assíncronas do Lambda. Embora isso tenha ajudado a estabilizar os serviços principais, criou atrasos em sistemas como AWS Config, Redshift e Amazon Connect, que levaram várias horas para serem totalmente processados, mesmo após a recuperação do serviço.

Esse evento com "efeito dominó" ilustra como as interdependências críticas dentro do ecossistema da AWS podem amplificar o impacto de uma única falha. Leia mais sobre isso no AWS Health Dashboard and Service Report.

O impacto nos negócios e por que a observabilidade é importante 

O impacto da interrupção foi generalizado, afetando os próprios serviços da AWS, como Alexa e Amazon.com, grandes clientes como Snapchat, Venmo da PayPal e Reddit, e até mesmo ferramentas essenciais, incluindo Docker e Zoom. Para clientes e organizações AWS desse tipo, que dependem muito de plataformas e serviços de nuvem, interrupções de várias horas distribuídas entre vários serviços da AWS causam um impacto significativo nos negócios.

A Previsão de Observabilidade de 2025 destaca o impressionante impacto financeiro das interrupções. Uma interrupção de aplicativo, plataforma ou até mesmo de uma oferta global de SaaS pode custar às organizações uma média de US$ 2,2 milhões por hora, ou aproximadamente US$ 33.333 por minuto. Embora ainda seja cedo para calcular números específicos para essa interrupção mais recente, com mais de 15 horas de duração, é seguro presumir que a perda foi significativa. 

O relatório de Previsão revela ainda que as organizações que utilizam a observabilidade full-stack (FSO) podem reduzir significativamente os custos de interrupção para US$ 1 milhão por hora, devido a maior resiliência e mitigação de riscos.

O impacto nos negócios não se resume apenas a dinheiro. Interrupções da AWS, principalmente aquelas que envolvem ações de limitação, representam um fardo significativo para as equipes de engenharia. Engenheiros de plantão, equipe de DevOps e SREs dedicaram aproximadamente 33% de seu tempo coletivo para resolver os problemas e incidentes resultantes, abordando diretamente essas interrupções de serviço.

É exatamente aqui que a observabilidade muda o paradigma:

• Detecção mais rápida: organizações que implementam ferramentas de observabilidade como a New Relic para sua observabilidade full-stack (FSO) alcançam uma detecção mais rápida de interrupções críticas. Em média, seu tempo médio de detecção (MTTD) é de 28 minutos, em comparação com 35 minutos para aqueles que não têm soluções de FSO.
• Respostas viabilizadas por IA e análise de causa-raiz automatizada: dada a complexidade inerente dos sistemas distribuídos modernos, operadores humanos muitas vezes se sentem sobrecarregados, tornando a inteligência artificial (IA) um recurso indispensável. Essa realidade se reflete entre executivos e líderes de TI, que identificam a resolução de problemas assistida por IA (38%) e a análise de causa-raiz automática (RCA) (33%) como recursos cruciais. Essas abordagens impulsionadas por IA são vistas como vitais para acelerar a resolução de incidentes e limitar significativamente as consequências de grandes eventos, como a cascata da AWS.
• Tracing de ponta a ponta: o distributed tracing é uma ferramenta crucial para prevenir e resolver interrupções, oferecendo uma maneira de rastrear solicitações de transação conforme elas se movem pelos serviços de back-end interconectados. Essa visibilidade de ponta a ponta é vital. Quando surge um problema em um serviço de back-end, como uma falha no banco de dados, o distributed tracing ajuda os engenheiros a identificar exatamente quais serviços estão degradando a experiência do cliente por meio de problemas como carregamento lento de páginas ou erros. Por sua vez, os engenheiros de back-end podem ver claramente como os problemas de infraestrutura estão impactando diretamente seus clientes.
• Correlação de alertas: ferramentas de observabilidade como a New Relic simplificam o gerenciamento de incidentes ao agrupar alertas relacionados de forma inteligente. Isso reduz o ruído e acelera a identificação da causa-raiz ao revelar padrões de correlação vinculados a cenários de incidentes específicos. Essa funcionalidade é essencial para navegar pelas complexidades de falhas de múltiplos componentes.

Validação da recuperação

Embora as ferramentas de observabilidade ajudem com o MTTD, também é importante identificar o tempo médio de resolução (MTTR), que seria um monitoramento ativo para confirmar se tudo voltou ao normal. 

Embora AWS Health Dashboards possam marcar tickets abertos como "resolvidos", os serviços frequentemente ainda enfrentam atrasos. Elas geralmente decorrem de elementos como filas SQS, processos em segundo plano que acionam funções Lambda ou outras dependências de terceiros. A observabilidade, portanto, fornece a evidência empírica crítica necessária para confirmar que a qualidade do serviço realmente retornou ao normal.

• Tempo de operação e confiabilidade confirmados: a observabilidade confirma que o aplicativo está atingindo sua principal meta de negócios: tempo de operação e confiabilidade do sistema.
• Monitoramento sintético: o monitoramento sintético permite que as equipes executem verificações contínuas para garantir que os endpoints do aplicativo estejam respondendo corretamente após a recuperação.
• Medindo o sucesso da resolução: práticas de observabilidade, como o monitoramento de métricas DORA e os sinais clássicos (latência, utilização, erros e saturação), são úteis para confirmar melhorias em MTTD e MTTR após esforços de recuperação e mudanças de procedimento.
• Rastreadores de alterações: esse recurso é essencial porque oferece suporte a recursos avançados de automação, como ações de correção assistidas por IA, como reversões ou atualizações de configuração.

A AWS está fora do ar... o que podemos fazer?

De acordo com o modelo de responsabilidade compartilhada, a AWS é responsável por resolver e restaurar a funcionalidade dos serviços para clientes que usam serviços da AWS. Mas o que nós, como clientes, podemos fazer proativamente para nos prepararmos para o próximo evento e mitigarmos os riscos? 

Nosso envolvimento vai além do mero monitoramento dos AWS Health Dashboards. Quando se trata de lidar com interrupções de serviço, não basta ter apenas uma estratégia de recuperação de desastres (disaster recovery, DR), uma configuração multirregional ou mesmo sistemas sofisticados de failover regionais em vigor. 

O primeiro passo mais crítico é obter visibilidade clara de quais serviços são realmente impactados durante um incidente. Essa conscientização fundamental deve vir antes que qualquer plano de recuperação possa ser executado de forma eficaz. Em ambientes de nuvem modernos, as arquiteturas são frequentemente construídas usando serviços da AWS como blocos de Lego interconectados. Essa complexidade é ampliada em microsserviços e sistemas distribuídos, onde os serviços da AWS são repetidamente aproveitados na arquitetura, criando uma rede de dependências que pode ser difícil de desatar durante uma interrupção. Sem visibilidade em tempo real, a identificação da causa-raiz e do escopo completo do impacto se torna um desafio significativo.

As ferramentas de observabilidade desempenham um papel fundamental na obtenção de visibilidade em tempo real:

• Identificar os serviços afetados do seu stack: o serviço da AWS afetado pode impactar todo o seu sistema/plataforma ou apenas um pequeno componente dele. A observabilidade fornece a clareza necessária para identificar quais serviços foram afetados, garantindo que você possa resolver problemas de forma eficiente.
• Monitorar sinais clássicos: monitore sinais clássicos dentro do ambiente de failover para garantir sua estabilidade e desempenho, validando assim a operação pretendida da estratégia de recuperação de desastres (DR).
• Quantificação da perda de receita: a observabilidade se estende aos resultados de negócios. O aplicativo New Relic Pathpoint permite que os clientes visualizem a jornada do cliente e quantifiquem o impacto financeiro das métricas de negócios, vendo a possível perda de receita para cada minuto do período de inatividade.
• Alertas e dashboards: aproveite sua visualização unificada de alertas para identificar rapidamente todos os serviços afetados por uma falha da AWS, informe imediatamente as equipes dependentes para estabelecer uma percepção abrangente da situação, e veja um dashboard centralizado para analisar a saúde e as métricas do aplicativo ou plataforma.

Utilizando a New Relic para detectar a interrupção

Na New Relic, usamos a AWS para nossos próprios workloads. Como a maior parte da nossa plataforma é executada fora da região us-east-1, nossas funcionalidades principais permaneceram praticamente inalteradas durante a interrupção da AWS no dia 20 de outubro. Isso significa que nossa ingestão de dados, armazenamento, consultas, alertas e a interface da New Relic estavam todos em funcionamento.

No entanto, alguns de nossos workloads foram afetados. Isso incluiu Synthetics, AWS Cloud Monitoring, Infinite Tracing, mobile symbolication e eventos relacionados ao consumo da New Relic (como NrConsumption e NRMTDConsumption). Os recursos Synthetics, Cloud Monitoring e Infinite Tracing foram projetados para serem executados em várias regiões, portanto, foram afetados apenas parcialmente. Em contrapartida, os eventos de mobile symbolication e consumo móvel têm uma dependência específica na us-east-1.

Como monitoramos ativamente a plataforma New Relic com a própria New Relic, detectamos o problema assim que ele começou. Às 11h57 PST, alertas foram acionados para um serviço que utiliza o DynamoDB em us-east-1, permitindo-nos identificar os erros recebidos imediatamente.

Ao recebermos os alertas, monitoramos ativamente os incidentes acionados para avaliar o impacto da interrupção. Apesar do impacto mínimo na plataforma New Relic, continuamos monitorando a situação para garantir que nossos clientes pudessem resolver quaisquer problemas relacionados.

Conclusão

Durante uma interrupção da AWS, você ainda não tem o conhecimento necessário para dizer com confiança: "Vamos implantar as correções!" Também não é o momento certo para reavaliar sua estratégia de recuperação de desastres ou avaliar a arquitetura em si, especialmente se você já estiver seguindo uma configuração multirregional, já que essa interrupção impactou especificamente a us-east-1. 

Em vez disso, o foco deve ser aproveitar ferramentas de observabilidade como a New Relic para dar sentido aos dados de telemetria (MELTX) e identificar rapidamente os serviços afetados. Essas ferramentas oferecem visibilidade full-stack de toda a sua arquitetura — desde aplicativos de frontend e APM até bancos de dados e infraestrutura. Isso inclui não apenas VMs, contêineres ou clusters do Kubernetes, mas também insights sobre o ambiente da AWS e a integridade do provedor de nuvem. 

Interrupções como essa podem causar transtornos significativos para as empresas. Como engenheiros, nossa prioridade número um é entender: o que não está funcionando, quais partes foram afetadas e até que ponto. Em momentos críticos como esses, ter uma estratégia abrangente de observabilidade é essencial para manter a conscientização e minimizar o impacto.