AWS não consegue recuperar dados perdidos em data centers do Oriente Médio após ataques

A Amazon Web Services informou aos clientes que não consegue recuperar dados e recursos hospedados exclusivamente em zonas de disponibilidade danificadas em suas regiões do Oriente Médio, após danos causados pelo conflito com o Irã. Em um comunicado de status divulgado esta semana sobre as regiões Middle East (UAE) me-central-1 e Middle East (Bahrain) me-south-1, a empresa afirmou que o dano em Bahrein superou o que seus serviços regionais e multi-AZ foram projetados para suportar.

O alcance dos danos

Para a zona de disponibilidade mec1-az2 nos Emirados Árabes Unidos, a AWS declarou:

"Após uma avaliação minuciosa, determinamos que não conseguimos restaurar o acesso aos recursos e dados hospedados exclusivamente na zona de disponibilidade mec1-az2. Continuamos trabalhando na recuperação de recursos regionais, bem como recursos zonais hospedados nas outras zonas de disponibilidade afetadas (mec1-az1 e mec1-az3)."

Para Bahrein, o escopo da avaliação cobriu toda a região:

"O dano à nossa infraestrutura abrangeu múltiplas zonas de disponibilidade e superou o que nossos serviços regionais e multi-AZ foram projetados para suportar. Após uma avaliação minuciosa, determinamos que não conseguimos restaurar o acesso aos recursos e dados hospedados exclusivamente nesta região."

A InfoQ reportou em março que ataques com drones iranianos danificaram três data centers da AWS nas duas regiões, com duas das três zonas de disponibilidade dos EAU significativamente comprometidas e uma instalação em Bahrein atingida. Na época, a AWS aconselhou clientes a replicar dados críticos para outras regiões e, logo depois, a migrar cargas de trabalho inteiramente para fora do Oriente Médio. O Corpo da Guarda Revolucionária Islâmica do Irã reivindicou um segundo ataque à região de Bahrein em julho.

A AWS afirma que está substituindo a infraestrutura afetada, notificou as autoridades relevantes e atualizará sobre a restauração do serviço nos próximos meses, com mais detalhes sobre Bahrein no início de 2027. Ela abriu a região de Bahrein em 2019 e a região dos EAU em 2022.

O debate sobre redundância e responsabilidade

As reações da comunidade no Hacker News focaram menos nos ataques do que no que os clientes entendiam estar comprando.

Uma entrevista televisiva de 2025 com um líder da AWS ressurgiu rapidamente. Quando perguntado o que aconteceria se alguém identificasse um data center AWS não marcado e o destruísse, e se o sistema era redundante o suficiente para que os clientes não notassem, ela respondeu:

"Yeah, you wouldn't notice. I mean, we might be a bit upset, but you wouldn't notice!" ("Sim, você não notaria. Quer dizer, talvez fiquemos um pouco chateados, mas você não notaria!")

O comentarista krick descreveu a posição em que isso deixa os clientes:

"Afirmações como essa são bastante comuns, fazem sentido e deveriam ser verdadeiras, então mesmo que eu não conheça realmente os detalhes do planejamento de redundância da AWS, costumava confiar nelas. É muito preocupante quando dizem abertamente que tudo ficará bem e, uma semana depois, descobrir que não ficou."

O comentarista houssc forneceu a ressalva ausente:

"A ressalva é sempre 'se você estiver usando o serviço corretamente', o que não é necessariamente gratuito. Significa aproveitar múltiplas zonas geográficas, criar redundância em sua stack, etc."

O comentarista jacquesm estendeu isso para o equívoco que vê com mais frequência: equipes acreditam que estão fazendo certo simplesmente porque usam AWS:

"Eles não percebem que AWS é uma caixa de ferramentas, não uma 'solução pronta para redundância contra todos os desastres a que você pode estar exposto'."

A documentação corrobora essa interpretação. S3 Standard e suas classes de armazenamento relacionadas armazenam objetos de forma redundante em um mínimo de três zonas de disponibilidade dentro de uma região, e a AWS afirma durabilidade de 99,999999999% por ano. Ambas são propriedades regionais. Comentaristas citaram orientações de recuperação de desastres da AWS mostrando que a empresa há muito tempo diz aos clientes para copiar backups para outra região, incluindo a linha de que todas as estratégias de DR exigem que as fontes de dados sejam copiadas dentro da região e depois transferidas para uma região de recuperação.

Onde a conversa se dividiu foi em quem deveria ter sabido. O comentarista albert_e argumentou que o conhecimento não está oculto, já que até mesmo a certificação AWS mais fundamental ensina o modelo de responsabilidade compartilhada e onde começam as obrigações do cliente.

Outros responsabilizaram os fornecedores pela impressão. O comentarista mhitza argumentou que provedores de nuvem promovem a ideia entre executivos através de canais de marketing e conferências, comparando com como narrativas de IA alcançaram executivos nos últimos dois anos. O comentarista lelanthran colocou a versão prática como uma pergunta:

"Em quem um CEO vai acreditar? Amazon, Microsoft e toda a divisão de infraestrutura de TI ou naquele único SRE que discorda deles?"

O comentarista dijit ofereceu uma explicação estrutural. O armazenamento distribuído negocia desempenho contra correção, e terceirizar significa que outra pessoa faz essa negociação, ponderada pelo que os clientes notam:

"Você não notará que há um terceiro servidor de commit fora do local (a menos que esse local seja bombardeado), mas notará escritas mais lentas."

A questão das obrigações de residência de dados

A conversa mais afiada preocupava-se com clientes que não poderiam ter replicado em outro lugar. A AWS afirma que os dados irrecuperáveis eram hospedados exclusivamente nas zonas e região afetadas, e um comentarista conectou essa linguagem às obrigações de residência de dados que exigem que a informação permaneça dentro das fronteiras nacionais. Backups criptografados enviados para o exterior não resolvem obviamente o problema, já que as chaves de descriptografia também precisariam estar fora da jurisdição para serem úteis após uma perda regional.

Essa tensão foi visível em março. Um arquiteto de nuvem sênior da T-Systems International alertou então que mover cargas de trabalho durante uma crise poderia restaurar o serviço enquanto empurrava dados sensíveis para fora das fronteiras nacionais, e que residência de dados é lei, não apenas uma prática recomendada.

Gregor Hohpe, coautor de Enterprise Integration Patterns, argumentou em março que a exposição é geográfica em vez de contratual:

"O risco é regional, não vinculado a um provedor. As pessoas que derrubaram ME-CENTRAL podem facilmente derrubar Azure ou qualquer outro data center."

Seis meses depois, esse enquadramento tem um resultado concreto anexado. A arquitetura multi-AZ distribui uma carga de trabalho entre instalações dentro de aproximadamente 100 quilômetros uma da outra, o que protege contra os modos de falha que a AWS lista, incluindo quedas de energia, raios, tornados e terremotos. Não protege contra um atacante que consegue alcançar várias dessas instalações na mesma noite.

A pergunta que se segue é mais estreita que uma estratégia multi-região. A linguagem da AWS é que os dados irrecuperáveis eram hospedados exclusivamente nas zonas e região afetadas, então o teste prático para qualquer equipe é se algo atualmente está em uma região sem cópia em outro lugar, e se obrigações regulatórias ou contratuais permitem que uma cópia saia da jurisdição. Onde não permitem, a exposição residual não é uma lacuna na arquitetura, mas uma restrição sobre ela, e uma que pertence a um registro de riscos em vez de um runbook.

A AWS afirma que permanece comprometida em apoiar clientes nos EAU e Bahrein. Clientes que precisam de assistência são direcionados ao AWS Support.