Les CUDs pour BigQuery et Composer sont enfin là — vais-je vraiment économiser ?
Introduction
Google a récemment annoncé les Committed Use Discounts (CUDs) pour BigQuery et Cloud Composer, avec des économies à la clé pour les usages réguliers. Google promet jusqu'à 20 % de remise pour un engagement de 3 ans et 10 % pour un engagement d'1 an. Les économies réelles dépendent toutefois de votre capacité à atteindre durablement votre seuil horaire d'engagement.
L'essentiel se trouve dans la documentation officielle (par exemple ici [1] et ici [2]), mais quelques précisions s'imposent :
Ces CUDs reposent sur un engagement de dépenses : vous vous engagez à dépenser un montant horaire défini sur les SKUs éligibles. L'achat se fait via votre compte de facturation et les remises peuvent être partagées entre projets d'une même région. Attention : les CUDs sont spécifiques à chaque région, il faut donc les acheter séparément pour chaque région concernée.
Selon Google, les CUDs s'appliquent à l'ensemble des SKUs BigQuery PAYG[3]. En pratique, cela couvre uniquement :
- Les modèles de consommation BigQuery Editions (toutes les Editions !)
- Les SKUs Composer 3 pour le compute (excellente nouvelle !)
- BigQuery Data Governance (anciennement Dataplex)
Quelques exclusions notables, en revanche : les coûts de stockage BigQuery et la tarification à la demande des requêtes d'analyse ne sont pas couverts par ces CUDs. Une limitation à garder en tête.
Côté inclusions, l'arrivée des CUDs pour Composer est une fonctionnalité bienvenue, attendue depuis longtemps par de nombreux utilisateurs. L'inclusion de BigQuery Data Governance est intéressante elle aussi, d'autant que Google n'a rattaché ces SKUs à BigQuery que récemment ; l'avenir dira l'impact réel de ces CUDs sur ces services spécifiques.
Pour savoir si ces nouveaux CUDs BigQuery/Composer sont faits pour vous, posez-vous les questions suivantes :
- Utilisez-vous BigQuery Editions en parallèle de Cloud Composer (version 2 ou 3) ou de BigQuery Data Governance ? Un engagement BigQuery Slot seul peut revenir moins cher, mais si votre consommation est régulière sur plusieurs de ces services éligibles, ces nouveaux CUDs basés sur les dépenses vous feront réaliser des économies supplémentaires.
- Vos workloads sur ces services sont-ils stables ? Par exemple, votre environnement Composer tourne-t-il en 24/7, et avez-vous des requêtes qui s'exécutent en continu tout au long de la journée ?
- Avez-vous déjà des engagements de slots en place pour des réservations BigQuery [4] ? Il semble que ces nouveaux CUDs basés sur les dépenses pour Editions/Composer/Governance ne puissent pas être cumulés avec des engagements de réservation de slots existants.
Identifier votre seuil de consommation stable
Identifier votre seuil de consommation stable n'est pas si simple : il faut calculer la dépense horaire pour l'ensemble des SKUs éligibles.
Premièrement, rendez-vous dans Committed use discounts analysis, dans les paramètres de votre compte de facturation, pour visualiser la consommation éligible aux CUDs.
Deuxièmement, si vous avez configuré un export BQ détaillé, vous pouvez utiliser cette requête.
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 vous êtes client DoiT, nous avons ajouté un rapport dédié : BigQuery CUD eligible analysis spend. N'hésitez pas à ouvrir un ticket de support pour échanger avec l'un de nos experts BigQuery.
Rapport DoiT DCI : BigQuery CUD eligible analysis spend.
De manière générale, un engagement BigQuery Slot reste plus avantageux. Mais si vous utilisez Cloud Composer 3 ou les services BigQuery Data Governance, les CUDs BigQuery sont une bonne affaire.
Comparaison : CUDs et engagement de slots
Exemple
Prenons un cas concret tiré du terrain :
Coût des SKUs éligibles, par région
Dans cet exemple, acheter des CUDs pour us-east1 ou us-central a peu d'intérêt : la dépense horaire sur les SKUs éligibles est inférieure à 1 $. En revanche, dans la multi-région US, ce client pourrait économiser 10 % (jusqu'à 500 $ par jour ; 230 de dépense de référence × 24 heures × 0,1) en souscrivant à un CUD. Le hic : il est déjà engagé sur une réservation BigQuery Slot d'1 an, qui lui fait économiser 20 % par heure de slot. Dans ce cas précis, ajouter un engagement basé sur les dépenses n'aurait aucun sens.
De manière générale, nous recommandons de panacher des CUDs sur 1 et 3 ans pour ne pas mettre tous ses œufs dans le même panier. Vous pouvez aussi choisir de ne couvrir que 60 à 75 % de vos dépenses éligibles, afin de garder de la marge pour vos futurs chantiers d'optimisation des coûts ou d'éventuelles évolutions de vos usages.
TLDR;
Les CUDs prennent tout leur sens pour les services always-on comme les VMs ou Cloud SQL, mais ils collent moins bien aux usages typiques de BigQuery. Les workloads BigQuery sont souvent plus irréguliers et peuvent descendre à zéro hors utilisation — c'est même l'un des principaux atouts d'un data warehouse cloud.
La donne change toutefois dès qu'on intègre Cloud Composer et BigQuery Data Governance dans le calcul. Ces services tournent plus volontiers en continu, parfois 24/7, et consomment des ressources de compute (slots, DCUs) tout au long de la journée.
Si notre travail vous intéresse, découvrez nos services sur https://doit.com/services
[1] https://cloud.google.com/bigquery/docs/bigquery-cud
[2] https://cloud.google.com/docs/cuds-spend-based#purchasing