Os CUDs para BigQuery e Composer finalmente chegaram — será que dá pra economizar de verdade?
Introdução
O Google anunciou recentemente os Committed Use Discounts (CUDs) para BigQuery e Cloud Composer, com potencial de economia para quem mantém um uso consistente. A promessa é de até 20% de desconto em compromissos de 3 anos e 10% em compromissos de 1 ano. Só que a economia real depende de você bater consistentemente sua linha de base de gasto comprometido por hora.
A maior parte dos detalhes está na documentação oficial (como aqui [1] e aqui [2]), mas vale acrescentar um pouco mais de contexto:
Esses CUDs são baseados em gasto, ou seja, você se compromete a gastar um valor específico por hora em SKUs elegíveis. A compra é feita pela sua conta de billing e os descontos podem ser compartilhados entre projetos dentro da mesma região. Importante: os CUDs são específicos por região, então é preciso comprá-los individualmente para cada região onde você quer o desconto.
O Google afirma que os CUDs se aplicam a todos os SKUs PAYG do BigQuery[3]. Mas, na prática, isso só engloba:
- Modelos de consumo das BigQuery Editions (todas as Editions!)
- SKUs de compute do Composer 3 (ótimo!!)
- BigQuery Data Governance (antigo Dataplex)
Por outro lado, há exclusões relevantes: os custos de armazenamento do BigQuery e o preço das consultas de análise on-demand não entram nesses CUDs. Essa é uma limitação importante de ter no radar.
Sobre o que está incluído, os CUDs para o Composer são uma novidade muito bem-vinda e há tempos pedida pelos usuários. Já a inclusão do BigQuery Data Governance é curiosa, principalmente porque o Google acabou de mover esses SKUs para debaixo do guarda-chuva do BigQuery; o tempo vai dizer o quanto esses CUDs vão pesar para esses serviços específicos.
Para saber se esses novos CUDs de BigQuery/Composer fazem sentido no seu cenário, considere os seguintes pontos:
- Você usa BigQuery Editions junto com Cloud Composer (versão 2 ou 3) ou BigQuery Data Governance? Um Slot commitment do BigQuery sozinho pode sair mais em conta, mas, se você tem uso consistente em uma combinação desses serviços elegíveis, vai conseguir economia adicional com esses novos CUDs baseados em gasto.
- Você tem workloads estáveis nesses serviços? Por exemplo: seu ambiente Composer roda 24/7 e suas queries rodam de forma consistente ao longo do dia?
- Você já tem outros slot commitments para reservas do BigQuery [4]? Pelo que tudo indica, esses novos CUDs baseados em gasto para Editions/Composer/Governance não podem ser empilhados com slot reservation commitments já existentes.
Como encontrar sua linha de base de workload estável
Encontrar a linha de base do seu workload estável não é tão simples quanto parece, já que você precisa apurar o gasto por hora de todos os SKUs elegíveis.
Primeiro, dá pra acessar "Committed use discounts analysis" nas configurações da sua conta de billing para ver o uso elegível que pode ser coberto por CUDs.
Segundo, se você tem um export detalhado do BQ configurado, pode 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
Se você é cliente DoiT, já preparamos um relatório pra você: o BigQuery CUD eligible analysis spend. Fique à vontade para abrir um chamado de suporte caso queira bater um papo com um dos nossos especialistas em BigQuery.
Relatório DoiT DCI: BigQuery CUD eligible analysis spend.
Em geral, um Slot commitment do BigQuery sai mais em conta. Mas, se você roda Cloud Composer 3 ou serviços de BigQuery Data Governance, os CUDs do BigQuery valem a pena.
Comparativo: CUDs vs Slot commitment
Exemplo
Vamos a um cenário simples e bem real:
Custo por SKUs elegíveis agrupados por região
Nesse exemplo, comprar CUDs para us-east1 ou us-central pode não compensar, já que o gasto por hora dos SKUs elegíveis fica abaixo de US$ 1. Já na multi-região US, este cliente economizaria 10% (até US$ 500 por dia; 230 de gasto base * 24 horas * 0,1) ao adquirir um CUD. O detalhe é que ele já tem uma reserva de slot do BigQuery comprometida por 1 ano, que está garantindo 20% de economia por hora de slot. Nesse caso específico, somar um compromisso baseado em gasto não faria sentido.
De modo geral, costumamos recomendar um mix de CUDs de 1 e 3 anos para não colocar todos os ovos na mesma cesta. Outra ideia é cobrir só 60–75% do seu gasto elegível com CUDs, o que deixa uma margem de flexibilidade para futuros esforços de otimização de custos ou mudanças nos padrões de uso.
TLDR;
Os CUDs fazem todo sentido para serviços ‘always-on’ como VMs e até Cloud SQL, mas podem não se encaixar tão bem nos padrões típicos de uso do BigQuery. Os workloads de BigQuery costumam ser mais irregulares e conseguem escalar para zero quando não estão em uso — o que, aliás, é uma das principais vantagens de um data warehouse na nuvem.
Por outro lado, quando você inclui o uso de Cloud Composer e BigQuery Data Governance na conta, o cenário muda. Esses serviços tendem a rodar de forma consistente, muitas vezes 24/7, consumindo recursos de compute (como slots ou DCUs) o dia inteiro.
Se você curte o que fazemos, dá uma olhada na nossa página de serviços https://doit.com/services
[1] https://cloud.google.com/bigquery/docs/bigquery-cud
[2] https://cloud.google.com/docs/cuds-spend-based#purchasing