Cómo reducir costos en Azure sin poner en riesgo la estabilidad

Una estación de trabajo en Azure puede necesitar mucha capacidad durante la jornada y ninguna durante la noche. Si permanece encendida, la factura crece sin mejorar el servicio; si se apaga sin conocer sus dependencias, el equipo puede quedarse sin acceso. Cuando terminan los créditos promocionales, ese consumo se vuelve visible en la primera factura. En Eximus abordamos el problema con infraestructura versionada, automatización por demanda y comprobaciones de continuidad. Este caso describe el diseño aplicado en nuestro entorno interno, sin exponer su inventario, accesos ni costos privados.

El problema real: el consumo y la disponibilidad siguen relojes distintos

Nuestro entorno reúne estaciones de trabajo virtuales y servicios compartidos de identidad, conectividad y aplicaciones. Una estación puede dejar de usarse mientras un servicio compartido sigue siendo necesario para otra persona o para una ventana operativa protegida. A la vez, una VM detenida desde el sistema operativo puede seguir reservando cómputo. Microsoft distingue la desasignación, que libera el cómputo, del estado detenido que puede seguir facturándolo.

La decisión no era simplemente reducir tamaños. Había que responder, para cada recurso: quién lo necesita, durante qué ventana, de qué servicios depende, cómo se confirma su estado y qué sucede si un arranque falla. El objetivo fue conservar la capacidad disponible cuando hace falta y evitar pagar cómputo cuando no existe demanda. Los discos, la red, las copias y otros servicios pueden seguir generando cargos aunque la VM esté desasignada; por eso medimos la factura completa.

Caso Eximus: cuatro decisiones de arquitectura

1. Separar capacidad de tiempo de uso

Las estaciones conservan un tamaño operativo definido para su carga. El ciclo habitual de cierre las desasigna; el siguiente inicio valida el tamaño esperado y las arranca. Así se mantiene el mismo recurso lógico, sus datos y su configuración, mientras el cómputo deja de facturarse durante la inactividad. El cambio de tamaño se trata como una operación aparte, con métricas y ventana de cambio: un ajuste diario de talla no es requisito para ahorrar por horas apagadas.

2. Encender las dependencias en orden

Al solicitar una estación, un runbook de Azure Automation comprueba e inicia los servicios compartidos necesarios en secuencia y espera confirmación del estado de cada VM antes de continuar. Solo registra la sesión activa cuando la estación ya está funcionando. Al cerrar, desasigna la estación y actualiza el estado central de sesiones. Si era la última, evalúa las ventanas protegidas antes de detener servicios compartidos y lo hace en orden inverso. El resultado es un ciclo que sigue la demanda real sin interrumpir a otro usuario.

3. Mantener excepciones explícitas

No todos los recursos deben obedecer al mismo reloj. En el diseño interno, un servidor especializado opera bajo demanda mediante runbooks propios; un componente de agentes no tiene arranque automático por motivos de costo; y existe un apagado programado de salvaguarda para recursos elegibles. Las ventanas de conectividad conservan los servicios que necesitan. Estas decisiones están declaradas por recurso y se revisan cuando cambia la operación, en vez de asumir que una sola programación sirve para todo.

4. Tratar el almacenamiento por separado

También revisamos el costo persistente de los discos. Para estaciones elegibles se diseñó una política de cambio entre SSD operativo y HDD tras un período completo de inactividad, con restauración a SSD antes del siguiente arranque. El antecedente de migrar ciertos discos de Premium SSD a Standard SSD se ejecutó con inventario, piloto y verificación. La política de enfriamiento permanece acotada: no hay estaciones vigentes marcadas como elegibles, por lo que no la presentamos como una fuente de ahorro actual. El tipo de disco se decide según rendimiento, operaciones y costo, nunca solo por precio.

flowchart LR
  A["Solicitud y revisión / Request and review"] --> B["Git y Azure DevOps / Git and Azure DevOps"]
  B --> C["Terraform para recursos declarados / Terraform for declared resources"]
  B --> D["Runbooks PowerShell versionados / Versioned PowerShell runbooks"]
  C --> E["VM y red privada / VM and private network"]
  D --> F["Azure Automation e identidad administrada / Automation and managed identity"]
  F --> E
  F --> G["Estado de sesiones en Blob / Session state in Blob"]
  E --> H["Métricas de servicio / Service metrics"]
  E --> I["Azure Cost Management / Cost Management"]
  H --> J["Decisión y reversa / Decision and rollback"]
  I --> J

