MSTech Geeks

Si trabajas con Azure y tienes máquinas virtuales que no necesitan estar encendidas 24/7 —entornos de desarrollo, testing, demos, laboratorios de formación—, seguro que ya te has hecho esta pregunta: ¿cómo evito pagar por cómputo que nadie está usando por las noches o los fines de semana?

La respuesta oficial de Microsoft para este escenario se llama Start/Stop VMs v2, y en este post vamos a repasar qué es, cómo funciona por dentro, cómo se despliega y qué cosas conviene tener en cuenta antes de ponerla en producción.

Documentación oficial de referencia: Start/Stop VMs v2 overview – Microsoft Learn

¿Qué es Start/Stop VMs v2?

De forma nativa y en el portal de Azure, tenemos una opción para parar las máquinas virtuales de manera individual, pero no para encenderlas, esto es lo que despista, por decirlo de alguna forma, a muchos técnicos. Pero sí, existe una forma de hacerlo y es con esta solución.

Es una solución que arranca y detiene máquinas virtuales de Azure según una programación horaria definida por el usuario, a través de múltiples suscripciones. Además:

• Da visibilidad mediante Azure Application Insights.
• Permite enviar notificaciones opcionales usando action groups.
• Es compatible con VMs de Azure Resource Manager (ARM) y también con VMs clásicas (Azure Service Manager), aunque este último modelo ya está deprecado en Azure en general.

Lo interesante de la «v2» es que es un rediseño completo respecto a la versión original: ya no depende de Azure Automation ni de Azure Monitor Logs. En su lugar, se apoya en Azure Functions para ejecutar las operaciones de arranque/parada, lo que la convierte en una opción de automatización descentralizada y de bajo coste.

Arquitectura: ¿qué se despliega realmente?

Para desplegar esta solución y si lo hacemos desde el portal (también se puede hacer desde el repositorio de github, completando un despliege por defecto), necesitamos acceder al Marketplace de Azure y buscar por «Start/Stop VMs during off hours – V2»

Cuando despliegas Start/Stop VMs v2 en tu suscripción, se crean varios componentes que trabajan juntos:

• Una Function App con identidad administrada (managed identity) en Microsoft Entra ID, que le permite acceder a otros recursos protegidos (Logic Apps, VMs) sin necesidad de credenciales almacenadas.
• Varias funciones internas, entre las que destacan:
  • Scheduled (HTTP): punto de entrada para los escenarios programados y secuenciados.
  • AutoStop (HTTP): punto de entrada para el apagado automático por uso de CPU.
  • AutoStopVM (HTTP): se dispara automáticamente cuando se cumple la condición de una alerta.
  • VirtualMachineRequestOrchestrator y VirtualMachineRequestExecutor (Queue): orquestan y ejecutan realmente el arranque/parada de la VM.
  • HeartBeatAvailabilityTest (Timer): monitoriza la disponibilidad de las funciones principales.
  • CostAnalyticsFunction y SavingsAnalyticsFunction (Timer): funciones que usa Microsoft internamente para estimar coste y ahorro agregado; no afectan a la funcionalidad de la solución.

• Cinco Logic Apps desplegadas por defecto, que son las que configuras y gestionas para definir tus horarios:
  • ststv2_vms_Scheduled_start / ststv2_vms_Scheduled_stop
  • ststv2_vms_Sequenced_start / ststv2_vms_Sequenced_stop
  • ststv2_vms_AutoStop
• Una cuenta de Azure Storage, usada para:
  • Table Storage: metadatos de cada operación de arranque/parada.
  • Queue Storage: soporte para los triggers de tipo cola de las Functions.

Toda la telemetría de ejecución se envía a Application Insights, y desde ahí puedes consultar un dashboard predefinido de Azure con visualizaciones ya montadas.

Los tres escenarios de automatización

Scheduled (programado)

El más simple: defines un horario y la solución arranca/para las VMs de un scope determinado (suscripción, resource group o lista de VMs) según ese calendario.

Sequenced (secuenciado)

Útil cuando el orden de arranque/parada importa (por ejemplo, primero la base de datos, luego el backend, luego el frontend). Se configura mediante dos tags en cada VM:

• sequencestart: valor entero de 1 a N que define el orden de arranque.
• sequencestop: valor entero que define el orden de parada.

Las VMs se procesan en orden ascendente según el valor del tag. Si dos VMs comparten el mismo valor, se arrancan/paran simultáneamente. Si una VM no tiene el tag, simplemente no participa en la secuencia.

Importante: este escenario solo es compatible con VMs de Azure Resource Manager, no con VMs clásicas.

