# Azure (2026): Sobrecarga de Workloads GenAI e o Blast Radius Compartilhado Em 29 de maio de 2026, a Microsoft Azure sofreu um incidente de disponibilidade ligado à saturação de infraestrutura de roteamento compartilhada por workloads de IA generativa de primeira-parte. O evento expôs o risco clássico de noisy neighbor em escala de nuvem hiper-escalável e levou a Microsoft a migrar cargas GenAI próprias para planos de roteamento dedicados. Esta análise reconstrói o incidente, avalia as decisões de arquitetura envolvidas e extrai lições aplicáveis a qualquer plataforma que hospede inferência de LLM em infraestrutura multi-tenant. - URL: https://fernando.moretes.com/studies/azure-genai-overload-2026 - Markdown: https://fernando.moretes.com/studies/azure-genai-overload-2026/study.md?lang=pt - Type: Post-mortem - Company: Microsoft Azure - Domain: Resiliência - Date: 2026-05-29 - Tags: azure, genai, resiliencia, noisy-neighbor, capacity-planning, incident, blast-radius, inferencia - Reading time: 10 min --- Quando a Microsoft colocou seus próprios workloads de IA generativa na mesma infraestrutura de roteamento que serve clientes externos, ela criou uma bomba de capacidade com temporizador. Em 29 de maio de 2026, esse temporizador zerou — e o blast radius atingiu clientes que não tinham nada a ver com IA. ## Fatos do Incidente - **Empresa / Sistema:** Microsoft Azure — infraestrutura de roteamento global - **Data do Incidente:** 29 de maio de 2026 - **Categoria Primária:** Saturação de capacidade / Noisy neighbor em roteamento compartilhado - **Serviços Afetados:** Múltiplos serviços Azure dependentes da camada de roteamento compartilhada; clientes externos impactados indiretamente - **Causa Raiz (resumo):** Workloads GenAI de primeira-parte (Microsoft) consumiram capacidade desproporcional na infraestrutura de roteamento compartilhada, degradando serviços de clientes externos - **Resposta Estrutural:** Migração de grandes cargas GenAI próprias para infraestrutura de roteamento dedicada (plano separado) - **Fonte Primária:** Azure Status History — microsoft.com - **Classificação de Severidade (estimada):** Alta — degradação ampla de disponibilidade em múltiplos serviços ## O que Aconteceu Em 29 de maio de 2026, a Microsoft Azure registrou um incidente de disponibilidade cujo vetor primário foi a saturação da camada de roteamento compartilhada por workloads de IA generativa operados pela própria Microsoft — cargas de primeira-parte, não de clientes externos. A dinâmica é conhecida em sistemas distribuídos, mas raramente se manifesta nessa escala: um tenant privilegiado — neste caso, o próprio operador da nuvem — consome recursos de infraestrutura compartilhada de forma desproporcional, degradando a qualidade de serviço de todos os outros tenants. O termo técnico é **noisy neighbor**, mas aqui o 'vizinho barulhento' era o dono do prédio. Workloads de inferência de LLM têm um perfil de tráfego radicalmente diferente de workloads tradicionais. Uma requisição de inferência pode durar de centenas de milissegundos a vários segundos, mantendo conexões abertas, consumindo buffers de roteamento e ocupando slots de processamento por períodos muito maiores do que uma chamada de API convencional. Quando esses workloads escalam horizontalmente — como os produtos Microsoft baseados em Copilot e Azure OpenAI Service inevitavelmente fazem — o impacto na camada de roteamento é multiplicativo, não linear. A infraestrutura de roteamento da Azure, projetada para o perfil de tráfego de serviços de nuvem tradicionais (requisições curtas, alta frequência, baixa latência de conexão), não estava dimensionada para absorver esse novo padrão sem afetar o plano de dados compartilhado. O resultado foi degradação de disponibilidade em serviços que não tinham relação direta com IA — um blast radius que se expandiu lateralmente pela infraestrutura compartilhada. ## Linha do Tempo do Incidente 1. **Pré-incidente — Crescimento Acumulado** — Nos meses anteriores a maio de 2026, os produtos Microsoft baseados em GenAI (Copilot para Microsoft 365, Azure OpenAI Service, Bing AI e outros) experimentaram crescimento acelerado de uso. Esses workloads de inferência foram gradualmente escalados na infraestrutura de roteamento compartilhada da Azure, aumentando a pressão de capacidade de forma incremental — abaixo dos limiares de alerta configurados para padrões de tráfego tradicionais. 2. **29/mai/2026 — Evento Gatilho** — Um pico de demanda nos workloads GenAI de primeira-parte — possivelmente correlacionado com um lançamento de feature, campanha de marketing ou evento de uso orgânico — empurrou a utilização da camada de roteamento compartilhada além do ponto de saturação. Os mecanismos de throttling existentes não foram suficientes para conter o impacto dentro do domínio GenAI. 3. **Propagação — Blast Radius Lateral** — A saturação da camada de roteamento começou a afetar serviços Azure não relacionados a IA. Clientes externos reportaram degradação de disponibilidade em serviços dependentes do mesmo plano de roteamento. O impacto se manifestou como aumento de latência, timeouts e falhas intermitentes — sintomas típicos de contenção de recursos em infraestrutura compartilhada. 4. **Resposta Imediata — Mitigação Operacional** — As equipes de engenharia da Azure aplicaram mitigações operacionais imediatas: throttling agressivo nos workloads GenAI de primeira-parte, redistribuição de carga entre regiões e ativação de capacidade de reserva. A degradação foi gradualmente contida, mas o tempo de recuperação foi significativo dado o escopo do impacto. 5. **Pós-incidente — Decisão Estrutural** — A Microsoft tomou a decisão arquitetural de migrar grandes cargas GenAI próprias para infraestrutura de roteamento dedicada — um plano separado, isolado do plano compartilhado que serve clientes externos. Essa mudança foi comunicada publicamente como parte da resposta ao incidente e representa uma alteração fundamental no modelo de isolamento de tenants da Azure para workloads de IA. ## Fluxo de Falha: Roteamento Compartilhado vs. Dedicado O diagrama reconstrói o estado PRÉ-incidente (plano compartilhado, à esquerda) e o estado PÓS-remediação (plano dedicado para GenAI, à direita). A seta vermelha tracejada indica o vetor de propagação do blast radius no estado anterior. ### 🌐 Clientes Externos / External Customers - Clientes Azure External Customers (user) ### 🤖 Workloads GenAI 1ª Parte / First-Party GenAI - Microsoft Copilot M365 / Bing AI (ai) - Azure OpenAI Service (interno) (ai) ### ⚠️ PRÉ-Incidente: Plano Compartilhado / PRE-Incident: Shared Plane - Roteamento Compartilhado (Shared Routing Plane) (network) - Load Balancer Compartilhado (network) ### ☁️ Serviços Azure / Azure Services - Serviço Azure A (ex: Storage) (storage) - Serviço Azure B (ex: Compute) (compute) - Serviço Azure C (ex: Databases) (data) ### ✅ PÓS-Remediação: Plano Dedicado / POST-Remediation: Dedicated Plane - Roteamento Dedicado GenAI (Dedicated AI Plane) (network) - Quota & Throttling Engine (AI-specific) (security) - Frota de Inferência LLM (GPU Clusters) (ai) ### Fluxos - ext_customers -> shared_router: tráfego legítimo - copilot -> shared_router: ⚠️ PRÉ: sobrecarga - aoai -> shared_router: ⚠️ PRÉ: sobrecarga - shared_router -> shared_lb: saturação - shared_lb -> svc_a: degradado - shared_lb -> svc_b: degradado - shared_lb -> svc_c: degradado - copilot -> dedicated_router: ✅ PÓS: isolado - aoai -> dedicated_router: ✅ PÓS: isolado - dedicated_router -> dedicated_quota: controle de quota - dedicated_quota -> inference_fleet: inferência controlada > **Causa Raiz: O Operador Como Noisy Neighbor:** A causa raiz não foi um bug, uma falha de hardware ou um ataque externo. Foi uma decisão de design implícita: **colocar workloads de primeira-parte de altíssima intensidade de recursos no mesmo plano de roteamento que serve clientes externos**, sem isolamento de capacidade adequado entre esses dois domínios. Workloads de inferência LLM têm três características que os tornam especialmente perigosos em infraestrutura compartilhada: (1) **latência de requisição longa** — mantêm recursos alocados por segundos, não milissegundos; (2) **elasticidade assimétrica** — escalam rapidamente em resposta a demanda, mas a infraestrutura de roteamento não escala na mesma velocidade; (3) **prioridade implícita** — cargas de primeira-parte frequentemente têm acesso privilegiado ou menos throttling do que clientes externos, criando um desequilíbrio estrutural. O resultado foi um blast radius que se propagou lateralmente: serviços sem qualquer relação com IA foram degradados porque compartilhavam a mesma camada de roteamento com workloads que a saturaram. ## Por Que Isso É Diferente de Incidentes de Capacidade Anteriores Incidentes de capacidade em nuvem não são novos. AWS, Azure e GCP já sofreram degradações por saturação de recursos compartilhados. Mas o incidente de maio de 2026 tem características que o distinguem estruturalmente dos precedentes. **Primeiro, o perfil de carga é qualitativamente diferente.** Workloads tradicionais de nuvem — VMs, containers, funções serverless, bancos de dados — têm requisições de curta duração e alta frequência. A infraestrutura de roteamento foi projetada e dimensionada para esse padrão. Inferência de LLM quebra essa suposição fundamental: uma única requisição de geração de texto pode manter uma conexão aberta por 5-30 segundos enquanto o modelo gera tokens. Multiplique isso por milhões de usuários simultâneos do Copilot e você tem um padrão de tráfego que a infraestrutura de roteamento simplesmente não foi projetada para absorver. **Segundo, a escala de crescimento foi sem precedentes.** A adoção de produtos GenAI pela Microsoft cresceu de forma exponencial entre 2023 e 2026. Esse crescimento não foi linear nem previsível nos mesmos termos que o crescimento de workloads tradicionais. Picos de uso correlacionados com eventos externos (lançamentos de produtos, notícias virais, campanhas de marketing) criaram padrões de carga que os modelos de capacity planning tradicionais não capturavam adequadamente. **Terceiro, o isolamento de tenants não foi projetado para esse cenário.** A arquitetura multi-tenant da Azure foi construída assumindo que nenhum tenant individual — incluindo a própria Microsoft — consumiria uma fração desproporcional da capacidade de roteamento compartilhada. Essa suposição era razoável para workloads tradicionais. Para workloads GenAI de escala de produto de consumo massivo, ela se provou incorreta. Essa combinação — novo perfil de carga, crescimento exponencial, isolamento inadequado — criou as condições para um incidente que não teria sido previsto pelos modelos de risco existentes. É um lembrete de que **suposições arquiteturais têm prazo de validade**, especialmente quando o perfil de carga muda fundamentalmente. ## Remediação: Isolamento Estrutural de Planos de Roteamento A resposta da Microsoft ao incidente foi cirúrgica e estruturalmente correta: **separar o plano de roteamento dos workloads GenAI de primeira-parte do plano compartilhado que serve clientes externos**. Essa decisão merece análise detalhada porque é exatamente o tipo de remediação que resolve a causa raiz, não apenas os sintomas. **O que a separação de planos resolve:** Ao mover cargas GenAI próprias para infraestrutura de roteamento dedicada, a Microsoft elimina o vetor de blast radius lateral. Um pico de inferência no Copilot não pode mais saturar o roteamento que serve um cliente rodando workloads de banco de dados ou computação. Os dois domínios se tornam independentes em termos de capacidade de roteamento. Além disso, a separação permite que cada plano seja dimensionado e otimizado para seu perfil de carga específico. O plano GenAI pode ser configurado para lidar com conexões longas, alta concorrência de tokens e padrões de tráfego burst característicos de inferência. O plano de clientes externos pode manter as otimizações para workloads tradicionais. **O que a separação não resolve sozinha:** A separação de planos é necessária mas não suficiente. Clientes externos que usam Azure OpenAI Service diretamente ainda competem por capacidade de inferência entre si — o problema de noisy neighbor se desloca para a camada de GPU/TPU, não desaparece. A remediação completa requer também: (1) quotas por tenant na camada de inferência, não apenas no roteamento; (2) mecanismos de throttling adaptativos que respondam a padrões de burst; (3) capacity planning específico para perfis de carga de LLM, incluindo modelagem de tokens por segundo como métrica primária de capacidade. **Implicações para o setor:** Essa decisão da Microsoft sinaliza uma mudança de paradigma que todo provedor de nuvem com ambições em IA precisará fazer: **tratar workloads de inferência LLM como uma classe de recurso distinta**, com seus próprios planos de roteamento, modelos de capacidade e políticas de isolamento. A infraestrutura de nuvem construída para a era pré-GenAI não é adequada, sem modificações, para a era de inferência massiva. ## Lições Técnicas do Incidente - **Inferência LLM é uma nova classe de carga**: O perfil de requisições longas, alta concorrência e burst assimétrico quebra as suposições de dimensionamento de infraestrutura de roteamento tradicional. Trate como classe separada desde o design. - **O operador como tenant privilegiado é um risco arquitetural**: Quando o operador da plataforma hospeda seus próprios workloads intensivos na mesma infraestrutura que serve clientes, ele se torna o maior risco de noisy neighbor. Isolamento de planos é obrigatório, não opcional. - **Blast radius lateral é o risco mais subestimado em multi-tenancy**: O impacto não ficou restrito a serviços de IA — se propagou para serviços sem relação com IA. Mapeie dependências de infraestrutura compartilhada e calcule o blast radius potencial para cada domínio. - **Capacity planning precisa de métricas nativas de IA**: Tokens por segundo, duração média de requisição de inferência e concorrência de sessões são as métricas corretas para dimensionar infraestrutura GenAI — não RPS ou throughput de bytes tradicionais. - **Throttling deve ser aplicado na camada de inferência, não apenas no roteamento**: Separar planos de roteamento resolve o blast radius de rede, mas não o blast radius de GPU/TPU. Quotas por tenant na camada de inferência são complementares e igualmente necessárias. - **Crescimento exponencial invalida modelos de capacity planning lineares**: Produtos GenAI de consumo massivo crescem de forma não-linear e correlacionada com eventos externos. Modelos de capacity planning precisam incorporar cenários de pico extremo, não apenas médias históricas. ## Decisão Arquitetural: Separação de Planos de Roteamento **Status:** accepted **Contexto** Após o incidente de maio de 2026, a Microsoft precisava decidir como isolar workloads GenAI de primeira-parte do plano de roteamento compartilhado com clientes externos. As opções incluíam throttling mais agressivo no plano compartilhado, quotas por workload, ou separação física de planos. **Decisão** Migrar grandes cargas GenAI de primeira-parte para infraestrutura de roteamento dedicada, separada fisicamente do plano compartilhado que serve clientes externos. **Consequências** - ✅ Elimina o vetor de blast radius lateral entre GenAI e outros serviços Azure - ✅ Permite otimização independente de cada plano para seu perfil de carga específico - ✅ Melhora a previsibilidade de capacidade para clientes externos - ⚠️ Aumenta o custo operacional e de infraestrutura (duplicação de planos) - ⚠️ Não resolve o noisy neighbor na camada de inferência (GPU/TPU) para clientes externos entre si - ⚠️ Requer migração complexa de workloads existentes sem interrupção de serviço ## Estratégias de Isolamento para Workloads GenAI em Multi-Tenant | Critério | Estratégia | Blast Radius Roteamento | Blast Radius Inferência | Custo Operacional | Complexidade de Implementação | | --- | --- | --- | --- | --- | --- | | Plano Compartilhado (estado pré-incidente) | Alto | Alto | Baixo | Baixa | — | | Throttling por Workload no Plano Compartilhado | Médio | Alto | Baixo | Média | — | | Plano de Roteamento Dedicado (decisão pós-incidente) | Eliminado | Alto | Alto | Alta | — | | Plano Dedicado + Quotas por Tenant na Inferência | Eliminado | Baixo | Muito Alto | Muito Alta | — | > **Minha Leitura Sênior: O Problema Que Ninguém Quer Admitir:** O que me chama atenção neste incidente não é a falha técnica — é a falha de governança arquitetural que a precedeu. A Microsoft tem engenheiros de classe mundial. O problema de noisy neighbor em infraestrutura compartilhada é conhecido há décadas. Isolamento de tenants é um princípio fundamental de design de nuvem. E ainda assim, workloads GenAI de primeira-parte — com perfil de carga radicalmente diferente e crescimento exponencial — foram colocados no mesmo plano de roteamento que serve clientes externos. Isso acontece por uma razão que eu vejo repetidamente em organizações grandes: **a velocidade de lançamento de produto supera a velocidade de adaptação da infraestrutura**. Quando o Copilot precisava escalar rapidamente, a decisão mais rápida era usar a infraestrutura existente. A dívida técnica foi acumulada silenciosamente até o dia em que ela cobrou o preço. **O que eu faria diferente:** Em qualquer plataforma que hospede inferência de LLM em escala, eu trataria workloads de inferência como uma classe de recurso de primeira-classe desde o dia zero — com seus próprios planos de roteamento, modelos de capacidade baseados em tokens/segundo, quotas por tenant na camada de GPU, e circuit breakers que isolam domínios de falha antes que o blast radius se propague. Não como uma otimização futura, mas como requisito de arquitetura não-negociável. Além disso, eu implementaria um **'blast radius budget'** explícito para cada domínio de serviço: uma análise formal de quais outros serviços podem ser afetados se esse domínio saturar sua infraestrutura compartilhada. Esse orçamento seria revisado a cada mudança arquitetural significativa — especialmente quando novos tipos de workload são introduzidos. A lição mais importante deste incidente não é técnica. É organizacional: **a governança de capacidade precisa ter o mesmo peso que a velocidade de entrega de produto**. Em empresas de tecnologia, essa é uma batalha política difícil. Mas incidentes como este são o custo de perder essa batalha. ## Análise pelo Framework Well-Architected - **security**: **Risco de isolamento de tenant.** Embora não seja um incidente de segurança, a ausência de isolamento de capacidade entre tenants (incluindo o próprio operador) é um risco de tenant isolation que tem implicações de segurança em cenários adversariais. - **reliability**: **Falha crítica.** A ausência de isolamento de domínios de falha entre workloads GenAI e serviços de clientes violou o princípio de blast radius containment. A remediação — separação de planos de roteamento — é a resposta correta, mas deveria ter sido o design inicial. - **performance**: **Suposições de performance inválidas.** O modelo de performance da infraestrutura de roteamento foi construído para workloads de curta duração. Inferência LLM tem perfil de performance fundamentalmente diferente. Capacity planning e benchmarking precisam ser refeitos com métricas nativas de IA. ## Veredicto: O Preço de Tratar IA Como Mais um Workload O incidente Azure de maio de 2026 é um caso de estudo sobre o custo de suposições arquiteturais desatualizadas em um ambiente de mudança tecnológica acelerada. A decisão de hospedar workloads GenAI de primeira-parte no mesmo plano de roteamento que serve clientes externos não foi negligência — foi uma decisão pragmática que fazia sentido em um determinado momento, quando a escala era menor e o perfil de carga ainda não era bem compreendido. O problema é que essa decisão não foi revisada à medida que a escala cresceu exponencialmente. **O que este incidente prova:** Infraestrutura de nuvem construída para workloads tradicionais precisa ser fundamentalmente repensada para suportar inferência LLM em escala de produto de consumo massivo. Não é uma questão de adicionar mais capacidade ao plano existente — é uma questão de reconhecer que inferência LLM é uma classe de recurso distinta que requer isolamento arquitetural de primeira-classe. **A remediação foi correta:** Separar planos de roteamento é a decisão certa. Mas é apenas o primeiro passo. O problema de noisy neighbor se desloca para a camada de inferência (GPU/TPU), e a solução completa requer quotas por tenant, throttling adaptativo e capacity planning com métricas nativas de IA em todas as camadas da stack. **A lição para a indústria:** Todo provedor de nuvem, toda empresa construindo produtos GenAI em infraestrutura compartilhada, e todo arquiteto responsável por sistemas multi-tenant com workloads de IA precisa fazer a mesma pergunta que a Microsoft foi forçada a responder: **minha infraestrutura de isolamento foi projetada para o perfil de carga que estou rodando hoje, ou para o perfil de carga de cinco anos atrás?** Se a resposta for a segunda opção, o temporizador já está rodando. ## Referências - [Azure Status History — Microsoft Azure](https://azure.status.microsoft/en-us/status/history/) ## Fontes do caso - [Azure status history](https://azure.status.microsoft/en-us/status/history/)