Cómo se implementó: el stack y la función de cada pieza

• Azure DevOps y Git guardan las solicitudes, la configuración, los runbooks, las revisiones y el historial de cambios. El flujo parte de un Work Item y pasa por validación y revisión antes de publicar una modificación operativa.
• Terraform define los componentes que pertenecen al módulo de aprovisionamiento, como la conectividad privada y su estado deseado, con backend remoto aislado por estación. La VM se crea desde una imagen controlada mediante un flujo de aprovisionamiento que también usa herramientas de Azure. No afirmamos que Terraform administre cada recurso histórico del entorno.
• Azure Compute, discos administrados y red privada aportan la estación y sus dependencias. Un perfil de máquina se fija según la carga, la cuota y las pruebas de rendimiento; el apagado operativo busca el estado deallocated.
• Azure Automation, PowerShell y Azure Az ejecutan los runbooks de inicio, cierre, secuencias de dependencias y salvaguardas. Las definiciones se generan desde configuración versionada; la publicación tiene vista previa antes de aplicarse.
• Identidad administrada, Azure RBAC y Blob Storage permiten operar con permisos acotados y guardar el estado compartido de sesiones. La actualización concurrente usa control de versión y reintentos para que dos solicitudes simultáneas no sobrescriban el inventario de usuarios activos.
• Azure Cost Management, métricas de Azure y señales de aplicación permiten comparar gasto y experiencia del usuario. Una consulta por VM debe incorporar sus discos y recursos asociados y declarar por separado los costos compartidos que no puede atribuir directamente.

La arquitectura depende de prerrequisitos concretos: inventario de recursos y propietarios, mapa de dependencias, ventanas de disponibilidad, permisos mínimos para la identidad de automatización, un almacén duradero para sesiones, cuotas suficientes para el reinicio, métricas de servicio y un procedimiento de reversa. La disponibilidad de una VM desasignada exige comprobar que podrá volver a asignarse cuando sea necesaria; la automatización confirma el estado en vez de asumirlo.

sequenceDiagram
  participant U as Usuario / User
  participant A as Azure Automation
  participant C as Servicios compartidos / Shared services
  participant W as Workstation
  participant S as Estado de sesiones / Session state
  U->>A: Solicita inicio / Requests start
  A->>C: Inicia dependencias en orden / Starts dependencies in order
  C-->>A: Confirma estado / Confirms state
  A->>W: Inicia VM / Starts VM
  W-->>A: Confirma estado / Confirms state
  A->>S: Registra sesion / Records session
  U->>A: Solicita cierre / Requests stop
  A->>W: Desasigna VM / Deallocates VM
  A->>S: Retira sesion / Removes session
  S-->>A: Ultima sesion y ventana protegida / Last session and protected window
  A->>C: Desasigna solo si procede / Deallocates only when allowed

El flujo operativo, de principio a fin

1. Establecer una línea base. Acordar período, moneda, alcance de recursos y base de costo real o amortizado. Registrar horas de uso, utilización, latencia, errores y demanda. Identificar cargos de cómputo, disco y servicios compartidos.
2. Diseñar la política por carga. Clasificar recursos en esenciales, dependientes, estaciones por demanda y servicios manuales. Definir secuencias de inicio y cierre, horarios protegidos, responsables y criterios para no apagar.
3. Versionar y validar. Declarar configuración y artefactos en Git. Validar la configuración, revisar el plan de publicación, probar arranques y cierres con escenarios de sesiones concurrentes y fallos antes de extender el cambio.
4. Operar con comprobaciones. Al iniciar, esperar el estado de cada dependencia. Al cerrar, confirmar la desasignación. Mantener una salvaguarda programada para recursos elegibles y registrar advertencias si una operación no llega al estado esperado.
5. Medir y ajustar. Comparar períodos equivalentes y costo por unidad de trabajo; revisar si aparecen retrasos de inicio, fallos de autenticación, degradación o costos desplazados. Conservar o revertir cada ajuste según resultados.

