Rightsizing continuo: por qué el ahorro en la nube se evapora

Casi toda organización con cargas en la nube ha hecho alguna vez un ejercicio de rightsizing: se revisan las instancias, se detectan las que están sobredimensionadas, se reducen y la factura baja. El problema aparece unos meses después, cuando la factura vuelve a subir sin que nadie haya tomado una decisión explícita de gastar más. El ahorro no se perdió por un error puntual. Se perdió porque el rightsizing se trató como un proyecto y no como una práctica operativa.

En este artículo explicamos por qué el ahorro se degrada, qué principios de FinOps conviene aplicar, qué señales usar para decidir y cómo un agente de IA puede sostener el trabajo en el tiempo sin quitarle el control a las personas que responden por la disponibilidad.

Por qué el ahorro de un solo ejercicio dura poco

El tamaño correcto de un recurso es una foto de un momento. La operación, en cambio, se mueve todo el tiempo. Hay al menos cuatro fuerzas que empujan el gasto de vuelta hacia arriba:

• Cargas nuevas. Cada proyecto nuevo despliega recursos con tamaños estimados antes de conocer el uso real. Esa estimación casi nunca se revisa después del lanzamiento.
• Valores por defecto. Plantillas de infraestructura como código, módulos compartidos, gráficos de Helm o asistentes de consola traen tamaños predefinidos. Si el valor por defecto es generoso, cada copia hereda el exceso.
• Miedo a quedarse corto. Para un equipo de operaciones, un incidente por falta de capacidad tiene un costo visible y personal. Un exceso de capacidad tiene un costo difuso que paga otro presupuesto. La decisión racional, desde su lugar, es sobredimensionar.
• Cambios en la aplicación. Una versión nueva puede reducir el consumo de memoria o duplicarlo. Si nadie conecta el despliegue con la revisión de tamaños, el recurso queda ajustado a una aplicación que ya no existe.

A esto se suma que los proveedores lanzan familias de instancias nuevas con otra relación entre precio y rendimiento. Un recurso que estaba bien elegido hace dos años puede no estarlo hoy, aunque su uso no haya cambiado.

La conclusión práctica es simple: si el rightsizing no tiene un dueño, una frecuencia y un mecanismo que detecte las desviaciones, el ahorro se evapora.

Principios de FinOps que conviene aplicar

La FinOps Foundation, una iniciativa de la Linux Foundation, publica el FinOps Framework, un marco abierto para gestionar el valor financiero de la nube. No hace falta adoptarlo completo para aprovechar sus ideas centrales. Para el rightsizing, las más útiles son estas:

• Los equipos colaboran. Finanzas, tecnología y negocio comparten la misma información y deciden juntos. El rightsizing no es una tarea que Finanzas le impone a Operaciones.
• Cada equipo es dueño de su consumo. Quien despliega un recurso responde por su costo. Para eso necesita ver ese costo, idealmente asignado mediante etiquetas consistentes.
• Los datos deben ser accesibles y oportunos. Un reporte mensual llega tarde para corregir una carga que se desplegó con el tamaño equivocado hace tres semanas.
• Las decisiones se basan en el valor de negocio. El objetivo no es gastar lo mínimo, sino gastar lo necesario para el nivel de servicio comprometido.

El marco también describe un ciclo de tres fases: Informar, Optimizar y Operar. El error frecuente es quedarse en Optimizar como evento único. El rightsizing continuo vive en la fase de Operar: es un proceso recurrente con responsables y métricas, no un proyecto con fecha de cierre.

Qué señales usar: percentiles, no promedios

La mayoría de los malos rightsizings se explican por una mala métrica. El promedio de CPU es la más usada y la más engañosa. Un servidor con un promedio de 15 % puede tener picos diarios de 90 % durante el cierre contable. Si lo reduces mirando el promedio, el cierre siguiente será un incidente.

Recomendamos trabajar con estas señales:

• Percentiles altos de utilización (p95 o p99) de CPU y memoria, calculados sobre una ventana que cubra el ciclo completo del negocio. Para muchos procesos financieros eso significa al menos un mes, para incluir el cierre.
• Memoria por separado. La CPU se puede compartir y estrangular, la memoria no. Quedarse sin memoria suele terminar en un proceso que se cae, no en uno más lento.
• Señales de saturación, no solo de uso: colas de ejecución, estrangulamiento de CPU en contenedores, espera de disco, IOPS y rendimiento de red contra los límites del tipo de instancia.
• Indicadores del servicio: latencia y tasa de error de las transacciones que dependen del recurso. Si el cambio empeora estos indicadores, no importa cuánto ahorre.
• Eventos de calendario conocidos: cierres, campañas, procesos batch trimestrales. Un dato que no está en las métricas no puede inferirse de ellas.

En Kubernetes la lógica es la misma, aplicada a los requests y limits de cada contenedor. Herramientas como el Vertical Pod Autoscaler o las recomendaciones de los proveedores de nube (por ejemplo, AWS Compute Optimizer o Azure Advisor) generan sugerencias útiles. Conviene tratarlas como una entrada más, no como una decisión.

