Los commitments son un blanco móvil. Los recomendadores nativos no dan en el blanco, así que construimos el nuestro.

Cómo encuentra el número nuestro motor

En realidad son dos motores. Uno para los Savings Plans de AWS y otro para los descuentos por uso comprometido (CUDs) de Google Cloud. Código separado, porque las dos nubes fijan precios y aplican commitments de formas realmente distintas, y fingir lo contrario nos habría costado precisión. Aun así, la idea de fondo es la misma.

Todo empieza con los datos de uso en bruto. Tomamos cada hora de gasto que un commitment podría cubrir durante el período de análisis; para una ventana de 60 días, eso significa revisar unas 1,440 horas individuales con sus montos exactos. Algunas de esas horas estarán llenas de actividad. Otras estarán completamente muertas, sobre todo cuando llega la caída del fin de semana. El verdadero reto es decidir cómo manejar una forma que fluctúa tanto.

Luego descontamos lo que ya tienes. Si tienes Savings Plans o CUDs activos, los aplicamos a cada hora igual que lo hace el proveedor de nube: primero el mejor descuento. Lo que esos planes ya cubren queda fuera de juego. Lo que queda es el gasto en el que un nuevo commitment todavía podría ahorrarte dinero.

También tenemos en cuenta cada descuento que ya tienes. Precios negociados por contrato. Descuentos por uso sostenido en Google Cloud. La cobertura de Flexsave de DoiT, si lo usas. Un commitment solo tiene sentido si supera el precio que realmente pagas hoy, así que ese es el precio contra el que comparamos, no el precio de lista.

Los dos motores están separados porque AWS y Google Cloud exponen los datos de facturación de forma distinta y aplican los commitments con sus propias reglas. El principio, sin embargo, es compartido: calcular el commitment contra lo que realmente pagas, no contra un precio de lista que nunca ves en tu factura.

Ahora, la parte que importa.

Elige cualquier commitment por hora que podrías comprar. A lo largo de la ventana pagarías dos cosas. El commitment en sí, cada hora, lo uses o no. Más el gasto on-demand que se desborda en las horas de mayor actividad. Súmalos y ese es tu costo total con ese nivel de commitment.

Un ejemplo rápido. Una hora tiene $100 de gasto elegible y, para simplificar, te comprometiste a $30 por hora con un 40% de descuento. Esos $30 compran/cubren $50 de uso on-demand. Entonces pagas $30 por el commitment, $50 on-demand por el resto: $80 en total en lugar de $100. Bien. Ahora toma una hora tranquila con solo $40 de gasto elegible. Tus $30 siguen comprando $50 de cobertura, solo que únicamente hay $40 que cubrir. Pagas $30, ahorras $10, y una parte del commitment se queda ahí sin usar. El recomendador hace esta aritmética para cada hora de la ventana y lo suma todo. Luego repite lo mismo para cada nivel de commitment que podría recomendar, para ver cuál ahorra más.

Grafica ese total contra el tamaño del commitment y obtienes una curva en forma de U. El punto más bajo de la curva es el punto óptimo: el commitment con el que tu factura total es más baja.

Del lado izquierdo, estás subcomprometido. Cada dólar adicional de commitment reemplaza más de un dólar de gasto on-demand, así que el costo total baja. Del lado derecho, estás sobrecomprometido. El commitment extra se queda inactivo en las horas tranquilas, así que el costo total vuelve a subir.

El punto más bajo de la curva es donde un dólar más de commitment te costaría más de lo que ahorra. Ese es el mejor commitment. No lo buscamos probando cada valor centavo por centavo y quedándonos con el más barato. La forma de la curva nos dice dónde está el punto de inflexión, así que vamos directo a él.

