Descuentos por uso comprometido en Google Cloud, y el orden en que comprarlos

El modelo de descuentos de Google Cloud es más indulgente que la mayoría, y justo por eso los equipos lo hacen mal: los descuentos por uso sostenido se aplican solos, así que la factura ya parece descontada y nadie mira las opciones de compromiso hasta que finanzas pregunta.

Aquí hay ahorros reales —del 20 al 55 por ciento según plazo y tipo— pero el orden importa, y uno de los dos tipos de compromiso es mucho más fácil de lamentar.

Sabe qué descuentos ya estás recibiendo

Los descuentos por uso sostenido se aplican automáticamente a las instancias de Compute Engine que corren la mayor parte de un mes. Sin acción, sin compromiso. Ya están en tu factura.

Los descuentos por uso comprometido son un compromiso de uno o tres años a cambio de un descuento mayor, y vienen en dos tipos que no son intercambiables.

Basados en gasto frente a basados en recurso, y por qué importa

Los CUD basados en gasto te comprometen a una cantidad de dinero por hora en un servicio. Son flexibles: se aplican entre tipos de máquina, entre regiones y a las generaciones nuevas que aparezcan durante tu plazo. Disponibles para Cloud Run, GKE Autopilot, Cloud SQL, Spanner, Memorystore y, de forma importante, Compute Engine en su variante flexible.

Los CUD basados en recurso te comprometen a una cantidad de vCPU y memoria en una región y familia de máquina concretas. Descuentan más, y son una trampa para quien pueda cambiar de arquitectura. Un compromiso n2 a tres años en europe-west1 no vale nada para una carga que muevas a c4 o a otra región, y el compromiso sigue facturando igualmente.

Nuestro valor por defecto: basado en gasto para todo, basado en recurso solo para una carga demostrablemente estática — un clúster de base de datos que no se va a mover, una aplicación con licencia de tamaño fijo. Los pocos puntos extra del basado en recurso rara vez compensan perder la libertad de adoptar una familia más nueva que a su vez es más barata por unidad de trabajo.

El orden

1. Quita el desperdicio primero. Un compromiso fija la huella de hoy. Las VM ociosas, las instancias sobredimensionadas, los discos persistentes sin asociar, los clústeres de desarrollo olvidados y los snapshots viejos deberían haber desaparecido antes de calcular una base. Es el mismo principio que las cinco capas de la factura de AWS y aquí se aplica igual.

2. Redimensiona con el Recommender. El Recommender de GCP da recomendaciones de tipo de máquina a partir de métricas reales, detección de recursos ociosos y de IP ociosas, todo gratis y todo en la consola. Aplícalas y espera dos semanas a que la nueva base se asiente.

3. Mueve lo que debería ser interrumpible o Spot. Lotes, runners de CI, réplicas sin estado. Las VM Spot tienen entre un 60 y un 91 por ciento de descuento y ningún compromiso las cubre — pero un compromiso comprado antes de mover una carga a Spot es un compromiso que cubre capacidad que estás a punto de dejar de usar.

4. Mide la base correctamente. Exporta la facturación a BigQuery y toma el p10 del uso horario de 90 días por servicio. Ese es el suelo al que puedes comprometerte con seguridad: el nivel que superas el 90 por ciento del tiempo.

5. Comprométete al 60 o 70 por ciento de ese suelo, primero a un año. Los compromisos a un año descuentan menos que los de tres y cuesta mucho menos equivocarse. Cuando tengas un año de datos estables y una hoja de ruta en la que creas, extiende la capa base a tres años y mantén la capa superior en uno.

6. Revisa cada trimestre. Los CUD se acumulan, así que puedes añadir capas conforme crece la base. Pon un recordatorio de calendario un mes antes de cada vencimiento — un compromiso vencido vuelve en silencio al precio bajo demanda y la factura salta.

Dos cosas que se pasan por alto

Los CUD se comparten entre proyectos de la misma cuenta de facturación si activas el uso compartido. Sin ello, un compromiso comprado en un proyecto no ayuda a otro, lo que produce el resultado confuso de un compromiso infrautilizado junto a cargos bajo demanda.

GKE Autopilot y Cloud Run tienen sus propios CUD basados en gasto. Los equipos que salieron de las VM a menudo siguen comprometiéndose en Compute Engine por costumbre y dejan sin comprar los compromisos nuevos.

Qué esperar

En un entorno típico, quitar desperdicio es del 15 al 25 por ciento, Spot para las cargas adecuadas otro 5 a 15, y los compromisos sobre la base restante un 20 a 30 encima. Hacerlo en el orden equivocado es lo que produce un descuento comprometido sobre capacidad que no necesitabas — que es una pérdida, no un ahorro. Recorremos esta secuencia en la fase de costes de casi todos los proyectos cloud.

Qué hacer esta semana

Abre el Recommender en la consola y mira las recomendaciones de recursos ociosos y de tipo de máquina en tus proyectos de producción. Aplícalas. Después, y solo después, mira la página de análisis de compromisos, que ahora te estará enseñando una base a la que merece la pena comprometerse.