Entenda o novo modelo de CUD por gasto do Google Cloud

Você já se pegou calculando a economia dos CUDs fazendo malabarismo entre custos sob demanda, taxas de commitment e abatimentos de crédito? Era exatamente assim que funcionava o antigo sistema de CUDs por gasto do Google. Você se comprometia, por exemplo, com US$ 100/hora de gasto sob demanda, pagava uma taxa de commitment de US$ 54/hora (com 46% de desconto) e recebia um crédito de -US$ 100 que abatia as cobranças de uso. A conta fechava, mas explicar isso para o cliente ou para o time financeiro era um pesadelo.

O novo modelo multiprice corta essa complexidade pela raiz. No lugar dos créditos, o Google passa a aplicar o desconto direto no preço dos SKUs, por meio dos chamados "consumption models". Você se compromete com o seu gasto real já com desconto (US$ 54/hora), paga esse valor e o uso aparece com a tarifa com desconto. Sem créditos avulsos, sem ginástica mental.

Essa mudança também transforma a forma como os dados de CUD aparecem nas exportações do BigQuery, o que exige ajustes em qualquer dashboard de FinOps caseiro ou sistema de alocação de custos que você tenha por aí. Aqui na DoiT passamos pelo mesmo processo.

A migração traz três grandes mudanças que os clientes precisam entender:

Primeiro: a conta do commitment foi invertida. Antes, o commitment era expresso em equivalente de gasto sob demanda. Agora, ele é expresso pelo seu custo real por hora, já com desconto aplicado. Um commitment que cobria US$ 185 de uso sob demanda com 46% de desconto era descrito como "commitment de US$ 185/hora". No novo modelo, esse mesmo commitment passa a ser descrito como "commitment de US$ 100/hora" — ou seja, o valor que você de fato paga. A ferramenta de CUD Recommendations também foi ajustada nessa linha. Se você tem scripts de automação que calculam valores de commitment, prepare-se para revisá-los.

Segundo: o schema do BigQuery ganhou novos campos. A adição mais relevante é a struct consumption_model, com os campos id e description. Quando o uso é coberto por um Compute Flexible CUD de 3 anos, a descrição mostra "Compute Flexible CUDs 3 Year" em vez de aparecer como uma linha de crédito separada. O Google também acrescentou os campos price.list_price, price.effective_price_default e cost_at_list_consumption_model para ajudar a diferenciar preços sob demanda dos preços com desconto nas suas queries.

Terceiro: os SKUs de taxa foram reestruturados. Os novos SKUs de taxa de CUD passam a custar US$ 1/hora, com um tipo de crédito compensatório chamado FEE_UTILIZATION_OFFSET. Quando o CUD é totalmente utilizado, a taxa e a compensação se anulam e o resultado é zero. Quando há subutilização, a parcela não consumida aparece como cobrança. Isso gera duas linhas por CUD nos dados de billing: uma para o uso coberto na tarifa com desconto e outra para qualquer excedente na tarifa sob demanda.

FEE_UTILIZATION_OFFSET

Os Compute Flexible CUDs agora cobrem workloads que antes exigiam tipos de commitment separados ou simplesmente não tinham caminho de desconto.

VMs otimizadas para memória finalmente entram na cobertura do Flex CUD. As famílias de máquinas M1, M2, M3 e M4 já podem ser cobertas por Compute Flexible CUDs, mas só em prazos de 3 anos e com 63% de desconto. Atenção a uma pegadinha importante: commitments de 1 ano oferecem zero de desconto para VMs otimizadas para memória. O seu gasto vai consumir o commitment não utilizado sem nenhum benefício de economia. Se você roda workloads intensivos em memória, como SAP HANA ou grandes bancos de dados in-memory, isso torna os commitments de 3 anos bem mais atrativos.

As famílias de HPC entram na festa. As famílias compute-optimized H3 e a nova H4D agora são elegíveis ao Flex CUD, com 17% para 1 ano e 38% para 3 anos. A H4D, hoje em preview, traz processadores AMD EPYC Turin de 5ª geração com 192 núcleos, até 1.488 GB de memória e rede com RDMA habilitado de 200 Gbps. É hardware parrudo para workloads de computação igualmente parrudos.