Luego eliges una política de riesgo. Conservative, Balanced, Max Savings, o una que definas tú mismo. Cada una toma una fracción de ese commitment óptimo —65%, 80% o 90%—, lo que deja margen para la semana en que tu uso baje. Las políticas personalizadas van más allá: hasta diez por cliente, cada una con su propio objetivo de cobertura y sus propios pasos de compra, para que la recomendación siga tus reglas y no los tres ajustes predefinidos que se le ocurrieron a un proveedor de nube. Expliqué por qué importa ese margen, y por qué compramos por pasos en lugar de todo de una vez, en un post anterior sobre el problema del dimensionamiento.

Sobre todo esto hay un pequeño conjunto de parámetros de ajuste. Los calibramos a medida que las compras reales nos enseñan cosas. Su función es mantener la recomendación del lado prudente del valor óptimo de commitment.

Por ejemplo, en algunos casos el fondo de la curva puede parecer plano. Un rango de commitments, no un número exacto, ahorra casi lo mismo. El cálculo por sí solo apuntaría sin dudar al más grande, pero nosotros no. Cuando varios tamaños ahorran más o menos lo mismo, tomamos el más pequeño. El mismo ahorro, menos dinero comprometido, más margen si un workload desaparece el próximo mes.

Los parámetros también nos permiten reaccionar a lo que vemos en producción. Si el uso de una cuenta tiende a la baja durante la ventana, la recomendación se inclina hacia algo más pequeño. Si una compra resulta menos útil de lo que el modelo esperaba, aprendemos de eso y la siguiente recomendación es más cautelosa.

Y como el motor es nuestro, cuando un cliente pide algo específico, como "nunca bajar del 70% de utilización" o "dejen margen extra, vamos a consolidar cuentas en el Q3", podemos cumplirlo. No puedes pedirle a AWS o a Google que ejecuten su recomendador con tus reglas. Pero a nosotros sí, o puedes crear tu propia política y nosotros la seguiremos.

En qué coincidimos con las nubes

Antes de hablar de diferencias, hablemos de confianza. Si nuestro número estuviera lejos del número de la nube, tendrías razón en preguntar cuál está mal.

Así que lo verificamos.

Primero hay algo que debe estar bien, o toda la comparación es ruido: ambos recomendadores deben mirar los mismos días de uso. Todo recomendador dimensiona sobre una ventana de análisis, un tramo fijo de horas pasadas. AWS te permite elegir hasta los últimos 60 días. El nuestro se puede configurar en cualquier valor. Si las dos ventanas no coinciden, aunque sea por unos días, los números serán distintos, y esa brecha no tiene nada que ver con el método y sí todo con las fechas. Así que para cada comparación de abajo configuramos nuestro motor con las mismas fechas exactas de inicio y fin que usó AWS o Google. Los mismos días de entrada, y después comparamos lo que sale.

En AWS, ejecutamos nuestro motor contra el AWS Purchase Analyzer en varias cuentas. Probamos todas las combinaciones: plazos de uno y tres años, sin pago inicial, pago parcial y pago total por adelantado. La misma ventana de análisis en ambos lados. Nuestro commitment recomendado quedó a menos del 1% del número de AWS en cada caso. También ejecutamos el motor en nuestro cliente de AWS más grande para asegurarnos de que funciona a escala. Funciona.

En Google Cloud, comparamos contra las recomendaciones que muestra la consola de GCP. En una cuenta de facturación con precios estándar, coincidimos con Google al centavo, en los ocho alcances de commitment que probamos. Eso incluye los CUDs de Compute Flexible, Memorystore y Cloud SQL en cada región. En una cuenta con descuentos negociados, la diferencia fue menor al 1%.

Nube	Tipo de cuenta	Alcances probados	Nuestro número vs. el de la nube
AWS	Payer mediano, todas las combinaciones de plazo y pago	6	Menos del 1% de diferencia
AWS	Nuestro cliente más grande	6	Funciona sin problemas, menos del 1% de diferencia
Google Cloud	Precios estándar	8	Coincidencia exacta, al centavo
Google Cloud	Descuentos negociados	8	Menos del 1% de diferencia

El punto es simple. Cuando haces la misma pregunta, obtienes la misma respuesta. Nadie inventa un número más grande para venderte más.

