Por fin llegaron los CUDs para BigQuery y Composer. ¿De verdad vas a ahorrar con ellos?
Introducción
Google anunció hace poco los Committed Use Discounts (CUDs) para BigQuery y Cloud Composer, una opción que abre la puerta a ahorrar cuando el consumo es constante. Google promete hasta un 20% de ahorro con un compromiso a 3 años y un 10% con uno a 1 año. Eso sí, el ahorro real depende de que mantengas de forma sostenida la línea base de gasto comprometido por hora.
Aunque la mayoría de los detalles están en la documentación oficial (por ejemplo aquí [1] y aquí [2]), me pareció útil sumar algo de contexto:
Estos CUDs están basados en gasto, es decir, te comprometes a gastar una cantidad determinada de dinero por hora en SKUs elegibles. Se compran a través de tu cuenta de facturación y los descuentos pueden compartirse entre proyectos dentro de la misma región. Algo importante: los CUDs son específicos por región, así que tienes que comprarlos por separado en cada región donde quieras aplicar el descuento.
Google indica que los CUDs se aplican a todos los SKUs PAYG de BigQuery[3]. Sin embargo, esto solo abarca:
- Modelos de consumo de BigQuery Editions (¡todas las Editions!)
- SKUs de cómputo de Composer 3 (¡muy bien!)
- BigQuery Data Governance (antes conocido como Dataplex)
Eso sí, hay exclusiones importantes: los costos de almacenamiento de BigQuery y los precios de consultas de análisis on-demand no quedan cubiertos por estos CUDs. Es una limitación clave que conviene tener presente.
En cuanto a lo que sí entra, la llegada de los CUDs para Composer es una novedad muy esperada por muchos usuarios. Que se incluya BigQuery Data Governance también llama la atención, sobre todo porque Google recién hace poco movió esos SKUs bajo el paraguas de BigQuery; el tiempo dirá qué tanto impacto tendrán estos CUDs en esos servicios puntuales.
Para definir si estos nuevos CUDs de BigQuery/Composer te convienen, ten en cuenta lo siguiente:
- ¿Estás usando BigQuery Editions junto con Cloud Composer (versión 2 o 3) o con BigQuery Data Governance? Un BigQuery Slot commitment por sí solo puede salir más barato, pero si tienes consumo constante en una combinación de estos servicios elegibles, vas a ver un ahorro adicional con estos nuevos CUDs basados en gasto.
- ¿Tus workloads en estos servicios son estables? Por ejemplo, ¿tu entorno de Composer corre 24/7 y tienes consultas ejecutándose de forma constante a lo largo del día?
- ¿Ya tienes otros slot commitments para BigQuery reservations [4] vigentes? Al parecer, estos nuevos CUDs basados en gasto para Editions/Composer/Governance no se pueden combinar con compromisos de slot reservation existentes.
Cómo encontrar la línea base de tus workloads estables
Encontrar la línea base de tus workloads estables no es tan sencillo como podría parecer, porque tienes que calcular el gasto por hora de todos los SKUs elegibles.
Primero, puedes ir a "Committed use discounts analysis" dentro de la configuración de tu cuenta de facturación para ver el consumo elegible que podría cubrirse con CUDs.
Segundo, si tienes configurado un export detallado de BQ, puedes usar esta query.
WITH base as (
SELECT *
FROM `project.dataset.billing_export*`
WHERE 1=1
AND TIMESTAMP_TRUNC(export_time, DAY) = TIMESTAMP("2025-04-20")
AND sku_group_description like "%PAYG%"
AND service_description = "BigQuery Reservation API"
)
SELECT
usage_start_time,
sku_group_description,
sku_description,
location.region,
SUM(cost)
FROM base
GROUP BY ALL
Si eres cliente de DoiT, ya agregamos un reporte para ti: se llama BigQuery CUD eligible analysis spend. No dudes en abrir un caso de soporte si quieres conversar con uno de nuestros SMEs de BigQuery.
Reporte DoiT DCI: BigQuery CUD eligible analysis spend.
En general, suele convenir más un BigQuery Slot commitment. Pero si estás corriendo Cloud Composer 3 o servicios de BigQuery Data Governance, los CUDs de BigQuery son una buena alternativa.
Comparación: CUDs vs. Slot commitment
Ejemplo
Veamos el siguiente caso real, bastante sencillo:
Costo por SKUs elegibles agrupados por región
Con este ejemplo, comprar CUDs para us-east1 o us-central podría no convenir, ya que el gasto por hora en SKUs elegibles está por debajo de $1. Sin embargo, en la multi-región US, este cliente podría ahorrar un 10% (hasta $500 al día; 230 de gasto base * 24 horas * 0.1) si compra un CUD. El detalle es que ya tiene una BigQuery slot reservation a 1 año, que le ahorra un 20% por slot hour. En ese caso particular, sumar un commit basado en gasto no tendría sentido.
En general, solemos recomendar combinar CUDs a 1 y 3 años para no poner todos los huevos en la misma canasta. Además, puedes optar por cubrir con CUDs solo entre el 60 y el 75% de tu gasto elegible, lo que te deja algo de margen para futuras iniciativas de optimización de costos o cambios en los patrones de consumo.
TLDR;
Los CUDs sin duda tienen sentido para servicios 'always-on' como las VMs e incluso Cloud SQL, pero puede que no encajen del todo con los patrones de uso típicos de BigQuery. Los workloads de BigQuery suelen ser más irregulares y pueden escalar a cero cuando no están en uso, lo que, de hecho, es una de las principales ventajas de un data warehouse en la nube.
Ahora bien, cuando sumas al cálculo el uso de Cloud Composer y BigQuery Data Governance, el panorama cambia. Estos servicios tienden a ejecutarse de forma constante, quizás 24/7, consumiendo recursos de cómputo (como slots o DCUs) a lo largo del día.
Si te gusta lo que hacemos, conoce nuestros servicios en https://doit.com/services
[1] https://cloud.google.com/bigquery/docs/bigquery-cud
[2] https://cloud.google.com/docs/cuds-spend-based#purchasing