Azure VMSS: escalá tus VMs solas según la demanda
Ponele que armás el front-end de tu e-commerce, lo lanzás, y el día de la promo te entran 10 veces más visitas de lo normal. Con una máquina virtual sola, o pagaste de más todo el año esperando ese pico, o se te cae el sitio justo cuando más vendías. Azure Virtual Machine Scale Sets (VMSS) resuelve eso: te deja correr un grupo de VMs idénticas que crecen o se achican solas según la demanda, todo desde una sola configuración. Microsoft lo documentó en detalle el 14 de junio de 2026.
En 30 segundos
- Qué es: un grupo de VMs idénticas en Azure que escalan solas, creadas desde una única configuración e imagen base.
- Dos modos: Uniforme (todas iguales, más previsible) y Flexible (podés mezclar tamaños y reducir costos), que es el modo recomendado por Microsoft para proyectos nuevos.
- Cómo escala: por métricas como CPU promedio, memoria o longitud de cola, con umbrales y períodos de enfriamiento que vos definís.
- Se crea en minutos con
az vmss createo desde el Portal, y te genera claves SSH y Load Balancer asociado. - Errores típicos: AllocationFailed por falta de recursos, QuotaExceeded por límites de la suscripción y autoescalado que no se dispara por reglas mal puestas.
¿Cuándo conviene usar VMSS en lugar de máquinas virtuales sueltas?
El caso clásico es una carga sin estado que necesita crecer rápido. Si tenés una app web, una API REST o microservicios en contenedores donde cualquier instancia puede atender cualquier request, VMSS es para vos.
Pensá en el front-end de un e-commerce durante un Black Friday. Una VM única tiene un techo: cuando se llena, se llena, y no hay magia que la haga atender más tráfico del que su CPU aguanta. Con un conjunto de escalado, en cambio, definís que arranque con 2 instancias y pueda llegar hasta 20 si el tráfico aprieta. Cuando pasa el pico, se achica solo y dejás de pagar VMs ociosas.
Otros escenarios donde encaja bien:
- Procesamiento batch: tareas pesadas que corren en paralelo y después liberás los recursos.
- Análisis en tiempo real: donde la cantidad de workers depende del volumen de datos que entra.
- APIs sin estado: cualquier backend donde no importa qué instancia atiende, porque el estado vive en otro lado (base de datos, cache, cola).
¿Cuándo NO usarlo? Si tu app guarda estado local en disco y cada instancia es distinta, VMSS te va a complicar más de lo que ayuda. Para eso seguí con VMs individuales o repensá la arquitectura. Complementá con explorar el ecosistema de Microsoft.
¿Cómo funciona el escalado automático en un conjunto de escalado?
VMSS hace escalado horizontal: en vez de agrandar una máquina, suma o resta máquinas. Vos definís una capacidad mínima, una máxima y reglas que disparan el cambio.
Las métricas que podés usar para decidir cuándo escalar:
- CPU promedio: la más común. Por ejemplo, si supera el 70% sostenido, sumá instancias.
- Memoria: útil para cargas que consumen RAM más que procesador.
- Longitud de cola personalizada: ideal para workers que procesan mensajes de una cola.
- Tráfico de red: bytes de entrada o salida cuando el cuello de botella es el ancho de banda.
Acá viene lo importante: el cooldown period (período de enfriamiento). Es el tiempo que Azure espera después de un cambio antes de evaluar otro. Sin esto, una métrica que oscila te haría sumar y restar instancias sin parar, lo que en la jerga se llama “flapping”. Un valor típico anda por los 5 minutos. Todo se apoya en Azure Monitor, que es de donde VMSS lee esas métricas.
¿Cuál es la diferencia entre el modo Uniforme y el Flexible?
Azure tiene dos modos de orquestación, y elegir bien al principio te ahorra dolores de cabeza después.
El modo Uniforme trata a todas las instancias como idénticas: misma imagen, mismo tamaño de VM, misma config. Es más previsible y fue el original. El modo Flexible te deja mezclar tamaños de VM dentro del mismo conjunto, lo que abre la puerta a optimizar costos (por ejemplo, combinar instancias spot más baratas con instancias regulares). Flexible es el modo que Microsoft recomienda para los proyectos nuevos.
| Característica | Modo Uniforme | Modo Flexible |
|---|---|---|
| Tamaños de VM | Todos idénticos | Se pueden mezclar |
| Previsibilidad | Alta | Media |
| Optimización de costos | Limitada | Mayor (spot + regular) |
| Recomendado para proyectos nuevos | No | Sí |
| Mejor para | Cargas homogéneas | Cargas mixtas y ahorro |