Entonces, ¿por qué construir el nuestro?

Donde las nubes se detienen y nosotros seguimos

Estas son las preguntas que nuestros clientes hacen de verdad. En cada caso, el recomendador de la nube o no puede responder, o te hace esperar. La versión corta, antes de los detalles:

	AWS	Google Cloud	DoiT
Precisión de la recomendación	Referencia	Referencia	A menos del 1% de ambas
Todas las opciones de plazo y pago, cuando lo necesites	20 análisis por día, uno a la vez	Solo algunos escenarios	Todas las combinaciones en menos de 20 segundos
API síncrona	Proceso asíncrono, hay que consultar el estado durante minutos	No disponible	Sí
Explicar por qué se movió el número	No	No	Sí, hasta las filas de facturación
Acotar por cuenta o SKU	No	No	Sí
Rango de fechas personalizado	Parcial	Parcial	Sí
Independiente de la API de la nube el día de compra	No	No	Sí, lee los datos de facturación directamente
Compras escalonadas automatizadas	No	No	Sí
Commitments por vencer	Vuelve a recomendar después del vencimiento	Vuelve a recomendar después del vencimiento	Reemplazo dimensionado y programado antes del vencimiento
Monitoreo humano de la utilización	No	No	Sí, equipo dedicado de DoiT

"Quiero comparar 1 año vs. 3 años, sin pago inicial vs. todo por adelantado, y tres niveles de riesgo, antes de decidir."

En AWS, cada uno de esos es un análisis separado. El Purchase Analyzer permite 20 análisis por cuenta payer al día. Cada uno tarda de unos segundos a varios minutos, y se ejecutan uno a la vez. Para ver el panorama completo de un payer, necesitas más análisis de los que AWS permite en un día. Así que eliges unos cuantos, esperas y cruzas los dedos para haber elegido bien.

Google Cloud es más flexible aquí. La consola te permite construir escenarios sobre distintos períodos de análisis, y puedes excluir un conjunto de fechas. Útil. Pero ahí se queda. Obtienes las opciones que a Google se le ocurrieron, según las reglas de Google, y en cuanto quieres algo fuera de esa lista, estás por tu cuenta.

Nuestro motor produce todas las combinaciones para una cuenta payer en menos de 20 segundos. Puedes ejecutarlo tantas veces como quieras.

"Quiero conectar las recomendaciones a mis propias herramientas."

El recomendador de AWS es un proceso asíncrono. Lo inicias y luego consultas hasta que termina, segundos o minutos después. Construir un pipeline confiable sobre eso requiere trabajo, y el límite diario sigue aplicando.

La recomendación de la consola de Google Cloud está hecha para leerse, no para alimentar un flujo de compra.

La nuestra es una API REST síncrona, parte de la API de DoiT Cloud Intelligence™. Llamas al endpoint con tu clave de API y recibes la recomendación en la misma respuesta. Tiene la misma forma en AWS y en Google Cloud, así que una sola integración cubre ambas nubes. Puedes publicar la recomendación diaria en Slack, abrir un ticket cuando se mueve más allá de un umbral, o llevarla a tu propio dashboard de FinOps junto al resto de tus datos de costos.

Y como es una API síncrona simple, se conecta a un asistente de IA con la misma facilidad que a un dashboard. Conéctala a Claude, o a lo que uses, y pregunta con palabras: "¿Cuál es la recomendación para Cloud SQL en us-east1?" "¿Cuándo vence mi próximo commitment?" "¿Cuánto nos ahorraron los commitments de cómputo el mes pasado?" Intenta preguntarle eso a una consola.

Además, todo se calcula por adelantado. Cada opción, cada política, cada cuenta, una vez al día. Así que cuando tú o tu asistente preguntan, nada entra en cola, nada tiene límite de peticiones y no hay espera por cada opción. La respuesta ya está ahí.

"¿Por qué cambió el número desde la semana pasada?"

