Quando a Falha é do Fornecedor Cloud: o Que a Queda da Azure de 30 de Setembro Ensina Sobre Disaster Recovery

Na noite de 30 de Setembro, várias empresas europeias perderam a ligação entre os seus escritórios e a cloud. Nenhuma tinha alterado nada. As equipas internas abriram incidentes, confirmaram que a configuração estava correcta e ficaram a olhar para a página de estado do fornecedor. Não havia mais nada para fazer.

É esse o ponto deste artigo. Não a falha em si, que acontece a todos os fornecedores, mas o que ela revela sobre onde está o controlo quando a falha não é nossa.

O que aconteceu a 30 de Setembro

Segundo o histórico de estado da Microsoft Azure, entre as 20:30 UTC de 30 de Setembro e as 02:15 UTC de 1 de Outubro de 2026, cerca de cinco horas e quarenta e cinco minutos, vários serviços de rede tiveram falhas de ligação em várias regiões. Entre os afectados estavam os gateways de ligação privada (ExpressRoute), as ligações por rede privada virtual (VPN Gateway), o Azure Firewall, o Application Gateway e o Azure VMware Solution. A Microsoft cita, entre as regiões ainda afectadas no fim do incidente, North Europe, UK South, UK West e France Central.

A causa indicada no resumo do incidente foi uma alteração recente num serviço regional de gestão de gateways, que gerou carga acima do previsto enquanto uma manutenção de sistema operativo, sem relação com essa alteração, avançava por várias regiões. A alteração foi revertida e a manutenção suspensa.

Repare no tipo de serviço afectado. Não foi uma aplicação. Foi a ligação entre a empresa e a cloud. Quando essa ligação cai, as aplicações podem estar perfeitamente saudáveis e, ainda assim, inacessíveis.

Porque é que estas falhas demoram mais

A falha da Azure não é um caso isolado. É um padrão medido.

O relatório analisou cerca de 178 mil registos públicos de páginas de estado, correspondentes a aproximadamente 109 mil incidentes não planeados em mais de 390 empresas de 13 sectores, entre 2018 e Junho de 2026. O mesmo estudo contou 223 empresas afectadas, a jusante, pela falha da AWS de 20 de Outubro de 2025.

A diferença entre 96 e 247 minutos não é técnica. É de controlo. Numa falha interna, a equipa diagnostica, corrige e confirma. Numa falha do fornecedor, a equipa diagnostica que não pode corrigir. Tudo o que reduz esse tempo tem de ter sido decidido antes.

A resiliência não se compra ao fornecedor

Os acordos de nível de serviço dos fornecedores cloud cobrem a disponibilidade do serviço deles, normalmente com créditos na factura quando falham. Não cobrem a continuidade da operação de quem os usa. Um crédito de alguns pontos percentuais numa factura mensal não compensa uma noite de vendas perdidas nem um processo industrial parado.

Este é o modelo de responsabilidade partilhada lido do lado menos confortável. O fornecedor responde pela infraestrutura que opera. A forma como cada empresa distribui as suas cargas por regiões, quantas ligações tem à cloud e o que faz quando uma delas cai continua a ser responsabilidade de quem desenha a arquitectura.

Na prática, muitas organizações descobrem a dependência no dia em que ela falha. A arquitectura cresceu região a região, serviço a serviço, e ninguém desenhou o mapa de quem depende de quem.

As quatro perguntas de um mapa de dependências

Um mapa de dependências útil não precisa de ferramenta nova. Precisa de quatro respostas por cada serviço crítico.

1. De que fornecedor e de que região depende? Incluindo as dependências indirectas, como a ligação privada, o fornecedor de identidade ou o serviço de nomes de domínio.
2. O que continua a funcionar quando essa região cai? Nada, uma versão degradada ou uma alternativa noutra região. A resposta honesta é muitas vezes "nada".
3. Quanto tempo e quantos dados se podem perder? São o objectivo de tempo de recuperação (RTO) e o objectivo de ponto de recuperação (RPO). Se ninguém os definiu, a arquitectura definiu-os por omissão.
4. Quem decide activar a alternativa, e em quanto tempo? Uma alternativa que exige uma reunião de direcção às duas da manhã não é uma alternativa.

Estas quatro perguntas separam um plano de recuperação de um documento chamado plano de recuperação. A diferença entre ter cópias dos dados e conseguir voltar a operar está explicada em Backup não é disaster recovery.

O que a NIS2 já exige

A directiva europeia NIS2, transposta em Portugal pelo Decreto-Lei n.º 125/2025, em vigor desde 3 de Abril de 2026, trata este tema directamente. O artigo 21.º, n.º 2 inclui entre as medidas mínimas de gestão de risco a continuidade das actividades, incluindo a gestão de cópias de segurança e a recuperação de desastres, e a segurança da cadeia de fornecimento, incluindo as relações com fornecedores directos e prestadores de serviços.

Um fornecedor cloud é, para efeitos práticos, parte dessa cadeia. E, segundo o Centro Nacional de Cibersegurança, os órgãos de gestão das entidades abrangidas passam a ter de aprovar formalmente as políticas de gestão de risco, supervisionar a sua implementação e assegurar a resposta e a recuperação em caso de incidente.

Para quem é fornecedor de uma entidade abrangida, a mesma exigência chega por via contratual, como explicado em NIS2 em Portugal: o que muda para quem fornece uma entidade essencial.

Por onde começar

Não é preciso um programa de multicloud para reduzir o risco. Quatro passos cobrem a maior parte da exposição.

Inventariar os serviços críticos e as suas dependências. Responder às quatro perguntas acima para os cinco a dez serviços de que o negócio não pode prescindir.

Testar a falha de uma região. Não em papel. Desligar, num ambiente de teste ou numa janela controlada, o acesso a uma região e cronometrar o tempo até a operação voltar. O número que sai desse teste é o RTO real.

Garantir mais de um caminho até à cloud. Uma única ligação privada é um ponto único de falha, mesmo quando o fornecedor tem redundância interna. Uma segunda ligação, ou uma alternativa por rede privada virtual testada, muda o cenário.

Escrever quem decide. Nome, substituto e critério de activação. Um incidente às duas da manhã não é o momento de descobrir que ninguém tem autoridade para mudar o tráfego de região.

Perguntas frequentes

Ter cargas em duas regiões do mesmo fornecedor resolve? Resolve uma parte. Protege contra a falha de uma região, não contra um problema que atravesse várias regiões ao mesmo tempo, como o de 30 de Setembro. A decisão depende de quanto custa uma hora de paragem para cada serviço.

Uma estratégia multicloud é obrigatória? Não. Para a maioria das empresas, uma segunda região testada e um plano de recuperação cronometrado reduzem mais risco por euro investido do que uma arquitectura multicloud completa.

O fornecedor não é responsável pela falha? Pela falha do serviço, sim, nos termos do contrato. Pela continuidade da operação de cada cliente, não. Essa continuidade é desenhada e testada do lado de quem usa a cloud.

Conclusão

A falha de 30 de Setembro durou menos de seis horas e foi resolvida pelo fornecedor. Para as empresas afectadas, a pergunta útil não é porque falhou a Azure. É o que teria mudado se, na véspera, alguém tivesse respondido às quatro perguntas do mapa de dependências.

Para mapear as dependências críticas da operação cloud e testar a recuperação, é possível agendar uma Sessão de Esclarecimento, sem compromisso.