Falha reportada na AWS em junho expõe risco de depender de uma única região

Falha reportada na AWS em junho expõe risco de depender de uma única região

Reclamações no Downdetector sobre EC2, S3, Lambda, RDS e CloudFront levaram a AWS a negar instabilidade no Brasil e a apontar problema só no Oriente Médio. O episódio de junho serve de lembrete sobre desenhar para resistir à perda de uma região inteira.

Nota da redação: este texto contém duas afirmações que não puderam ser confirmadas em fontes públicas no momento da checagem. Primeiro, a alegação de que a AWS não forneceu detalhamento adicional sobre o incidente nos cinco meses seguintes se baseia na ausência de cobertura posterior encontrada, não em uma busca exaustiva por eventual atualização da empresa; o leitor deve considerar essa lacuna como não confirmada, não como fato estabelecido. Segundo, as descrições técnicas de produtos da AWS (Multi-AZ, Aurora Global Database, DynamoDB Global Tables, S3 CRR, Route 53 failover) refletem o funcionamento geral e publicamente conhecido desses serviços, mas não foram cotejadas com documentação oficial da AWS nesta apuração.

O que foi relatado na sexta-feira 12 de junho

Na manhã de sexta-feira, 12 de junho de 2026, o Downdetector registrou um pico de reclamações de usuários sobre serviços da AWS. Os mais citados foram EC2, S3, Lambda, RDS e CloudFront, segundo reportagem da Exame baseada nos registros do site.

Procurada pela imprensa, a AWS negou qualquer instabilidade naquela manhã. Em nota, a empresa afirmou:

A única instabilidade é na região do Oriente Médio em razão da guerra, sem qualquer impacto no Brasil.

Nota da Amazon Web Services à imprensa

Passados cinco meses desse episódio (de 12 de junho a 13 de novembro de 2026), a AWS não forneceu publicamente nenhum detalhamento adicional sobre o que ocorreu naquela região, nem quanto tempo durou o problema, além da nota dada à imprensa no próprio dia. É esse hiato de informação, não o incidente em si, que interessa a quem opera carga de produção na nuvem.

Downdetector mede reclamação, não causa

O Downdetector agrega relatos espontâneos de usuários, sem acesso a telemetria interna de nenhum provedor. Um pico de reclamações pode significar falha real, mas também pode refletir um problema isolado em algum ISP, um app específico com bug, ou simplesmente mais gente comentando porque viu outra pessoa comentar.

Para quem arquiteta e opera ambiente AWS, esse detalhe importa na hora de decidir se aciona um runbook de incidente. Tratar Downdetector como fonte de verdade operacional é o tipo de erro que gera pânico desnecessário, ou pior, mascara um problema real que está em outro lugar da própria aplicação.

A fonte correta de status é o AWS Health Dashboard (status.aws.amazon.com) e o AWS Health API, mecanismos oficiais da AWS para acompanhar o status dos serviços, diferentemente de agregadores como o Downdetector, que dependem de relatos de terceiros.

Por que Oriente Médio, e qual região exatamente

A nota da AWS não especificou qual região do Oriente Médio foi afetada, nem detalhou se o problema atingiu um data center específico, conectividade de rede ou outro ponto da infraestrutura. A atribuição do problema à guerra na região sugere algo na infraestrutura física ou de conectividade, mas sem mais detalhes públicos da empresa não dá para cravar causa técnica.

O ponto prático para quem está no Brasil: nenhuma região do Oriente Médio hospeda carga de produção típica de empresa brasileira. A confusão da manhã de 12 de junho veio do fato de que reclamações no Downdetector não distinguem região de origem do usuário da região afetada no backend.

O que o pilar de Reliability cobra na prática

O Well-Architected Framework trata a resiliência a falha de região como um nível acima da resiliência a falha de zona de disponibilidade (AZ). Multi-AZ, hoje padrão em RDS, ElastiCache e grupos de Auto Scaling, protege contra a perda de um data center. Não protege contra um evento que tire do ar uma região inteira.

Para quem desenha workloads críticos, entre os recursos de desenho multi-região mais conhecidos da AWS estão:

• Aurora Global Database: recurso para manter réplica do banco em uma segunda região.
• DynamoDB Global Tables: recurso de replicação de tabelas entre regiões.
• S3 Cross-Region Replication (CRR): recurso para replicar objetos de um bucket para outra região.
• Route 53 com health checks e failover routing: recurso de roteamento de DNS que considera a saúde dos endpoints na decisão de para onde enviar tráfego.

Cada uma dessas peças tem custo de operação e de banda, e nem todo workload justifica o investimento. O próprio Well-Architected recomenda calcular RTO (tempo de recuperação) e RPO (perda de dado tolerável) antes de escolher entre as estratégias clássicas de disaster recovery: backup e restore, pilot light, warm standby ou multi-site ativo-ativo.

Runbook mínimo para quando parece que a AWS caiu

Quando um alerta externo (rede social, Downdetector, cliente reclamando) sugere problema na AWS, antes de declarar incidente vale seguir uma sequência curta:

1. Checar o AWS Health Dashboard público para a região onde sua conta opera.
2. Consultar o Personal Health Dashboard da própria conta via console ou AWS Health API.
3. Olhar os alarmes do CloudWatch já configurados na própria arquitetura, que medem o que importa para a sua aplicação, não para o setor inteiro.
4. Só então decidir se há motivo para acionar failover para região secundária, caso ela exista.

Esse fluxo evita dois erros simétricos: ignorar um incidente real porque ele não apareceu em nenhuma rede social, ou acionar failover caro por causa de um boato.

O que fica em aberto

A nota da AWS dada à imprensa não precisou duração nem escopo exato do problema na região do Oriente Médio, e a empresa não forneceu detalhamento adicional sobre o caso até a publicação deste texto. Para quem opera na sa-east-1 (São Paulo), o caso serve menos como alerta de falha concreta e mais como exercício: se a confusão daquela manhã tivesse sido sobre a região de São Paulo, qual seria o plano?

Fonte: Exame