flowchart LR
  A["Visibilidad / Visibility"] --> B["Desperdicio / Waste"]
  B --> C["Ajuste / Rightsizing"]
  C --> D["Compromisos / Commitments"]

Qué significa «ahorro» en este caso

Hay tres efectos distintos. Desasignar elimina el cargo de cómputo durante horas sin uso, pero no todos los costos asociados. Cambiar un SKU altera el precio y puede alterar el rendimiento; exige una prueba independiente. Comprar una reserva o un Savings Plan cambia la facturación de demanda estable, pero no sustituye la corrección del desperdicio. Microsoft explica que el costo real y el amortizado presentan los compromisos de forma diferente. Mezclar esas vistas o períodos puede producir un porcentaje engañoso.

Para comunicar un resultado, usamos esta fórmula: reducción observada = (costo base comparable − costo posterior comparable) / costo base comparable × 100. La comparación debe fijar moneda, fechas, alcance, volumen de trabajo, descuentos y cargos compartidos, y revisar la estabilidad del servicio. Observación provisional: la captura compartida de Azure Cost Management para la suscripción principal muestra en septiembre de 2026, todavía abierto, un indicador de 22 % menos. Esta vista no equivale a una factura final ni atribuye la variación a una medida concreta. Tampoco demuestra que el inventario o la carga de trabajo fueran idénticos entre períodos. Para calcular y atribuir el ahorro neto se necesitan períodos cerrados, la misma base de costos, un alcance comparable y el desglose completo de cargos.

Lecciones de implementación que cambiaron el diseño

La transición desde créditos promocionales a facturación ordinaria expuso un problema adicional: las cuotas de una familia de VM no permitían completar el cambio de tamaño que hacían los runbooks antiguos. El equipo eliminó ese resize del ciclo diario, fijó tamaños operativos por estación y verificó la cuota antes de cambios posteriores. Una VM desasignada puede ahorrar cómputo, pero su siguiente inicio también necesita capacidad autorizada y disponible.

La auditoría descubrió automatizaciones heredadas que todavía podían apagar estaciones fuera del flujo nuevo. Se revisaron los disparadores existentes y se deshabilitaron los duplicados antes de confiar en los runbooks versionados como mecanismo operativo. Las pruebas también revelaron condiciones límite en el estado compartido de sesiones y discos; se corrigieron con validaciones, reintentos y comprobación del estado real. Este trabajo explica por qué un inventario de automatizaciones y pruebas de recuperación forman parte del proyecto de ahorro, no son tareas posteriores.

Controles que protegen la estabilidad

• No desasignar un servicio compartido solo porque una estación terminó: comprobar todas las sesiones y las ventanas protegidas.
• Confirmar el estado de energía de Azure después de iniciar o detener cada VM; una solicitud aceptada no equivale a un servicio disponible.
• Probar cuota, permisos y dependencias antes de activar una nueva estación o reducir un tamaño.
• Mantener cambios de disco y tamaño separados del apagado cotidiano, con reversa y métricas de rendimiento.
• Diferenciar errores de automatización de una degradación real de la aplicación y alertar al responsable.
• Revisar periódicamente la configuración versionada frente al estado real para evitar deriva.

Qué puede llevarse un cliente de este enfoque

El resultado reutilizable es un sistema de decisiones, no un horario copiado. Eximus puede levantar el mapa de consumo y dependencias, identificar recursos aptos para operación por demanda, diseñar la secuencia segura, versionar la automatización, aplicar permisos mínimos y verificar costo y experiencia del usuario. En cargas que deben estar disponibles de forma continua, la misma evaluación puede concluir que el apagado no corresponde y priorizar derechos de tamaño, almacenamiento o compromisos de consumo.

El entregable para finanzas incluye línea base, criterio de atribución y ahorro observado; para ingeniería, estado deseado, validaciones, riesgos y reversa. Ambos equipos revisan el mismo cambio y la misma evidencia.

Próximo paso

Si tu factura de Azure crece mientras tus patrones de uso tienen pausas claras, empieza por una revisión de recursos, dependencias y costo comparable. Conoce nuestra solución de optimización de costos y rendimiento, el servicio de optimización de costos en Azure o agenda una conversación para definir un primer bloque medible.