A Amazon Web Services↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → informou que não consegue restaurar o acesso à sua instalação de nuvem no Bahrein e a uma das três zonas de hospedagem de dados nos Emirados Árabes Unidos, após danos sofridos durante a guerra com o Irã. A informação está em uma atualização de status da AWS vista pela Reuters e reportada pelo ET Tech.
Segundo a própria AWS, o estrago foi além do que a arquitetura da nuvem foi desenhada para absorver: "O dano à nossa infraestrutura abrangeu múltiplas Availability Zones e excedeu o que nossos serviços regionais e multi-AZ foram projetados para suportar", diz o comunicado. A empresa afirmou ter apoiado clientes do Bahrein a reestabelecer operações em outras regiões.
O caso é raro porque expõe, na prática, o limite de um modelo de resiliência que a indústria trata quase como garantia: o de que espalhar cargas entre Availability Zones de uma mesma região é suficiente para sobreviver a falhas. Aqui, o evento derrubou várias AZs de uma vez, algo que o desenho padrão não prevê.
O que é uma Availability Zone (e por que isso importa)
Uma região da AWS é uma área geográfica; dentro dela ficam as Availability Zones (AZs), que são clusters de um ou mais data centers fisicamente separados, com energia e rede independentes. A promessa comercial é justamente essa: se uma AZ cair, sua aplicação continua rodando nas outras da mesma região, sem você precisar sair dali.
Toda a documentação de boas práticas de alta disponibilidade da AWS gira em torno disso. Bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → como RDS Multi-AZ, balanceadores, Auto Scaling Groups: o padrão recomendado é distribuir réplicas e instâncias entre pelo menos duas ou três AZs. É o alicerce de quase todo desenho de tolerância a falhas feito sobre a nuvem da Amazon.
O comunicado do Bahrein quebra exatamente essa premissa. Quando o dano "abrange múltiplas AZs" e "excede" o que os serviços multi-AZ suportam, a rede de segurança projetada dentro da região deixa de funcionar. Quem confiou só na redundância intra-região ficou sem plano B automático.
O buraco que fica no plano de disaster recovery
Há uma distinção que muita equipe de infra trata como detalhe e que este episódio joga para o centro: alta disponibilidade (HA) dentro de uma região não é o mesmo que disaster recovery (DR) entre regiões.
- Multi-AZ protege contra falha de um data center: um transformador que pega fogo, uma AZ que perde energia, uma pane isolada.
- Multi-região protege contra a perda da região inteira: desastre natural, conflito armado, falha de larga escala que atinge vários data centers ao mesmo tempo.
O Bahrein é o cenário em que só multi-AZ não basta. Quem tinha DR configurado para outra região conseguiu migrar; quem apostou que "multi-AZ é redundância suficiente" descobriu, no pior momento, que não era. A própria AWS confirma que o caminho de recuperação foi mover clientes para outras regiões, ou seja, a solução dependeu de arquitetura multi-região que nem todos têm pronta.
Vale lembrar a diferença entre os conceitos que aparecem em qualquer plano de DR:
- RTO (Recovery Time Objective): quanto tempo você tolera ficar fora do ar.
- RPO (Recovery Point Objective): quanto dado você tolera perder desde o último backup replicado.
Se seus backups e réplicas vivem todos na mesma região que caiu, tanto o RTO quanto o RPO viram números teóricos, porque a cópia de segurança sumiu junto com o primário.
O que muda para quem constrói software no Brasil
A maior parte das cargas brasileiras roda em sa-east-1 (São Paulo), que por muito tempo foi região de AZ única no início e cresceu para múltiplas AZs. O reflexo direto é a pergunta desconfortável: se sua stack inteira mora só em sa-east-1, o que acontece se a região sair do ar por completo?
O episódio no Golfo tem causa geopolítica improvável por aqui, mas a lição de arquitetura é agnóstica ao motivo. Uma falha regional em cascata, seja por desastre físico, seja por erro operacional em larga escala, produz o mesmo efeito prático para quem não tem saída para outra região.
Alguns pontos que valem revisão para quem toca infra no país:
- Mapear a real dependência de região. Muitos times acham que estão "multi-AZ" e não fizeram nenhuma provisão para operar fora de sa-east-1.
- Onde estão os backups de verdade. Snapshots de RDS, objetos em S3 e imagens de máquina precisam ter cópia replicada para outra região se a exigência de continuidade for alta. S3 tem replicação cross-region; RDS permite réplicas de leitura em outra região.
- Latência x continuidade. Sair de São Paulo pode significar cair para us-east-1 (Norte da Virgínia) e absorver latência maior para o usuário brasileiro. É um trade-off consciente, não um detalhe técnico.
- Custo do DR ocioso. Multi-região custa: infraestrutura de espera, tráfego entre regiões, replicação de dados. O episódio ajuda a justificar esse gasto para cargas que não podem parar.
- Testar o failover de verdade. Plano de DR que nunca foi exercitado é documento, não garantia. A hora de descobrir que o runbook está desatualizado não é durante o incidente.
O que continua em aberto
A atualização de status não detalha quanto tempo os clientes ficaram sem acesso, quantos foram afetados nem se há previsão de reconstrução física das instalações no Bahrein. Também não há, no material, número de cargas perdidas ou impacto financeiro.
O que fica claro é o recado técnico: o modelo de "múltiplas AZs numa região" resolve a esmagadora maioria das falhas do dia a dia, mas tem um teto. Eventos que ultrapassam esse teto existem e, quando acontecem, só quem investiu em redundância entre regiões continua de pé. Para quem projeta sistemas críticos, a distinção entre HA e DR deixa de ser tópico de prova de certificação e vira decisão de arquitetura com consequência real.
Fonte: ET Tech (Índia)
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
Comentários
Ninguém comentou ainda. Começa a conversa?