Um tópico do r/AZURE desta semana (40 comentários) procurava um banco de dados pequeno em West Europe e não achava nenhum tamanho disponível; nas respostas se misturavam capacidade, tamanhos em descontinuação e cota. O Azure devolve três erros diferentes que pelo portal parecem o mesmo: AllocationFailed, SkuNotAvailable e o de cota, OperationNotAllowed. Cada um tem outra causa e outra correção, e só um pode ser resolvido tentando de novo. É o equivalente no Azure do "Out of host capacity" da OCI, que tem a sua nota com um loop de retentativas. Tudo o que segue sai de learn.microsoft.com; as fontes estão no final.

Os três erros

  • AllocationFailed ou ZonalAllocationFailed: "Allocation failed. We do not have sufficient capacity for the requested VM size in this region". É capacidade: naquele momento não há hosts livres para esse tamanho na região ou na zona. Aparece ao criar, ao iniciar uma VM desalocada (deallocated) ou ao mudar o tamanho dela. É o único que pode ser resolvido tentando de novo.
  • SkuNotAvailable: "The requested size for resource … is currently not available in location … zones … for subscription …". O tamanho não é oferecido à sua assinatura nessa região ou zona. Com um template ARM ou Bicep chega como InvalidTemplateDeployment na validação: o deployment não começa e o erro fica só no activity log. Tentar de novo não muda nada.
  • Cota: OperationNotAllowed com "Operation results in exceeding quota limits of Core. Maximum allowed: 4, Current in use: 4, Additional requested: 2". É um limite da sua assinatura, não falta de hardware: resolve-se pedindo mais cota ou liberando vCPUs.

A Microsoft diz isso na página de cotas: o Azure verifica cota e capacidade separadamente. Ter cota de sobra não garante capacidade, e haver capacidade não adianta se a cota estiver cheia.

SkuNotAvailable: ler a restrição em vez de adivinhar

O portal só mostra os tamanhos que passam; não diz por que falta o resto. az vm list-skus com --all inclui os que não estão disponíveis para a sua assinatura e mostra a restrição:

# tamanhos da família B na região, incluindo os restritos az vm list-skus --location westeurope --size Standard_B --all --output table # o objeto de restrição de um tamanho específico az vm list-skus --location westeurope --size Standard_B2s --all \ --query "[?name=='Standard_B2s'].restrictions" # só VMs, com o detalhe por zona az vm list-skus --location westeurope --resource-type virtualMachines --zone --all --output table

A coluna Restrictions (em JSON, o campo restrictions que a API Resource Skus devolve) traz os dois dados que decidem o que fazer:

  • type: Location se o tamanho está restrito em toda a região, Zone se só em algumas zonas. Nesse caso restrictionInfo.zones lista as zonas fechadas, e as outras podem aceitar o tamanho.
  • reasonCode: no caso que a documentação mostra, NotAvailableForSubscription: a região não oferece esse tamanho à sua assinatura.

Se o tamanho está restrito em toda a região e você precisa dele ali, a Microsoft indica pedi-lo ao suporte com um SKU request. Se está restrito só em uma zona, a saída é outra zona ou tirar a restrição de zona. As VMs Spot também dão SkuNotAvailable quando não há capacidade Spot na região. Para o Azure Database for PostgreSQL Flexible Server, o equivalente é az postgres flexible-server list-skus --location <região>.

Cota: dois níveis por região, e as VMs paradas também contam

A cota de vCPUs tem dois níveis por assinatura e por região: Total Regional vCPUs e uma cota por família (por exemplo, Standard DSv3 Family vCPUs), além de um teto de quantidade de VMs. Uma VM nova tem que caber nas duas cotas de vCPU. Um detalhe que confunde: a cota é calculada com os cores em uso, alocados e desalocados, então uma VM parada (deallocated) continua ocupando cota mesmo sem cobrar compute.

# uso e limite de cada cota de compute na região az vm list-usage --location westeurope --output table