Cómo propone cambios un agente

Un agente de rightsizing no es un script que reduce instancias. Es un proceso que observa, razona sobre la evidencia y prepara una propuesta que una persona puede evaluar en minutos. Un flujo razonable tiene estos pasos:

1. Inventario y contexto. El agente lee el inventario de recursos, sus etiquetas (dueño, servicio, ambiente, criticidad) y la tarifa aplicable, incluidos compromisos de uso o reservas que afecten el ahorro real.
2. Análisis de uso. Calcula percentiles sobre la ventana definida, cruza con indicadores del servicio y con el calendario de eventos, y descarta recursos con historia insuficiente.
3. Propuesta con evidencia. Para cada candidato genera una ficha: tamaño actual, tamaño propuesto, percentiles observados, margen que queda tras el cambio, ahorro estimado y supuestos.
4. Plan de reversión. La ficha incluye cómo volver atrás, cuánto tarda y qué indicador dispara la reversión.
5. Cambio por el canal normal. Si la infraestructura se gestiona como código, la propuesta llega como un pull request contra el repositorio, no como un cambio directo en la consola.
6. Verificación posterior. Tras el cambio, el agente vigila los indicadores durante un período acordado y reporta si el resultado coincide con lo previsto.

Un ejemplo ilustrativo, con números inventados para mostrar el formato y no para sugerir resultados típicos: una máquina virtual de 8 vCPU y 32 GB muestra, en 45 días que incluyen un cierre mensual, un p95 de CPU de 22 % y un p99 de memoria de 11 GB. El agente propone pasar a 4 vCPU y 16 GB, lo que dejaría un p95 de CPU estimado cercano al 44 % y un margen de memoria de 5 GB sobre el p99. Indica el ahorro mensual según la tarifa vigente, aclara que el recurso no tiene reserva asociada y define la reversión: volver al tamaño anterior si la latencia p95 del servicio supera el umbral del SLO durante quince minutos.

Lo importante del ejemplo no son los números, sino que cada afirmación es verificable y que el criterio de reversión está escrito antes del cambio.

Flujo de aprobación según el riesgo

No todos los cambios merecen el mismo nivel de revisión. Clasificar por reversibilidad y criticidad evita dos fallas opuestas: aprobar todo sin mirar o bloquear todo por precaución.

Tipo de cambio	Reversibilidad	Aprobación sugerida
Ajuste de requests en ambientes de desarrollo	Inmediata	Automática dentro de límites, con reporte semanal
Cambio de tamaño en servicio no crítico con autoescalado	Minutos	Dueño del servicio
Cambio de tamaño en servicio crítico o con SLA comprometido	Minutos, con ventana	Dueño del servicio y gestión de cambios
Bases de datos, almacenamiento o cambio de familia	Lenta o con riesgo	Comité de cambios con plan de pruebas
Compra o modificación de compromisos de uso	No reversible en el corto plazo	Finanzas y Operaciones; el agente solo recomienda

Esta graduación conecta con una pregunta más amplia: cuánta autonomía darle a un agente y cómo ampliarla con el tiempo. Conviene definirla con una escala explícita de niveles de autonomía.

Medir el ahorro que se sostiene

Un programa de rightsizing que solo reporta "ahorro identificado" no prueba nada. Lo que importa es cuánto de ese ahorro sigue vigente seis meses después. Recomendamos medir:

• Ahorro realizado frente a identificado. Cuántas propuestas se aprobaron, se aplicaron y siguen aplicadas.
• Tasa de reversión. Qué porcentaje de cambios hubo que deshacer. Una tasa alta indica umbrales agresivos; una tasa nula puede indicar que el agente es demasiado conservador.
• Incidentes atribuibles. Cualquier incidente causado por un cambio de tamaño se analiza como problema y ajusta las reglas.
• Deriva por recurso. Recursos que volvieron a crecer después de ajustarse, y por qué.
• Costo unitario. Cuando sea posible, costo por transacción, por cliente o por proceso. El gasto total puede subir por crecimiento legítimo; el costo unitario muestra si la eficiencia se mantiene.

Para que estas métricas sean confiables hace falta una base de etiquetado consistente y una línea base registrada antes de cada cambio. Sin línea base, cualquier cifra de ahorro es una opinión.

Por último, conviene atacar la causa y no solo el síntoma. Si el agente detecta que la mayoría de los excesos nace de un mismo módulo de infraestructura o de una plantilla compartida, la mejor propuesta no es ajustar cien recursos, sino corregir el valor por defecto que los generó. Ese hallazgo se documenta y se prioriza junto con el resto del backlog de automatización, por ejemplo con el marco de Valor y Complejidad que usamos para ordenar iniciativas.

Si estás empezando con agentes en operaciones, el artículo sobre agentes de IA en la operación de TI da el contexto general.