Vimos cómo la recomendación de un payer de AWS se movía entre dos niveles bastante distintos en una misma semana. Nada en el uso lo explicaba. Nuestra mejor hipótesis es que se debe a la ventana móvil y al día de la semana en que preguntas. Pero no podemos estar seguros, porque el Purchase Analyzer no muestra sus cálculos con suficiente claridad como para verificarlo.

Cada número que produce nuestro motor se puede rastrear hasta las filas de facturación. Cuando un cliente pregunta por qué se movió la recomendación, podemos mostrarle qué horas cambiaron y cuánto. A menudo la respuesta es simple: un proceso batch dejó de ejecutarse por la noche, o un entorno nuevo se activó el jueves. En cualquier caso, recibes una respuesta en lugar de una evasiva.

"Esa cuenta se va a dar de baja. Ignórala."

O: "Excluye estos SKUs, estamos migrando ese workload." O: "Dimensiónalo sobre el trimestre pasado, no sobre la ventana predeterminada."

Ninguna de las dos nubes te permite acotar la recomendación por cuenta, por SKU o por un período de tiempo explícito. Obtienes una sola respuesta para todo el payer, con la ventana que ellas eligen.

El nuestro hace las tres cosas. Excluye una cuenta. Quita una fracción de SKUs específicos. Define tus propias fechas de inicio y fin. La elegibilidad también es granular: qué cuentas vinculadas o proyectos entran siquiera en el alcance de los commitments es una configuración, y el motor dimensiona solo contra esos. Hoy lo configuramos por ti; pronto llegará un control de autoservicio. Y detrás hay más controles de los que cualquiera de las dos consolas expone.

Para ser transparentes: hoy estos no son botones de autoservicio en la consola. Le dices a tu equipo de DoiT qué excluir o qué fechas usar, y nosotros ejecutamos el motor con esa configuración por ti. El punto es que se puede hacer, y que la respuesta llega el mismo día. Y todo esto está en nuestro radar: queremos entregar a los clientes los controles de ajuste para que puedan manejar cada parte por sí mismos.

"¿Y si Cost Explorer está caído el día de la compra?"

Suena a caso extremo hasta que sucede. Dimensionar un commitment no es una tarea que se hace una sola vez. Como argumenté en el post sobre dimensionamiento, es un blanco móvil al que tienes que darle una y otra vez, semana tras semana, mientras tu uso no deja de cambiar. Y el blanco se multiplica. Dos nubes, cómputo más bases de datos, varias regiones, cada una con su propio commitment y su propia fecha de vencimiento. Eso no es una decisión semanal. Es una docena.

Un recomendador que depende de un proceso externo puede saltarse un paso. Si la API está lenta, con límite de peticiones o en medio de un incidente, la compra de esa semana no sucede. El nuestro lee tus datos de facturación directamente. No hay nada externo que esperar.

"No quiero estar pendiente de esto."

Y aquí está el punto clave. Esta es la verdadera respuesta a "¿para qué necesito el suyo?".

Una recomendación solo es útil si alguien actúa sobre ella. Nuestro motor alimenta un proceso de compras escalonadas automatizado. Las compras ocurren tras bambalinas, con la cadencia que el cliente controla, en pasos dimensionados por la política que eligió. Y un equipo dedicado de DoiT vigila la utilización de cada commitment. Si algo empieza a quedar inactivo, lo detectan antes de que se convierta en pérdida en tu factura. En AWS eso puede incluso significar devolver un Savings Plan mientras la ventana de devolución sigue abierta.

El vencimiento se maneja igual. Cuando un plan está por vencer, la siguiente recomendación ya asume que no estará, y el sistema programa el reemplazo para que empiece en el momento exacto en que termina el anterior. La cobertura no se cae durante una semana hasta que alguien lo nota. Los recomendadores de las nubes solo ven la brecha después de que se abrió.

Pronto, los clientes podrán definir ellos mismos la política de cadencia de compra, además de la política de riesgo que ya eligen hoy.