Resolve-se com um pedido de aumento (Subscription → Usage + quotas) ou apagando as VMs que ninguém usa; desalocá-las não basta.

AllocationFailed: o que mudar em cada caso

  • VM avulsa (sem availability set nem proximity placement group): tentar de novo mais tarde, outro tamanho ou outra região ou zona. A Microsoft apresenta isso como solução temporária até haver capacidade.
  • Availability set: adicionar uma VM, mudar o tamanho ou iniciar só parte das VMs desalocadas é pedido ao cluster original do set, que pode não ter espaço. Parar (deallocate) todas as VMs do set e iniciá-las juntas deixa a alocação procurar em todos os clusters.
  • Zonas: criar a VM a partir de um snapshot do disco do sistema em outra zona, ou sem restrição de zona, abre a alocação para toda a região.
  • OverconstrainedAllocationRequest ou OverconstrainedZonalAllocationRequest: a combinação de requisitos não cabe. A Microsoft cita accelerated networking, zona, disco efêmero, proximity placement group e discos Ultra ou Premium SSD v2; tirar um deles pode bastar mesmo havendo capacidade do tamanho.
  • Tamanhos antigos (Av1, Dv1, DSv1, D15v2, DS15v2): não rodam no hardware novo e falham com mais frequência. A recomendação é passar para Av2, Dv3/DSv3 ou Ev3/ESv3.

Se a capacidade tem que estar lá de qualquer jeito, existe a On-demand Capacity Reservation: reserva o espaço com antecedência, mas é cobrada pela tarifa da VM mesmo quando a reserva não é usada.

Uma retentativa que não perde horas no que não se resolve

Antes de deixar um loop tentando de novo, vale descartar os dois erros que não mudam com o tempo: list-usage para ver se é cota e list-skus --all para ver se o tamanho está restrito. Só então faz sentido tentar de novo, alternando tamanhos da mesma família. Este exemplo testa três tamanhos em uma VM existente e pula os que aparecem como restritos; az vm resize reinicia a VM se ela estiver rodando:

RG=meu-rg; VM=minha-vm; LOC=westeurope for size in Standard_D2as_v5 Standard_D2s_v5 Standard_D2ads_v5; do r=$(az vm list-skus -l $LOC --size $size --all \ --query "[?name=='$size'].restrictions[0].type" -o tsv) [ -n "$r" ] && { echo "$size restrito ($r), próximo"; continue; } az vm resize -g $RG -n $VM --size $size && break done

O que o Control Cloud faz com esses erros

Quando um deploy falha, o decodificador de erros do Control Cloud traduz SkuNotAvailable e QuotaExceeded em uma explicação com o comando somente leitura para confirmá-lo (az vm list-skus e az vm list-usage). Ainda não reconhece AllocationFailed nem o OperationNotAllowed de cota de cores, e o pre-flight não consulta cota nem SKUs do Azure antes de implantar: hoje é para isso que servem os comandos desta nota. Para conectar uma assinatura com permissões de leitura, há o guia do Azure e a nota do service principal somente leitura. Se quiser testar, peça acesso.

Fontes

  • Microsoft Learn, "Troubleshooting Azure VM allocation failures" (AllocationFailed, ZonalAllocationFailed, availability sets, zonas, Overconstrained e tamanhos antigos).
  • Microsoft Learn, "SKU not available errors" (SkuNotAvailable, InvalidTemplateDeployment, az vm list-skus --all, Spot).
  • Microsoft Learn, referência da API "Resource Skus - List" (restrictions: type Location ou Zone, reasonCode, restrictionInfo.zones).
  • Microsoft Learn, "vCPU quotas" (dois níveis, cota e capacidade verificadas separadamente, cores alocados e desalocados, az vm list-usage) e "Resource quota errors" (OperationNotAllowed).
  • Microsoft Learn, "On-demand Capacity Reservation" (cobrada pela tarifa da VM mesmo sem uso) e a referência de az postgres flexible-server list-skus.
  • Neste repositório: o dicionário de erros do backend (errordict.go).