Azure Front Door out/2025: config global passa pelas checagens de segurança

01 · CONTEXTO

Uma configuração, todos os sites de borda do mundo

O Azure Front Door (AFD) e a Azure CDN encaminham tráfego por sites de borda distribuídos globalmente, que atendem clientes e serviços da própria Microsoft, inclusive portais de gerenciamento. Este caso usa o relatório pós-incidente (PIR) oficial da Microsoft sobre a falha de 29 de outubro de 2025, que afetou clientes e serviços com erros de timeout e de resolução de DNS.

O plano de controle do AFD gera os metadados de configuração dos clientes, e o plano de dados os consome em operações como purga e regras de firewall de aplicação web (WAF). Como as aplicações podem ser acessadas de qualquer lugar do mundo, essas mudanças são implantadas em todos os sites de borda.

1. O cliente altera a configuração da sua aplicação, como rotas, regras de WAF ou origens, e a mudança chega ao plano de controle.

2. O plano de controle gera metadados de configuração, e o plano de dados, nos sites de borda, os consome.

3. Usuários de qualquer lugar chegam a um site de borda, que aplica a configuração e busca o conteúdo na origem quando precisa.

4. O DNS interno da plataforma, usado para resolver nomes, é hospedado nos próprios sites de borda.

02 · A PROTEÇÃO

O que deveria barrar uma configuração ruim

O AFD usa vários estágios de implantação e um sistema de proteção de configuração. Ele valida a configuração em cada estágio e só avança depois de receber sinais positivos de saúde do plano de dados.

Quando a implantação termina bem, o sistema atualiza um snapshot de "última configuração boa conhecida" (LKG), uma foto periódica das configurações saudáveis que permite reverter automaticamente em caso de problema. O sistema espera cerca de um minuto entre estágios e conclui, em média, em 5 a 10 minutos no mundo todo.

03 · A CADEIA DE EVENTOS

Uma falha que só aparece depois que a configuração já passou

Uma sequência específica de mudanças de configuração de clientes, feitas em duas versões diferentes de build do plano de controle, gerou metadados incompatíveis. As mudanças eram válidas e não maliciosas, mas os metadados expuseram um bug latente no plano de dados, que travou durante um processamento assíncrono.

O defeito escapou da validação em pré-produção porque nem todos os recursos são validados entre versões diferentes do plano de controle.

1. O plano de controle gera metadados incompatíveis a partir de mudanças válidas, e a mudança incompatível é feita às 15:35 UTC.

2. A configuração é aplicada em pré-produção às 15:36 UTC e o monitoramento segue recebendo sinais saudáveis, porque o metadado problemático ainda não havia causado problema.

3. Como o travamento só aparece de forma assíncrona, depois de cerca de cinco minutos, a configuração atravessa as salvaguardas e segue para estágios posteriores.

4. Às 15:39 UTC a maioria dos sites de borda já tinha a configuração, e o snapshot da última configuração boa também foi atualizado com ela.

5. O impacto começa pela pré-produção às 15:41 UTC; às 15:43 UTC o sistema de proteção interrompe as mudanças novas e em andamento; às 15:45 UTC todos os sites de borda do mundo estão afetados.

Os travamentos também afetaram o DNS interno do AFD, hospedado nos sites de borda, o que causou erros intermitentes de resolução de nomes para parte das requisições de clientes.

O relatório diz que este incidente não teve relação direta com o de 9 de outubro: o modo de falha era parecido, mas os defeitos de fundo eram diferentes. Em 9 de outubro o sistema de proteção funcionou como esperado, mas foi contornado pela engenharia durante uma limpeza manual; em 29 de outubro a configuração passou pelo sistema de proteção antes de a tarefa assíncrona atrasada causar o travamento.

04 · A RESPOSTA

Reparar a última configuração boa à mão

Como o snapshot mais recente já continha os metadados conflitantes, a equipe decidiu não revertê-lo para ele e também não voltar a versões anteriores. Em vez disso, editou o mais recente, removendo manualmente as configurações problemáticas.

Às 17:30 UTC todas as mudanças de configuração de clientes foram bloqueadas, para não reintroduzir o problema durante a mitigação, e às 17:40 UTC começou a implantação do snapshot atualizado na frota global. A recuperação exigiu recarregar as configurações em cada site de borda e reequilibrar o tráfego aos poucos, para evitar sobrecarga.

1. O snapshot mais recente já continha os metadados conflitantes, e a equipe decidiu não revertê-lo para ele.

2. Em vez de voltar a uma versão anterior, a engenharia edita o snapshot mais recente e remove manualmente as configurações problemáticas.

3. Às 17:30 UTC as mudanças de configuração de clientes deixam de ser propagadas ao plano de dados, para não reintroduzir o problema.

4. Às 17:40 UTC começa a implantação do snapshot atualizado, e cada site de borda recarrega todas as configurações de clientes.

5. Às 18:30 UTC o DNS se recupera e o tráfego é reequilibrado manualmente para poucos sites saudáveis; às 20:20 UTC o gerenciamento passa a ser automático; às 00:05 UTC de 30 de outubro o impacto é confirmado como mitigado.

Muitos serviços que usam o AFD conseguiram fazer failover, como os portais Entra e Intune e o Azure AD B2C. O Azure Portal usou o seu processo padrão de recuperação para sair do AFD, mas alguns serviços dentro do Portal não tinham estratégia de fallback, e partes da experiência continuaram falhando mesmo após a recuperação do Portal, como o Marketplace.

1. No caminho normal, o acesso ao portal passa pela plataforma de borda.

2. Durante o incidente, a plataforma de borda está em falha.

3. O Portal usa o seu processo padrão de recuperação e passa a ser acessado fora da plataforma de borda; a transição aparece no relatório às 17:26 UTC.

4. Serviços dentro do Portal sem estratégia de fallback, como o Marketplace, continuam falhando mesmo depois que o Portal se recupera.

05 · REPAROS E LIÇÕES

O que mudou no pipeline

Entre as medidas de segurança de implantação, a Microsoft lista processamento síncrono completo de cada configuração antes de avançar a estágios de produção, remoção do processamento assíncrono do plano de dados, um estágio adicional de pré-canary e mais tempo de espera (bake time) em cada estágio da propagação.

Isso tem custo: os novos estágios e o tempo de espera aumentaram o tempo de propagação de todas as operações, incluindo criar, atualizar, excluir, operações de WAF e purgas de cache. O relatório cita como meta reduzir esse tempo de 45 minutos para cerca de 15 minutos.

Para reduzir o raio de impacto, a Microsoft migrou infraestrutura crítica própria, como o Portal, o Marketplace e a criação de tickets de suporte, para uma solução ativo-ativo com fail away, e planeja segmentar o plano de dados em micro cells para isolar a configuração e o tráfego de cada cliente. Para recuperar mais rápido, cita melhorias no tempo de recuperação do plano de dados, de cerca de 4,5 horas para cerca de uma hora, e o desacoplamento do processamento de configuração das instâncias que atendem tráfego.