AutoStop (Apagado automático por uso)

Este escenario detiene VMs (ARM o clásicas) en función de su utilización de CPU. Funciona creando una alerta de Azure Monitor sobre la VM; cuando la condición de la alerta se cumple, se dispara el apagado automáticamente.

Opciones de scoping (a qué VMs afecta)

Cada acción de Start/Stop admite tres formas de definir el alcance:

Opción	Cuándo usarla
Subscription	Quieres aplicar la acción a todas las VMs de una o varias suscripciones completas (con opción de excluir VMs concretas, incluso con wildcards).
Resource Group	Quieres limitar la acción a uno o varios resource groups específicos, en una o varias suscripciones.
VMList	Quieres apuntar a una lista concreta de VMs. Esta opción no admite exclusiones.

Requisitos previos

• Cuenta de Azure con una suscripción activa.
• Permisos de Owner a nivel de suscripción para poder desplegar la solución.
• Disponible en todas las regiones globales de Azure y en Azure US Government donde Azure Functions esté disponible.

Cómo se despliega (resumen rápido)

El despliegue se hace desde el repositorio oficial de GitHub del proyecto o bien directamente desde el marketplace, como hemos visto en el punto anterior de Arquitectura, mediante una plantilla ARM personalizada:

1. Accedes a la organización de GitHub de Start/Stop VMs v2 y eliges la opción correspondiente a tu nube (Azure público o US Government).
2. Eliges el plan: StartStopV2 (Function App en plan Consumption + Storage account localmente redundante) o StartStopV2-AZ (plan Elastic Premium con 3 instancias mínimas en zonas de disponibilidad, para escenarios que requieren alta disponibilidad).
3. Completas el formulario de despliegue en el portal de Azure y confirmas.
4. Una vez desplegado, si quieres gestionar VMs en otras suscripciones, debes asignar el rol correspondiente a la managed identity de la Function App en cada suscripción adicional (vía Access Control – IAM).
5. Configuras los Logic Apps (Scheduled, Sequenced, AutoStop) según tus necesidades de horario.
   

Para el detalle paso a paso, la guía oficial es Deploy Start/Stop VMs v2.

Puntos clave a tener en cuenta antes de adoptarla

Esto es importante y muchos posts sobre el tema no lo mencionan lo suficiente. Según la propia documentación de Microsoft, a día de hoy:

1. No habrá más desarrollo ni mejoras de Start/Stop v2, salvo lo estrictamente necesario para mantener el soporte de sus componentes y servicios de Azure subyacentes. Es decir: la solución sigue siendo válida y soportada, pero está en modo mantenimiento, no en evolución activa. Esto confunde a mucha gente, parece que estén deprecando la solución pero no es así.
2. Las funciones TriggerAutoUpdate y UpdateStartStopV2 están deprecadas y se eliminarán en el futuro. Si necesitas actualizar tu instancia, el procedimiento recomendado ahora es manual: detener el sitio, instalar la última versión desde el repositorio de GitHub y volver a arrancar el sitio. También puedes desactivar la auto-actualización poniendo la app setting AzureClientOptions:EnableAutoUpdate a false.
3. No existe un sistema de notificación integrado para avisarte de nuevas versiones disponibles: Microsoft actualiza el README.md del repositorio de GitHub, así que si quieres enterarte de cambios te toca vigilar el repo (o usar algún watcher de terceros).
4. Desde el 19 de agosto de 2024, la solución corre sobre el modelo aislado de .NET 8 (isolated worker model).

Recomendación: si vas a desplegar Start/Stop VMs v2 ahora, ten en cuenta que estás adoptando una solución estable pero congelada en cuanto a nuevas features, y que el proceso de actualización requiere intervención manual. Merece la pena documentar internamente en tu equipo cómo y cuándo revisar el repo de GitHub para no quedarte en una versión desactualizada de componentes.

Conclusión

Start/Stop VMs v2 sigue siendo, hoy en día, la solución nativa recomendada por Microsoft para automatizar el encendido/apagado de VMs y optimizar costes, especialmente frente a la v1 (basada en Azure Automation), que ya no recibe soporte de la comunidad. Su arquitectura basada en Azure Functions + Logic Apps la hace ligera y fácil de razonar, y sus tres escenarios (Scheduled, Sequenced, AutoStop) cubren la mayoría de casos de uso reales.

Eso sí: al estar en modo mantenimiento, es buena práctica tenerlo monitorizado y no asumir que se actualizará solo, especialmente ahora que las funciones de auto-actualización están camino de desaparecer.