Duas zonas de disponibilidade, com seis horas de intervalo

Às 12:51 UTC de 2 de março de 2026, a zona de disponibilidade que a AWS designa por mec1-az2, na sua região Médio Oriente Emirados, deixou de funcionar normalmente. Às 18:46 UTC do mesmo dia, também a mec1-az3 estava afetada. A AWS confirmou que ambas tinham sido atingidas diretamente por drones no quadro do conflito mais amplo na zona. Uma terceira instalação, a mes1-az2 na região distinta do Barém, tinha sido perturbada por volta das 06:56 UTC dessa segunda-feira, o que a AWS atribuiu a um ataque de drone nas imediações com impactos físicos na sua infraestrutura.

Os impactos provocaram incêndios. Os incêndios acionaram os sistemas de aspersão dos centros de dados, e a água danificou equipamento. A AWS relatou que os clientes registavam taxas elevadas de falha na entrada e saída de dados em serviços como o S3, que precisa de pelo menos uma zona sã por região para funcionar. A empresa estimou que repor as instalações e os respetivos sistemas de refrigeração levaria pelo menos um dia.

Guarde essa estimativa para o resto do artigo. Foi dada de boa-fé, por um operador com melhor informação do que qualquer cliente tinha, e descrevia a reparação com rigor.

A frase do aviso que realmente contava

A par das atualizações de estado, a AWS disse aos clientes algo de maior alcance. Aconselhou-os a salvaguardar os dados e a ponderar migrar as cargas para outras regiões da AWS, com o fundamento de que o conflito em curso na zona tornava o ambiente operacional imprevisível. Os fornecedores de nuvem não pedem de ânimo leve a um cliente que paga para deixar uma região que eles próprios vendem.

Esse aviso é o elemento útil de todo o episódio, porque é a única instrução que responde ao modo de falha verdadeiro. Danos de aspersão são uma reparação. Um ambiente operacional imprevisível não é uma reparação, é uma propriedade do local, e nenhuma engenharia dentro do edifício a altera. A AWS estava, no fundo, a dizer aos clientes que a resposta correta a esta classe de acontecimentos é a saída e não a paciência.

A parte incómoda: a maioria dos manuais de reposição tem uma página para esperar e nenhuma para sair.

Pelo menos um dia, medido contra o calendário

A 30 de abril, o próprio estado de serviço da AWS dizia que a região Médio Oriente Emirados tinha sofrido danos em consequência do conflito no Médio Oriente e não conseguia então sustentar com fiabilidade as aplicações dos clientes. Repare no que mudou nessa frase. Em março a região tinha uma avaria e uma estimativa. No final de abril tinha uma condição e nenhuma estimativa.

A 28 de julho a Cloudflare publicou a sua revisão trimestral de eventos de perturbação da internet, retirada dos dados de rede do Radar. Aí consta que o tráfego HTTP para me-central-1 se manteve baixo, e a redução prolongada é descrita como a assinatura a jusante de danos físicos na infraestrutura do centro de dados subjacente. Trata-se de uma medição independente e não de uma declaração do fornecedor, e aponta no mesmo sentido cerca de cinco meses depois dos ataques.

A aritmética a levar à próxima revisão de continuidade: a estimativa publicada era de pelo menos um dia, e a resposta observável continua a medir-se em meses.

A resiliência regional foi desenhada para a falha errada

Uma arquitetura em várias zonas de disponibilidade é uma resposta genuinamente boa à falha para que foi desenhada. As zonas são separadas para que um incêndio, uma inundação, um incidente elétrico ou uma falha de rede numa delas não arraste as outras. Esse pressuposto de desenho aguenta lindamente enquanto o perigo for local a um edifício e independente entre edifícios. Deixa de aguentar quando o perigo é regional e correlacionado, porque então a separação entre zonas mede-se em quilómetros e aquilo que causa o dano não.

Duas das três zonas nos Emirados foram atingidas no mesmo dia. Uma instalação noutra região, noutro país, foi afetada na mesma semana. A independência das zonas é uma afirmação física sobre uma lista concreta de perigos, e o conflito armado não consta dessa lista. Vale a pena dizê-lo com clareza porque é a parte que depois parece óbvia e antes quase nunca aparece numa revisão de desenho.

Para as empresas europeias a obrigação já existe: as entidades financeiras abrangidas pelo DORA devem ao seu supervisor um plano documentado de saída e continuidade para os prestadores críticos de serviços informáticos, e esse plano tem de aguentar que uma região do fornecedor fique indisponível e não apenas lenta.

Quatro alterações ao seu manual esta semana

Primeiro, escreva o seu objetivo real de tempo de reposição para a perda de uma região inteira e não de uma zona, e seja honesto quanto a alguma vez o ter testado. Se a resposta honesta for que a perda de região está fora do âmbito, isso é uma decisão, e deve ficar registada com um responsável identificado em vez de ficar como omissão. Segundo, separe os cenários de reparação dos cenários de saída. Um cenário de reparação espera. Um cenário de saída move-se, e precisa dos seus dados, da sua configuração de identidades e das suas rotas de rede já preparados noutro sítio.

Terceiro, decida antecipadamente que evidência desencadearia uma mudança. O gatilho útil aqui não foi a avaria de 2 de março, foi o aviso que dizia aos clientes para ponderarem migrar. Os fornecedores raramente dizem isso, e quando o fazem deve ser tratado como o sinal e não como ruído de fundo. Quarto, verifique onde estão fisicamente as suas cópias de segurança. Uma cópia dentro da região de que está a tentar sair não é uma cópia, e o momento em que precisa dela é o momento em que a região é o problema.

Leia a seguir: A OpenAI pagou de volta naquilo que falhou  |  Um quarto gigante da nuvem torna-se plausível