Si recién arrancás y tu carga es pareja, Uniforme alcanza y sobra. Si querés exprimir costos mezclando tipos de instancia, Flexible es el camino. Te puede servir nuestra cobertura de implementar seguridad robusta en la nube.
¿Cómo crear un conjunto de escalado con Azure CLI y el Portal?
Por CLI es la vía más rápida y la que conviene si vas a versionar tu infraestructura. El comando base es az vmss create. Los parámetros clave:
- –resource-group: el grupo de recursos donde vive el VMSS.
- –name: el nombre del conjunto.
- –image: la imagen base (por ejemplo, Ubuntu o Windows Server).
- –orchestration-mode flexible: elegís el modo, Flexible o Uniform.
Cuando corrés ese comando, Azure te genera las claves SSH automáticamente y arma un Load Balancer asociado al conjunto, así no tenés que configurarlo aparte. Microsoft tiene un tutorial paso a paso por CLI que cubre la creación y administración completa.
Por el Portal el flujo es visual: buscás “Virtual Machine Scale Sets”, completás el formulario (grupo de recursos, imagen, tamaño, capacidad inicial) y listo. Es más cómodo para entender qué hace cada opción, pero menos repetible. Para producción seria, CLI o plantillas.
¿Cómo configurar reglas de escalado basadas en métricas?
Acá es donde el conjunto pasa de ser un grupo de VMs a algo que respira con tu tráfico. Las reglas se arman dentro de un perfil de escalado automático.
Un ejemplo concreto y bastante estándar:
- Escalar hacia afuera (sumar): si la CPU promedio supera el 70% durante 5 minutos, agregá 1 instancia.
- Escalar hacia adentro (restar): si la CPU promedio baja del 30% durante 10 minutos, quitá 1 instancia.
Fijate que el umbral para reducir (30%) está bastante por debajo del umbral para sumar (70%). Eso es a propósito. Si los dos valores estuvieran pegados, el conjunto entraría en ese flapping del que hablábamos antes: suma una instancia, la métrica baja, la saca, la métrica sube, la vuelve a poner. Dejar un margen amplio entre ambos umbrales evita ese baile.
El tema es que mucha gente arma las reglas pero se olvida del período de enfriamiento o le pone un valor muy chico. Si lo dejás en cero, cada evaluación dispara un cambio. Poné al menos unos minutos. Tema relacionado: automatizar tus procesos de deployment.
¿Cómo integrar Azure Load Balancer con un VMSS?
De nada sirve tener 10 instancias si todo el tráfico le pega a una sola. Ahí entra el balanceador. Azure Load Balancer reparte las peticiones entre las instancias del conjunto, por defecto con round-robin.
La pieza clave son los health probes (sondas de salud). El balanceador chequea cada instancia cada cierto tiempo; si una no responde, deja de mandarle tráfico hasta que se recupera. Así una instancia colgada no se traga requests que después fallan.
¿Y cuándo uso Application Gateway en vez de Load Balancer? Buena pregunta. La diferencia es la capa:
- Azure Load Balancer (capa 4): trabaja a nivel TCP/UDP. Rápido, simple, sin entender el contenido HTTP.
- Application Gateway (capa 7): entiende HTTP, hace ruteo por URL, terminación SSL y tiene WAF. Más completo, más caro.
Si tu necesidad es repartir tráfico y nada más, Load Balancer zafa de sobra. Si necesitás rutear por path o cortar el SSL en el borde, Application Gateway. Y si estás montando toda esta infraestructura y todavía no definiste dónde alojar tu sitio o tus dominios en Argentina, donweb.com tiene opciones de hosting y cloud locales.
Errores comunes al usar Azure VMSS
Estos son los que se repiten en producción, no las obviedades del manual:
- AllocationFailed / ZonalAllocationFailed: Azure no tiene capacidad en esa región o zona para el tamaño de VM que pediste. Probá otro tamaño, otra zona o esperá. Pasa más seguido con SKUs específicos en regiones chicas.
- QuotaExceeded: chocaste con el límite de núcleos de tu suscripción. No es un error de Azure, es tu cuota. Pedí un aumento de cuota desde el portal antes de escalar fuerte.
- VMExtensionProvisioningError: falló una extensión al instalarse (por ejemplo, un script de inicialización). Revisá los logs de la extensión, casi siempre es un comando que devuelve error o una dependencia que no estaba.
- El autoescalado no se dispara: el caso más frustrante. Suele ser que la métrica está mal configurada, el umbral nunca se cumple, o el cooldown es tan largo que parece que no hace nada. Verificá en Azure Monitor que la métrica esté llegando.
- Red mal configurada: la VNet o las subnets sin el espacio de direcciones suficiente para la cantidad máxima de instancias. Si pusiste máximo 50 pero la subnet da para 20, no vas a llegar nunca.
Preguntas Frecuentes
¿Qué es un conjunto de escalado de máquinas virtuales en Azure?
Es un recurso de cómputo de Azure que crea y administra un grupo de máquinas virtuales idénticas, balanceadas y creadas desde la misma imagen base. Su función es escalar el número de instancias de forma automática según la demanda o un calendario, y distribuirlas entre zonas de disponibilidad para tolerar fallas.
¿Cómo funciona el escalado automático en Azure VMSS?
Funciona por escalado horizontal: suma o resta instancias según reglas basadas en métricas como CPU promedio, memoria o longitud de cola. Vos definís capacidad mínima y máxima, umbrales (por ejemplo, sumar si CPU supera 70% durante 5 minutos) y un período de enfriamiento para evitar cambios constantes. En seleccionar la herramienta CI/CD correcta profundizamos sobre esto.
¿Cuál es la diferencia entre una VM individual y un VMSS?
Una VM individual tiene capacidad fija: cuando se satura, no atiende más tráfico. Un VMSS administra varias VMs idénticas que crecen o se achican solas según la demanda, con balanceo de carga y alta disponibilidad incluidos desde una sola configuración.
¿Cómo se crea un VMSS con Azure CLI?
Con el comando az vmss create, indicando el grupo de recursos (–resource-group), el nombre (–name), la imagen base (–image) y el modo de orquestación (–orchestration-mode flexible). Azure genera las claves SSH y arma el Load Balancer asociado de forma automática.
¿Cuál es el modo de orquestación recomendado en Azure VMSS?
Para los proyectos nuevos, Microsoft recomienda el modo Flexible. Permite mezclar distintos tamaños de VM en el mismo conjunto, a diferencia del modo Uniforme, donde todas las instancias son idénticas.
Conclusión
Azure VMSS resuelve un problema viejo y caro: cómo bancar picos de tráfico sin pagar VMs ociosas el resto del tiempo. Si tu carga es sin estado (web, API, workers de cola), es de las herramientas más directas que tiene Azure para escalar sin reescribir la app.
El consejo práctico: arrancá con modo Flexible, definí bien tus métricas en Azure Monitor antes de poner reglas, y dejá margen amplio entre los umbrales de subir y bajar para no entrar en flapping. Y revisá tu cuota de núcleos antes de configurar un máximo ambicioso, porque el QuotaExceeded llega justo cuando más necesitás escalar. Probalo primero en un grupo de recursos de prueba, mirá cómo reacciona ante un pico simulado, y recién después llevalo a producción.
Fuentes
- Microsoft Learn – Información general sobre conjuntos de escalado de máquinas virtuales
- Microsoft Learn – Información general sobre el escalado automático
- Microsoft Learn – Crear y administrar un VMSS con Azure CLI
- Dev.to – Azure Virtual Machine Scale Sets (VMSS): A Complete Guide
- TecnetOne – Azure Virtual Machine Scale Sets: escalado eficiente






