Apaga dev y staging por la noche: cómo programarlo con AAA Sentinel y cuánto ahorras de verdad

A las ocho de la tarde el equipo cierra el portátil. Las máquinas de desarrollo y de staging, no: siguen encendidas toda la noche y todo el fin de semana, facturando cada hora aunque nadie las use. Es una de las fugas más fáciles de cerrar porque no exige cambiar ninguna arquitectura, sólo apagar y encender a su hora. En este artículo te contamos cómo hacerlo con AAA Sentinel: dónde encontrar los candidatos, cómo calcular el ahorro sin inflarlo y cómo dejar el apagado programado.

El problema: máquinas que trabajan 60 horas y cobran 168

Una semana tiene 168 horas. Un equipo que trabaja de lunes a viernes de 08:00 a 20:00 usa sus entornos 60 de ellas. Las otras 108, el 64 % de la semana, son noches y fines de semana en los que esas máquinas sólo generan factura:

• En AWS, una instancia EC2 detenida no paga cómputo. En Azure, una VM desasignada tampoco. En Google Cloud, una instancia detenida deja de pagar CPU y memoria.
• Lo que sí sigue cobrándose son los discos y algunas direcciones IP, como verás más abajo. Por eso el ahorro real es menor que el 64 % de la factura total del entorno.
• Nadie apaga a mano todos los días. Funciona una semana y después se olvida: el apagado tiene que estar programado.

Qué ganas con ello

Programar el apagado de los entornos que no son de producción tiene ventajas que van más allá de la cifra:

• Un ahorro recurrente que no depende de que alguien se acuerde.
• Ningún cambio en el código ni en la arquitectura: las máquinas son las mismas, sólo cambian sus horas encendidas.
• Una lista clara de qué es desarrollo y qué es producción, porque para programar el apagado tienes que decidirlo.
• Un registro de cada apagado y cada encendido, con el resultado, para saber que el plan se cumple.

Antes de empezar: lo que se paga aunque la máquina esté apagada

Para no prometer más de lo que vas a ver en la factura, ten en cuenta estos puntos:

• Los volúmenes EBS (y los discos gestionados en Azure o Google Cloud) se siguen cobrando con la instancia detenida.
• AWS cobra cada dirección IPv4 pública por horas, también una Elastic IP asociada a una instancia detenida.
• Si la instancia está cubierta por una Reserved Instance o un Savings Plan, apagarla no ahorra: el compromiso se paga igual.
• Al detener una instancia se pierde lo que haya en el almacenamiento de instancia (instance store), y la IP pública cambia en el siguiente arranque si no es una Elastic IP.
• Si la instancia forma parte de un grupo de Auto Scaling, el grupo puede considerarla no sana y sustituirla. Estas instancias no son buenas candidatas.

Cómo lo resuelve AAA Sentinel: tres piezas

El flujo completo usa tres pantallas, cada una en su plan:

• Hallazgos activos, en todos los planes: el escaneo detecta las instancias con CPU muy baja y las que ya están paradas con discos que siguen facturando. Es tu lista de candidatos.
• Simulador de ahorro, en el plan Pro: antes de tocar nada, calculas cuánto ahorraría apagar dev y staging por la noche.
• Agente IA → Automatizaciones, en el plan Business: creas el horario de apagado y encendido, y la plataforma lo ejecuta cada día y deja constancia en el historial.

Caso práctico: los entornos de ACME

ACME es una empresa ficticia con un equipo de desarrollo en Madrid. Tiene seis máquinas de desarrollo y dos de staging en AWS, en us-east-1, encendidas día y noche. Los precios son aproximados, de lista, bajo demanda y con Linux:

Paso 1: encontrar candidatos en Hallazgos activos

Después del primer escaneo de la cuenta, abre Hallazgos activos. Tres reglas te ayudan a localizar entornos que sobran por la noche:

• «CPU infrautilizada»: CPU media inferior al 5 % durante los últimos 7 días. Una máquina de desarrollo que sólo trabaja unas horas al día suele aparecer aquí.
• «Instancias paradas con volúmenes»: alguien ya la apagó a mano, pero sus discos siguen facturando. Decide si la vas a volver a usar (entonces, prográmala) o si sobra (entonces, termínala tras hacer snapshot si quieres conservar los datos).
• «Recursos sin etiquetas»: el recurso tiene menos de dos de estas etiquetas: Environment, Project, Owner, CostCenter o Team. Etiquetar Environment=dev o Environment=staging es lo que te permite separar después lo que se puede apagar de lo que no.

Paso 2: calcular el ahorro en el Simulador

En Resumen de ahorro → Simulador de ahorro, elige la cuenta y activa el escenario «Apagar Dev/Staging por la noche». Tiene dos campos:

