Em Azure, quota e limite quase nunca aparecem em reunião de arquitetura. Eles aparecem quando uma VM não sobe, um Private Endpoint falha, um peering não escala, uma policy não aplica ou um alerta deixa de ser criado. Em ambientes enterprise, isso não é detalhe administrativo. É parte real da escalabilidade da plataforma.
O erro mais comum é abordar esse assunto como uma lista cansativa de números. Esse formato ajuda pouco. O que realmente importa é entender quais limites mudam o desenho da arquitetura, quais podem ser aumentados e quais normalmente indicam necessidade de reorganização, não só abertura de chamado. A própria Microsoft diferencia limites ajustáveis de limites fixos: quando a tabela traz limite padrão e máximo, há margem para aumento; quando aparece apenas “Limit”, em geral estamos diante de um teto não ajustável no mesmo modelo.
Leitura rápida
O ponto não é decorar quotas do Azure.
O ponto é descobrir cedo quais limites podem travar expansão, operação e governança.
Onde esse tema pega mais em enterprise
Em ambiente corporativo, alguns limites aparecem com muito mais frequência do que outros. Entre os mais relevantes estão quotas de vCPU para VMs, limites de peering e Private Endpoint, escala de DNS privado, quantidade de role assignments, volume de objetos do Azure Policy e crescimento da malha de alertas. Cada um deles mexe com uma camada diferente da plataforma.
1) vCPU de VMs: o limite mais frequente do dia a dia
Esse é, provavelmente, o caso mais recorrente em ambientes enterprise. Em Azure, a quota de compute não é uma única linha. Para VMs, a Microsoft mostra que existe pelo menos a combinação entre Total Regional vCPUs e vCPUs por família de VM, como D, DSv3, F e outras. Uma implantação pode falhar mesmo com folga em uma dessas camadas, se a outra estiver no limite.
Esse ponto importa porque muita gente enxerga apenas o tamanho da VM que quer subir, mas a quota é aplicada por assinatura, por região e por família. Em ambiente enterprise, isso aparece em cenários como crescimento rápido de workloads, criação de novos ambientes, ativação de DR, testes de resiliência e onboarding de times em regiões específicas. A própria Microsoft também destaca que a quota considera VMs alocadas e desalocadas, então desligar uma VM nem sempre resolve do jeito que muita gente espera.
Na prática
Um erro de quota de VM nem sempre significa “falta capacidade para qualquer VM”.
Muitas vezes significa “faltou quota naquela região ou naquela família específica”.
2) Peering: o hub-and-spoke não cresce indefinidamente
Peering é outro limite que muda arquitetura. A Microsoft documenta até 500 peerings por VNet, podendo chegar a 1.000 com Azure Virtual Network Manager. No mesmo conjunto, entram outros números relevantes, como 3.000 subnets por VNet e 65.536 IPs privados por VNet.
Isso significa que o hub-and-spoke funciona muito bem, mas não deve ser desenhado como se fosse infinito. À medida que o ambiente cresce com mais spokes, domínios, ambientes e serviços compartilhados, o limite deixa de ser teórico. Em geral, quando esse tipo de número começa a pesar, ele não indica apenas crescimento; ele indica que a topologia precisa continuar escalável sem depender de centralização excessiva.
3) Private Endpoint: o limite que parece distante até chegar
Private Endpoint virou componente padrão em muitas arquiteturas corporativas. Por isso mesmo, ele costuma surpreender quando o ambiente cresce. A Microsoft documenta 1.000 private endpoints em uma única VNet, 4.000 across peered virtual networks e, com High Scale Private Endpoints, o aumento para 5.000 em uma VNet e 20.000 entre VNets pareadas.
Esse é um caso especialmente importante porque o consumo não deve ser analisado olhando só para uma VNet isolada. Em um cenário recente que eu presenciei, o time atingiu o limite justamente porque o limite efetivo não era calculado apenas pela VNet local. O consumo dos Private Endpoints nas VNets pareadas também entrava na conta da malha. Ou seja, a leitura local parecia confortável, mas o total efetivo da malha já estava pressionado. Esse tipo de situação é muito plausível em arquiteturas com rede central, múltiplos serviços PaaS privados e crescimento progressivo por produto ou domínio. A própria documentação recomenda verificar o total de endpoints conectados à malha central antes de concluir se é preciso escalar.
Existe a possibilidade de escalar com High Scale Private Endpoints, mas esse ajuste precisa ser planejado. A Microsoft informa que habilitar ou desabilitar a funcionalidade provoca um platform update com one-time connection reset nas conexões privadas de longa duração, e recomenda fazer isso em janela de manutenção.
Ponto de atenção
Private Endpoint não cresce só com “mais um endpoint”.
Em malhas com peering, o limite relevante pode estar no conjunto das redes conectadas.
4) DNS privado: o teto aparece na operação, não só no desenho
Quando o uso de Private Endpoint cresce, o DNS privado cresce junto. E aí começam os limites que parecem pequenos só no início. Em Private DNS, a Microsoft documenta 1.000 zonas privadas por subscription, 25.000 record sets por zona, 1.000 virtual network links por zona, 100 links com autoregistration habilitado e apenas uma zona com autoregistration por VNet.
Isso pesa bastante em ambientes com múltiplos serviços privados, naming segmentado, várias VNets e integração híbrida. O gargalo deixa de ser “criar zona” e passa a ser governar links, autoregistration e padrão de resolução. Em outras palavras, o DNS privado não é só detalhe de conectividade; ele é parte do desenho de escala da plataforma.
5) RBAC: o limite que denuncia acesso mal distribuído
Em ambiente enterprise, RBAC também escala — e escala mal quando o modelo é muito granular. A Microsoft informa que Azure suporta até 4.000 role assignments por subscription e 500 role assignments por management group, sendo que esse limite de management group é fixo e não pode ser aumentado.
Esse número importa porque ele costuma revelar um problema estrutural: excesso de permissões atribuídas individualmente, em muitos escopos, para muitos objetos. Quando a subscription se aproxima do teto, normalmente o problema não é apenas “quantidade”. O problema é falta de padronização por grupos, papéis reutilizáveis e governança de acesso mais saudável. A própria documentação de troubleshooting orienta consolidar assignments e reduzir redundâncias.
6) Azure Policy: governança também precisa escalar direito
Azure Policy é outro tema que parece ilimitado até a governança amadurecer de verdade. A Microsoft documenta 500 policy definitions por escopo, 200 initiative definitions por escopo, 200 assignments por escopo, 1.000 exemptions e até 1.000 políticas dentro de uma initiative. Também há limite de 50.000 recursos por remediation task.
Na prática, esses números são menos sobre “bater teto” e mais sobre sinal de desenho. Quando o ambiente cresce com policies demais, initiatives pouco reutilizadas, assignments espalhados e muitas exceções, a governança vira peso operacional. Em enterprise, um bom desenho de Policy depende menos de volume bruto e mais de organização por escopo, iniciativa e padrão de exceção.
7) Azure Monitor: alerta demais também é problema
Observabilidade é outra área em que os limites ajudam a revelar maturidade. A Microsoft documenta 5.000 metric alert rules ativas por subscription, 5.000 log alert rules ativas por subscription e apenas 100 activity log alert rules por subscription, sendo que esse último limite não pode ser aumentado. Também existem 1.000 alert processing rules por subscription.
Em ambiente enterprise, isso importa porque a tendência natural é multiplicar alertas conforme o número de times, subscriptions e serviços cresce. O problema é que alerta demais não significa observabilidade melhor. Muitas vezes significa duplicação de regra, pouca padronização e uma malha difícil de manter. O limite de activity log alerts deixa claro que algumas estratégias precisam ser consolidadas e não apenas replicadas indefinidamente.
O que esses limites têm em comum
O ponto em comum entre esses exemplos é simples: eles não são só números. Eles revelam até onde o desenho atual continua saudável. Em alguns casos, como vCPU, a saída pode ser aumento de quota regional ou por família. Em outros, como RBAC muito fragmentado, Azure Policy muito espalhado ou DNS privado sem padrão, o limite é mais um sintoma de arquitetura e operação do que uma falta de capacidade bruta. A própria Microsoft diferencia limites ajustáveis e limites fixos exatamente porque nem todo problema de escala se resolve com request.
Conclusão
Em Azure, quotas e limites fazem parte da arquitetura tanto quanto rede, segurança e governança. Em ambiente enterprise, os casos que mais aparecem não estão só na conectividade. Eles passam por compute, DNS, acesso, políticas e observabilidade. Ignorar esse tema costuma cobrar um preço ruim: a plataforma para de escalar do jeito que foi desenhada, justamente quando mais se precisa dela.
A melhor forma de usar esse assunto em arquitetura não é montar uma tabela infinita. É identificar, com antecedência, quais limites são mais prováveis no seu contexto e tratá-los como parte do modelo operacional da plataforma.