Cloud Run ganha cobertura abrangente. A cobrança baseada em requisições para serviços do Cloud Run (incluindo Cloud Run functions, antes conhecidas como Cloud Functions) agora se qualifica para Compute Flexible CUDs com 17% tanto em 1 quanto em 3 anos. A cobrança baseada em instâncias, jobs e worker pools continua com descontos de 28%/46%. Se você roda workloads serverless em escala, isso pode mexer de verdade na economia unitária do seu negócio.

A tabela a seguir resume a nova estrutura de descontos por gasto:

Depois da migração, a coluna "Savings" no seu dashboard de FinOps vai mostrar números bem menores. Se antes aparecia -US$ 10,00, agora pode aparecer -US$ 4,50. Aí vem o susto — até você entender o que está acontecendo.

O modelo antigo mostrava um crédito bruto que abatia todo o seu custo sob demanda. O novo modelo mostra a sua economia líquida real: a diferença entre o que você teria pago na tarifa sob demanda e o que efetivamente pagou na tarifa com desconto. O valor final da fatura e a economia real são idênticos nos dois casos. O que muda é só a forma de apresentar.

Nenhuma dessas mudanças mexe nas suas taxas de desconto reais. Um Compute Flexible CUD de 3 anos continua economizando 46% em compute geral. Um de 1 ano continua economizando 28%. Os dólares que saem do seu bolso são exatamente os mesmos antes e depois da migração. O Google mudou como a economia é exibida, não como ela é calculada. Que isso fique bem claro.

Isso também vai exigir conversas com CFOs e stakeholders acostumados a ver números altos de crédito. Quando perguntarem por que os créditos de CUD caíram 55%, você vai precisar explicar que agora estão vendo a economia real, e não compensações contábeis.

O valor do meu commitment vai aumentar se eu não optar pela mudança?

Não. Quando o Google migra você automaticamente, os commitments existentes são convertidos para valores equivalentes no novo modelo. Se você tinha um commitment de US$ 185/hora (expresso como equivalente sob demanda), ele vira um commitment de US$ 100/hora (o seu gasto real com desconto). Mesma cobertura, mesmo custo, rótulo diferente. O bolso continua exatamente igual; o que muda é a forma de reportar.

Os meus CUDs atuais vão cobrir menos depois da migração?

Não — pelo contrário. Todos os CUDs existentes vão cobrir pelo menos o que cobriam antes, e muitos vão cobrir mais SKUs graças à elegibilidade ampliada. Se você tem Compute Flexible CUDs hoje, eles passam a cobrir automaticamente workloads recém-elegíveis, como a cobrança por requisições do Cloud Run, instâncias H3/H4D e VMs otimizadas para memória. Ou seja, melhor aproveitamento dos commitments que você já comprou, sem precisar mexer em nada.

Então o que muda, na prática?

A exibição e a estrutura dos dados. Os percentuais de desconto continuam os mesmos. Os custos de commitment continuam os mesmos. A cobertura ou continua igual ou melhora. As mudanças são:

1. Como os valores de commitment são expressos
2. Como a economia aparece nas exportações de billing
3. Quais SKUs são elegíveis para cobertura.

É só isso.

Vale destacar o que essa migração não muda. Os committed use discounts baseados em recursos — em que você se compromete com quantidades específicas de vCPU, memória, GPU ou Local SSD em uma região e projeto definidos — continuam funcionando exatamente como antes. Eles seguem sendo ideais para workloads previsíveis, em regime estável e com requisitos de recursos consistentes.

As principais diferenças se mantêm:

• CUDs baseados em recursos são específicos por projeto e região (mas dá para habilitar o compartilhamento dentro de uma billing account).
• Os Flex CUDs por gasto se aplicam automaticamente a todo uso elegível dentro de uma billing account.

Os commitments baseados em recursos oferecem taxas de desconto um pouco maiores para compute geral (até 55% em 3 anos contra 46% do Flex), mas exigem um planejamento de capacidade mais preciso.

O que sempre recomendo para a maioria das organizações é combinar os dois: CUDs baseados em recursos para os workloads de baseline e previsíveis, e Flex CUDs para o uso variável ou distribuído, mais difícil de cravar por região e tipo de máquina.

O novo modelo multiprice de CUD é a mudança mais relevante de billing do Google Cloud em anos. A cobertura ampliada e o modelo de dados mais limpo são avanços importantes. Agora, cabe a você garantir que os seus sistemas internos estejam prontos para aproveitar tudo isso — e, se quiser que a gente da DoiT te ajude, vamos conversar.