# AWS us-east-1 (2025): Evento Térmico em Datacenter Derruba EC2 e EBS Uma falha no sistema de refrigeração de um datacenter em us-east-1 causou superaquecimento de servidores, acionando desligamentos de proteção térmica que degradaram EC2 e EBS na região. O incidente reacende debates críticos sobre concentração de workloads em us-east-1, o papel do isolamento físico por AZ e a necessidade de graceful degradation em arquiteturas de produção. - URL: https://fernando.moretes.com/studies/aws-us-east-1-thermal-2026 - Markdown: https://fernando.moretes.com/studies/aws-us-east-1-thermal-2026/study.md?lang=pt - Type: Post-mortem - Company: AWS - Domain: Resiliência - Date: 2026-06-20 - Tags: aws, us-east-1, resiliencia, ec2, ebs, postmortem, thermal-event, multi-region - Reading time: 10 min --- ## Ficha do Incidente - **Provedor:** Amazon Web Services (AWS) - **Região afetada:** us-east-1 (Norte da Virgínia) - **Data do incidente:** Janeiro de 2025 - **Serviços impactados:** Amazon EC2, Amazon EBS, serviços dependentes (RDS, ECS, Lambda em alguns casos) - **Causa raiz:** Falha no sistema de refrigeração de um datacenter físico dentro de uma AZ de us-east-1 - **Mecanismo de falha:** Superaquecimento de hosts físicos → desligamento de proteção térmica → perda de capacidade de compute e storage - **Blast radius:** Subconjunto de instâncias EC2 e volumes EBS em AZ(s) afetada(s); impacto em cascata para serviços gerenciados dependentes - **Perfil de risco amplificado:** us-east-1 concentra a maior densidade de workloads AWS globalmente Refrigeração não é glamour de arquitetura — mas é disponibilidade. Quando o sistema de resfriamento de um datacenter em us-east-1 falhou em janeiro de 2025, servidores físicos atingiram limiares térmicos críticos e desligaram automaticamente para se proteger. O resultado foi degradação de EC2 e EBS em escala regional, afetando uma das regiões com maior concentração de workloads críticos do planeta. Este post-mortem analisa o que aconteceu, por que a infraestrutura física ainda é o limite inferior de toda abstração de nuvem, e o que arquiteturas resilientes precisam incorporar para sobreviver a eventos que nenhum SLA de software consegue mitigar. ## O que aconteceu: da falha física ao impacto em produção Em janeiro de 2025, um evento térmico em um datacenter físico dentro da região us-east-1 da AWS provocou uma das interrupções mais discutidas do ano no setor. A causa imediata foi uma falha no sistema de refrigeração — HVAC ou infraestrutura de cooling equivalente — que resultou em elevação anormal de temperatura no interior do datacenter afetado. Hosts físicos que executavam instâncias EC2 e serviam volumes EBS atingiram limiares de temperatura que acionaram mecanismos automáticos de proteção térmica: os servidores simplesmente se desligaram para evitar danos permanentes ao hardware. Esse tipo de falha tem uma característica particularmente brutal do ponto de vista operacional: ela não é gradual. Um servidor que desliga por proteção térmica não degrada suavemente — ele para. Instâncias EC2 em execução nesses hosts foram abruptamente terminadas. Volumes EBS cujos dados residiam em storage nodes afetados tornaram-se inacessíveis. A propagação foi imediata para qualquer serviço que dependia dessas instâncias ou volumes: bancos de dados RDS com instâncias primárias nos hosts afetados iniciaram failover (quando configurados com Multi-AZ), clusters ECS perderam tasks, pipelines de dados pararam. A AWS confirmou o incidente via AWS Health Dashboard, descrevendo degradação de EC2 e EBS em us-east-1. O escopo exato — quantas AZs foram afetadas, qual a densidade de hosts impactados — não foi divulgado com granularidade total, o que é padrão para comunicações de incidente da AWS. O que ficou claro pelo relato do Network World e pela comunicação pública foi que o evento foi físico, não lógico: não havia patch de software, rollback de configuração ou roteamento alternativo que pudesse ter prevenido o impacto nos hosts que superaqueceram. ## Linha do Tempo do Incidente 1. **T-0: Falha de refrigeração** — O sistema de refrigeração de um datacenter físico em us-east-1 falha. Temperatura interna começa a subir acima dos limiares operacionais seguros. 2. **T+minutos: Proteção térmica ativada** — Hosts físicos atingem limiares de temperatura crítica. Mecanismos de proteção térmica automáticos desligam servidores para evitar danos permanentes ao hardware. Instâncias EC2 são terminadas abruptamente; volumes EBS ficam inacessíveis. 3. **T+minutos a horas: Propagação em cascata** — Serviços dependentes começam a falhar: RDS inicia failover Multi-AZ onde configurado; ECS e outros orquestradores tentam realocar tasks; aplicações single-AZ ficam completamente indisponíveis. Alarmes disparam em massa nos sistemas de monitoramento dos clientes. 4. **T+horas: AWS confirma incidente** — AWS publica atualização no AWS Health Dashboard confirmando degradação de EC2 e EBS em us-east-1 e indicando investigação ativa. Equipes de engenharia da AWS trabalham para restaurar refrigeração e avaliar hosts afetados. 5. **T+horas a dias: Recuperação gradual** — À medida que a refrigeração é restaurada e hosts são verificados, a AWS começa a trazer capacidade de volta online. Instâncias e volumes que sobreviveram ao desligamento são restaurados; hosts com danos físicos requerem substituição de hardware. 6. **Pós-incidente: Comunicação e revisão** — AWS publica atualizações finais no Health Dashboard. Discussão pública intensa sobre concentração de risco em us-east-1 e práticas de resiliência multi-AZ e multi-region. ## Fluxo de Falha: Evento Térmico em us-east-1 O diagrama reconstrói como a falha física de refrigeração em um datacenter propagou-se pela stack de abstrações da AWS até atingir workloads de clientes. A falha começa na camada física (HVAC), atravessa o host hypervisor, e impacta EC2 e EBS, que por sua vez degradam serviços gerenciados dependentes. ### 🏭 Datacenter Físico — AZ Afetada / Affected AZ - HVAC / Cooling [FALHOU / FAILED] (network) - Host Físico A [Superaquecido / Overheated] (compute) - Host Físico B [Superaquecido / Overheated] (compute) - Storage Node EBS [Inacessível / Inaccessible] (storage) ### ☁️ Camada de Virtualização AWS / AWS Virtualization Layer - EC2 Instances [Terminadas / Terminated] (compute) - EBS Volumes [Degradados / Degraded] (storage) ### 🗄️ Serviços Gerenciados / Managed Services - Amazon RDS [Failover iniciado / Failover initiated] (data) - Amazon ECS [Tasks perdidas / Tasks lost] (compute) - AWS Lambda [Degradação parcial / Partial degradation] (compute) ### 👤 Workloads de Clientes / Customer Workloads - App Single-AZ [Indisponível / Unavailable] (frontend) - App Multi-AZ [Degradada / Degraded] (frontend) - App Multi-Region [Sobreviveu / Survived] (frontend) ### Fluxos - hvac -> host1: Temperatura crítica - hvac -> host2: Temperatura crítica - hvac -> storage_node: Temperatura crítica - host1 -> ec2: Desligamento térmico - host2 -> ec2: Desligamento térmico - storage_node -> ebs: Inacessível - ec2 -> rds: Instância primária perdida - ec2 -> ecs: Tasks terminadas - ebs -> rds: Storage inacessível - rds -> single_az_app: DB indisponível - ecs -> single_az_app: Sem compute - rds -> multi_az_app: Failover Multi-AZ - ec2 -> multi_az_app: AZ saudável assume - ec2 -> multi_region_app: Tráfego desviado > **Causa Raiz: Infraestrutura Física é o Limite Inferior de Toda Abstração:** A causa raiz deste incidente não foi um bug de software, uma misconfiguration de rede ou um erro de deploy. Foi a falha de um sistema físico de refrigeração — HVAC — que resultou em superaquecimento de hardware real. Isso expõe uma verdade fundamental que abstrações de nuvem tendem a obscurecer: toda instância EC2 executa em um servidor físico, em um rack físico, em um datacenter físico, com sistemas de energia e refrigeração físicos. Quando esses sistemas falham de forma suficientemente severa, nenhuma camada de software pode compensar. A proteção térmica automática dos hosts é um mecanismo de segurança correto — ela previne perda permanente de hardware — mas seu efeito colateral é indistinguível de uma falha catastrófica para os workloads em execução. O isolamento de AZ existe exatamente para conter esse tipo de blast radius físico, mas ele só protege arquiteturas que efetivamente distribuem carga entre AZs. ## Blast Radius: por que us-east-1 dói mais us-east-1 não é apenas mais uma região AWS. É historicamente a primeira região da AWS, a mais antiga, a que tem a maior densidade de serviços disponíveis e, consequentemente, a que concentra a maior proporção de workloads críticos globalmente. Muitas organizações escolheram us-east-1 por padrão — porque era a única opção quando começaram, porque seus times conhecem melhor, porque certos serviços só estavam disponíveis lá por anos. O resultado é uma concentração de risco que amplifica o impacto de qualquer evento nessa região. Quando um evento térmico ocorre em us-east-1, o blast radius não é apenas técnico — é de negócio. Empresas que nunca pensaram seriamente em multi-region porque "a AWS nunca cai" descobrem que a AWS cai, e que cai exatamente na região onde colocaram tudo. A ironia é que us-east-1 também é historicamente a região com mais incidentes documentados — não necessariamente porque seja menos confiável por design, mas porque tem mais workloads, mais tráfego, mais pressão operacional, e mais visibilidade quando algo falha. Do ponto de vista de blast radius físico, o modelo de AZ da AWS é teoricamente correto: cada AZ é um ou mais datacenters fisicamente separados, com energia e rede independentes. Um evento térmico em um datacenter específico deveria, em teoria, ser contido dentro daquela AZ. O problema é duplo: primeiro, nem todas as arquiteturas de clientes distribuem carga entre AZs de forma genuinamente resiliente — muitas têm dependências implícitas em uma única AZ (volumes EBS não são replicados entre AZs por padrão, por exemplo). Segundo, mesmo com Multi-AZ configurado, o failover tem latência e pode introduzir janelas de indisponibilidade que violam SLOs de aplicações sensíveis a latência. ## Remediação e o que arquiteturas resilientes precisam incorporar A remediação imediata do incidente foi responsabilidade da AWS: restaurar o sistema de refrigeração, verificar a integridade dos hosts afetados, substituir hardware danificado, e trazer capacidade de volta online de forma controlada. Esse processo leva horas a dias dependendo da extensão do dano físico — e não há atalho. Hardware que superaqueceu precisa ser inspecionado antes de ser recolocado em produção. Mas a remediação arquitetural — o trabalho que cabe aos times de engenharia dos clientes — é mais interessante e mais durável. Ela começa com uma pergunta honesta: o que acontece com meu sistema se uma AZ inteira ficar indisponível por 4 horas? Se a resposta for "meu sistema fica completamente indisponível", a arquitetura tem um risco de concentração que precisa ser endereçado. As práticas que efetivamente limitam o blast radius de eventos como este são conhecidas, mas frequentemente subestimadas em implementação: **Distribuição genuína entre AZs**: Não basta ter instâncias em múltiplas AZs se o banco de dados primário, a fila de mensagens ou o cache estão em uma única AZ. A resiliência precisa ser end-to-end. Auto Scaling Groups devem ter `balance across AZs` habilitado. RDS Multi-AZ deve ser padrão para qualquer banco de dados de produção. **EBS e o problema de afinidade de AZ**: Volumes EBS são recursos zonais — eles existem em uma AZ específica e não podem ser acessados de outra. Isso significa que qualquer instância EC2 que depende de um volume EBS tem uma dependência implícita na AZ onde esse volume existe. Para dados que precisam sobreviver a falhas de AZ, as opções são: replicação de dados na camada de aplicação, uso de EFS (que é regional e multi-AZ), ou migração para serviços de storage gerenciados que abstraem a replicação. **Graceful degradation**: Sistemas que não conseguem degradar graciosamente transformam falhas parciais em falhas totais. Circuit breakers, fallbacks para dados em cache, filas de mensagens para absorver picos durante recuperação — esses padrões fazem a diferença entre "degradado mas funcional" e "completamente indisponível". **Multi-region como estratégia, não como luxo**: Para workloads com SLOs de disponibilidade acima de 99,9%, single-region — especialmente single-region em us-east-1 — não é uma estratégia defensável. Multi-region com Route 53 failover, Global Accelerator, ou active-active com replicação de dados é o caminho correto. O custo é real, mas precisa ser comparado ao custo de uma indisponibilidade de horas em produção. **Chaos engineering e game days**: Nenhuma arquitetura multi-AZ ou multi-region que nunca foi testada sob falha real pode ser considerada validada. Injeção de falhas de AZ em ambiente de staging, game days simulando perda de região — esses exercícios revelam dependências ocultas que documentos de arquitetura não capturam. ## Lições do Incidente - **Refrigeração é disponibilidade**: Sistemas de HVAC e cooling são dependências de disponibilidade de primeira classe. Falhas físicas de infraestrutura não são mitigáveis por software — elas definem o limite inferior de qualquer SLA de nuvem. - **us-east-1 é risco de concentração**: A maior região AWS em densidade de workloads é também a que amplifica o impacto de qualquer incidente. Single-region em us-east-1 não é estratégia defensável para SLOs acima de 99,9%. - **AZ isolation só funciona se a arquitetura respeita os limites de AZ**: Volumes EBS são zonais. Instâncias EC2 são zonais. Dependências implícitas em uma única AZ anulam o benefício do modelo multi-AZ. - **Graceful degradation é design, não otimização**: Sistemas que não têm fallbacks, circuit breakers e filas de absorção transformam falhas parciais em indisponibilidades totais. Isso é uma escolha de design, não um acidente. - **Failover Multi-AZ tem latência — e isso importa**: RDS Multi-AZ failover leva tipicamente 60-120 segundos. Para aplicações que não toleram essa janela, a arquitetura precisa de mecanismos adicionais de resiliência na camada de aplicação. - **Chaos engineering valida o que documentos não capturam**: Dependências ocultas de AZ só aparecem sob falha real. Game days e injeção de falhas em staging são investimentos de confiabilidade, não overhead de processo. > **Minha Perspectiva: O Que Eu Faria Diferente:** Trabalho com sistemas de alta disponibilidade há mais de 16 anos, incluindo infraestrutura financeira onde indisponibilidade de minutos tem custo mensurável em regulação e receita. Esse incidente não me surpreende — surpreende apenas quem nunca levou a sério a frase 'a nuvem é o computador de outra pessoa'. Minha posição é direta: qualquer workload com SLO acima de 99,5% que roda single-region em us-east-1 em 2025 tem um débito arquitetural que precisa ser endereçado, não postergado. O custo de multi-region ativo-passivo com Route 53 failover é uma fração do custo de uma indisponibilidade de 4 horas em produção para a maioria dos negócios digitais. Mas o que me incomoda mais nesse incidente não é a falha da AWS — datacenters físicos falham, e a AWS tem um track record razoável de contenção. O que me incomoda é o padrão recorrente de arquiteturas que tratam a nuvem como se fosse infinitamente resiliente por design. EBS sendo usado como storage primário sem replicação em workloads críticos. RDS sem Multi-AZ em produção. Auto Scaling Groups ancorados em uma única AZ por conveniência de configuração. Se eu estivesse revisando a arquitetura de um cliente após esse incidente, minha primeira pergunta seria: 'mostre-me o runbook de falha de AZ'. Se não existir, ou se existir mas nunca tiver sido testado, esse é o trabalho mais urgente — não a otimização de custo, não a nova feature, não o upgrade de versão. A resiliência precisa ser testada para ser real. E us-east-1, pela sua densidade histórica de workloads e incidentes, deveria ser tratada com o mesmo respeito que se dá a qualquer single point of failure — porque, para quem não diversificou, é exatamente isso que ela é. ## Veredicto: Física Não Abstrai O evento térmico em us-east-1 é um lembrete de que toda arquitetura de nuvem tem um substrato físico — e esse substrato pode falhar de formas que nenhuma camada de software pode compensar. A AWS fez o que era correto: os hosts desligaram para proteger o hardware, e a equipe trabalhou para restaurar o serviço. O modelo de AZ existe para conter exatamente esse tipo de blast radius físico. O problema não é a AWS. O problema é a concentração. us-east-1 concentra risco por razões históricas e operacionais que são compreensíveis, mas não são desculpa. Arquiteturas que não distribuem carga entre AZs de forma genuína, que não testam failover, que não têm graceful degradation — essas arquiteturas transformam um evento contível em uma indisponibilidade total. As lições são antigas e conhecidas: distribua entre AZs, teste failover, implemente graceful degradation, considere multi-region para SLOs elevados, e nunca trate a nuvem como se fosse imune a física. O que muda a cada incidente como este é o custo de não ter aprendido antes. Para times que levam resiliência a sério, esse incidente é um exercício de validação. Para os demais, é um alerta que deveria ser transformado em ação arquitetural concreta — antes do próximo evento térmico. ## Referências - [Network World — AWS hit by US-East-1 outage after data center thermal event](https://www.networkworld.com/article/4168878/aws-hit-by-us-east-1-outage-after-data-center-thermal-event.html) - [AWS Health Dashboard — Service Health History](https://health.aws.amazon.com/) - [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) - [AWS Documentation — Amazon EBS Availability and Durability](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) - [AWS Documentation — Multi-AZ deployments for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) - [AWS Blog — Building a Multi-Region Active-Active Backend](https://aws.amazon.com/blogs/architecture/building-a-multi-region-active-active-backend/) ## Fontes do caso - [Network World — AWS hit by US-East-1 outage after data center thermal event](https://www.networkworld.com/article/4168878/aws-hit-by-us-east-1-outage-after-data-center-thermal-event.html) - [AWS Health Dashboard](https://health.aws.amazon.com/)