Un hilo de r/AZURE de esta semana (40 comentarios) buscaba una base de datos chica en West Europe y no encontraba ningún tamaño disponible; en las respuestas se mezclaban capacidad, tamaños en retiro y cuota. Azure devuelve tres errores distintos que desde el portal parecen el mismo: AllocationFailed, SkuNotAvailable y el de cuota, OperationNotAllowed. Cada uno tiene otra causa y otro arreglo, y sólo uno puede resolverse reintentando. Es el equivalente en Azure del "Out of host capacity" de OCI, que tiene su nota con un loop de reintentos. Todo lo que sigue sale de learn.microsoft.com; las fuentes están al final.

Los tres errores

  • AllocationFailed o ZonalAllocationFailed: "Allocation failed. We do not have sufficient capacity for the requested VM size in this region". Es capacidad: en ese momento no hay hosts libres para ese tamaño en la región o la zona. Aparece al crear, al arrancar una VM desasignada (deallocated) o al cambiarle el tamaño. Es el único que puede resolverse reintentando.
  • SkuNotAvailable: "The requested size for resource … is currently not available in location … zones … for subscription …". El tamaño no se le ofrece a tu suscripción en esa región o zona. Con una plantilla ARM o Bicep llega como InvalidTemplateDeployment en la validación: el deployment no arranca y el error queda sólo en el activity log. Reintentar no cambia nada.
  • Cuota: OperationNotAllowed con "Operation results in exceeding quota limits of Core. Maximum allowed: 4, Current in use: 4, Additional requested: 2". Es un límite de tu suscripción, no falta de hardware: se arregla pidiendo más cuota o liberando vCPUs.

Microsoft lo dice en su página de cuotas: Azure chequea cuota y capacidad por separado. Tener cuota de sobra no garantiza capacidad, y que haya capacidad no sirve si la cuota está llena.

SkuNotAvailable: leer la restricción en vez de adivinar

El portal sólo muestra los tamaños que pasan; no dice por qué falta el resto. az vm list-skus con --all incluye los que no están disponibles para tu suscripción y muestra la restricción:

# tamaños de la familia B en la región, incluidos los restringidos az vm list-skus --location westeurope --size Standard_B --all --output table # el objeto de restricción de un tamaño puntual az vm list-skus --location westeurope --size Standard_B2s --all \ --query "[?name=='Standard_B2s'].restrictions" # sólo VMs, con el detalle por zona az vm list-skus --location westeurope --resource-type virtualMachines --zone --all --output table

La columna Restrictions (en JSON, el campo restrictions que devuelve la API Resource Skus) trae los dos datos que deciden qué hacer:

  • type: Location si el tamaño está restringido en toda la región, Zone si sólo en algunas zonas. En ese caso restrictionInfo.zones lista las zonas cerradas, y las otras pueden aceptar el tamaño.
  • reasonCode: en el caso que muestra la documentación, NotAvailableForSubscription: la región no le ofrece ese tamaño a tu suscripción.

Si el tamaño está restringido en toda la región y lo necesitás ahí, Microsoft indica pedirlo a soporte con un SKU request. Si sólo está restringido en una zona, la salida es otra zona o sacar la restricción de zona. Las VMs Spot también dan SkuNotAvailable cuando no hay capacidad Spot en la región. Para Azure Database for PostgreSQL Flexible Server, el equivalente es az postgres flexible-server list-skus --location <región>.

Cuota: dos niveles por región, y las VMs apagadas también cuentan

La cuota de vCPUs tiene dos niveles por suscripción y por región: Total Regional vCPUs y una cuota por familia (por ejemplo, Standard DSv3 Family vCPUs), además de un tope de cantidad de VMs. Una VM nueva tiene que entrar en las dos cuotas de vCPU. Un detalle que confunde: la cuota se calcula con los cores en uso, asignados y desasignados, así que una VM detenida (deallocated) sigue ocupando cuota aunque no cobre cómputo.

# uso y límite de cada cuota de cómputo en la región az vm list-usage --location westeurope --output table

Se arregla con un pedido de aumento (Subscription → Usage + quotas) o borrando las VMs que no se usan; desasignarlas no alcanza.

AllocationFailed: qué cambiar según el caso

  • VM suelta (sin availability set ni proximity placement group): reintentar más tarde, otro tamaño u otra región o zona. Microsoft lo presenta como solución temporal hasta que haya capacidad.
  • Availability set: agregar una VM, cambiar el tamaño o arrancar sólo parte de las VMs desasignadas se le pide al cluster original del set, que puede no tener lugar. Detener (deallocate) todas las VMs del set y arrancarlas juntas deja que la asignación busque en todos los clusters.
  • Zonas: crear la VM desde un snapshot del disco del sistema en otra zona, o sin restricción de zona, abre la asignación a toda la región.
  • OverconstrainedAllocationRequest u OverconstrainedZonalAllocationRequest: la combinación de requisitos no entra. Microsoft nombra accelerated networking, zona, disco efímero, proximity placement group y discos Ultra o Premium SSD v2; sacar uno puede alcanzar aunque haya capacidad del tamaño.
  • Tamaños viejos (Av1, Dv1, DSv1, D15v2, DS15v2): no corren en el hardware nuevo y fallan más seguido. La recomendación es pasar a Av2, Dv3/DSv3 o Ev3/ESv3.

Si la capacidad tiene que estar sí o sí, existe la On-demand Capacity Reservation: reserva el lugar por adelantado, pero se cobra a la tarifa de la VM aunque la reserva no se use.

Un reintento que no pierde horas en lo que no se arregla

Antes de dejar un loop reintentando, conviene descartar los dos errores que no cambian con el tiempo: list-usage para ver si es cuota y list-skus --all para ver si el tamaño está restringido. Recién ahí tiene sentido reintentar, rotando tamaños de la misma familia. Este ejemplo prueba tres tamaños sobre una VM existente y saltea los que figuran restringidos; az vm resize reinicia la VM si está corriendo:

RG=mi-rg; VM=mi-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 restringido ($r), sigo"; continue; } az vm resize -g $RG -n $VM --size $size && break done

Lo que hace Control Cloud con estos errores

Cuando un deploy falla, el decodificador de errores de Control Cloud traduce SkuNotAvailable y QuotaExceeded a una explicación con el comando de solo lectura para confirmarlo (az vm list-skus y az vm list-usage). Todavía no reconoce AllocationFailed ni el OperationNotAllowed de cuota de cores, y el pre-flight no consulta cuota ni SKUs de Azure antes de desplegar: hoy eso son los comandos de esta nota. Para conectar una suscripción con permisos de lectura están la guía de Azure y la nota del service principal de solo lectura. Si querés probarlo, pedí acceso.

Fuentes

  • Microsoft Learn, "Troubleshooting Azure VM allocation failures" (AllocationFailed, ZonalAllocationFailed, availability sets, zonas, Overconstrained y tamaños viejos).
  • Microsoft Learn, "SKU not available errors" (SkuNotAvailable, InvalidTemplateDeployment, az vm list-skus --all, Spot).
  • Microsoft Learn, referencia de la API "Resource Skus - List" (restrictions: type Location o Zone, reasonCode, restrictionInfo.zones).
  • Microsoft Learn, "vCPU quotas" (dos niveles, cuota y capacidad por separado, cores asignados y desasignados, az vm list-usage) y "Resource quota errors" (OperationNotAllowed).
  • Microsoft Learn, "On-demand Capacity Reservation" (se cobra a la tarifa de la VM aunque no se use) y la referencia de az postgres flexible-server list-skus.
  • En este repositorio: el diccionario de errores del backend (errordict.go).