• «Coste EC2 Dev (USD/mes)»: llega rellenado con el 40 % del coste total de la cuenta, que es sólo un punto de partida. Sustitúyelo por el coste real de tus máquinas de desarrollo y staging; ACME pone 645.
• «Horas apagado/día»: las horas que estarían apagadas cada día laborable. De 20:00 a 08:00 son 12.

Las cuentas completas, con el fin de semana

Con un horario que apaga a las 20:00 y enciende a las 08:00 de lunes a viernes, las máquinas se apagan el viernes por la noche y no vuelven a arrancar hasta el lunes por la mañana. Estas son las cuentas de ACME:

• El ahorro sale del cómputo; los discos siguen costando lo mismo. Por eso el 64 % de horas apagadas se queda en un 58 % de la factura del entorno.
• Si alguna de esas máquinas estuviera cubierta por una Reserved Instance o un Savings Plan, habría que restarla del cálculo.

Paso 3: preparar la cuenta para que el agente pueda actuar

El rol con el que conectaste la cuenta es de sólo lectura y no puede apagar nada. Para las automatizaciones hacen falta dos cosas más:

• En AWS, el rol de agente. Se instala en el último paso del asistente de conexión, «Habilitar agente autónomo (opcional)», con el botón «Instalar rol de agente en AWS»: un segundo stack de CloudFormation que crea el rol FinOpsSentinelAgent. Si lo saltaste, puedes instalarlo después desde Mis cuentas cloud.
• En AWS, la etiqueta FinOpsSentinelManaged=true en cada instancia que quieras programar. El rol de agente sólo puede arrancar y detener instancias con esa etiqueta, y no puede ponérsela a sí mismo: la pones tú.
• En Azure y Google Cloud, los permisos de escritura del mismo paso del asistente. En Azure la VM se desasigna, no sólo se detiene, para que deje de pagar cómputo; en Google Cloud la instancia se detiene.

Paso 4: crear la automatización

En Agente IA → Automatizaciones, pulsa «Nuevo schedule». Así lo rellena ACME:

• Los días valen para el apagado y para el encendido. Con lunes a viernes, el apagado del viernes no tiene encendido hasta el lunes: el fin de semana queda cubierto sin hacer nada más.
• «Ahorro estimado ($/mes)» es la cifra que tú declaras, la del cálculo del paso anterior. La plataforma la muestra en la tarjeta y la suma en el total de ahorro de las automatizaciones activas; no es una medición.
• Crear, pausar o borrar una automatización exige permiso de escritura sobre el agente, que tienen los roles de propietario y administrador.

Paso 5: comprobar que se cumple

Una vez creada, la automatización aparece como «Activo» con su horario, su zona horaria, el número de instancias y el ahorro declarado. A partir de ahí:

• La tarjeta indica cuándo fue la última ejecución y cuántas lleva.
• Cada apagado y cada encendido queda en Agente IA → Historial, como completado o fallido, con el error si lo hubo (por ejemplo, una instancia sin la etiqueta).
• El interruptor «Pausar» detiene la automatización sin borrarla. Ojo: pausar no enciende las máquinas; si alguien necesita el entorno esa noche, arráncalo a mano.
• Borrar la automatización elimina sus dos reglas programadas. Las máquinas se quedan en el estado en que estuvieran.

Qué no hace todavía

Para que sepas qué esperar:

• Sólo arranca y detiene instancias: EC2 en AWS, máquinas virtuales en Azure e instancias de Compute Engine en Google Cloud. No programa bases de datos RDS, grupos de Auto Scaling ni nodos de Kubernetes.
• No hay calendario de festivos: el horario se define por días de la semana.
• Cada automatización admite hasta 50 instancias y una organización puede tener hasta 200.
• El formulario ofrece cinco zonas horarias: Europe/Madrid, tres husos de Estados Unidos y UTC.
• El ahorro de la tarjeta es el que declaras, no uno medido en la factura.
• Si la suscripción vence, las automatizaciones dejan de ejecutarse.

Checklist para empezar

Con esto en orden, tus entornos de desarrollo dejarán de pagar las noches y los fines de semana sin que nadie tenga que acordarse:

• Cuenta conectada y escaneada; candidatos revisados en Hallazgos activos.
• Entornos etiquetados con Environment=dev o Environment=staging.
• Ahorro calculado en el Simulador de ahorro y completado a mano con el fin de semana.
• Comprobado que ninguna candidata está cubierta por una reserva ni dentro de un grupo de Auto Scaling.
• Plan Business, rol de agente instalado y etiqueta FinOpsSentinelManaged=true en cada instancia.
• Automatización creada y primera ejecución verificada en el Historial.