Commitments são um alvo em movimento. Os recomendadores nativos erram o alvo, então criamos o nosso.

Como nosso motor encontra o número

Na verdade, são dois motores. Um para os Savings Plans da AWS, outro para os committed use discounts (CUDs) do Google Cloud. Código separado, porque as duas nuvens precificam e aplicam commitments de formas genuinamente diferentes, e fingir o contrário nos custaria precisão. A ideia por baixo, porém, é a mesma.

Tudo começa com dados brutos de uso. Pegamos cada hora de gasto que um commitment poderia cobrir durante a janela de análise — o que, para uma janela de 60 dias, significa olhar cerca de 1.440 horas individuais e seus valores exatos. Algumas dessas horas estarão a todo vapor. Outras, completamente paradas, principalmente na queda do fim de semana. Descobrir como lidar com esse formato que oscila tanto é o verdadeiro desafio aqui.

Depois, descontamos o que você já tem. Se você possui Savings Plans ou CUDs ativos, nós os aplicamos a cada hora do mesmo jeito que o provedor de nuvem faz, do maior desconto para o menor. O que esses planos já cobrem está fora do jogo. O que sobra é o gasto em que um novo commitment ainda pode gerar economia.

Também consideramos cada desconto que você já tem. Preços negociados em contrato. Descontos por uso contínuo (sustained-use) no Google Cloud. Cobertura do Flexsave da DoiT, se você usa. Um commitment só faz sentido se superar o preço que você realmente paga hoje, então é contra esse preço que comparamos, não o preço de tabela.

Os dois motores são separados porque AWS e Google Cloud expõem os dados de billing de formas diferentes e aplicam commitments segundo suas próprias regras. O princípio, porém, é compartilhado: precificar o commitment contra o que você realmente paga, não contra um preço de tabela que nunca aparece na sua fatura.

Agora, a parte que importa.

Escolha qualquer commitment por hora que você poderia comprar. Ao longo da janela, você pagaria duas coisas. O próprio commitment, em cada hora, usado ou não. Mais o gasto on-demand que ainda transborda nas horas de pico. Some os dois e esse é seu custo total naquele nível de commitment.

Um exemplo rápido. Uma hora tem US$ 100 de gasto elegível e você se comprometeu com US$ 30 por hora a um desconto de 40%, para simplificar. Esses US$ 30 compram/cobrem US$ 50 de uso on-demand. Então você paga US$ 30 pelo commitment, US$ 50 on-demand pelo restante, US$ 80 no total em vez de US$ 100. Até aí, tudo bem. Agora pegue uma hora tranquila com apenas US$ 40 de gasto elegível. Seus US$ 30 continuam comprando US$ 50 de cobertura, só que há apenas US$ 40 para cobrir. Você paga US$ 30, economiza US$ 10, e uma fatia do commitment fica ali parada. O recomendador roda essa aritmética para cada hora da janela e soma tudo. Depois faz o mesmo para cada nível de commitment que poderia recomendar, para ver qual economiza mais.

Plote esse total contra o tamanho do commitment e você obtém uma curva em forma de tigela. O fundo da tigela é o ponto ideal: o commitment em que sua fatura total é a mais baixa.

No lado esquerdo, você está subcomprometido. Cada dólar extra de commitment substitui mais de um dólar de gasto on-demand, então o custo total cai. No lado direito, você está supercomprometido. O commitment extra fica ocioso nas horas tranquilas, então o custo total volta a subir.

O fundo da tigela é o ponto em que um dólar a mais comprometido custaria mais do que economiza. Esse é o melhor commitment. Não o caçamos testando cada valor centavo a centavo para ficar com o mais barato. O formato da curva nos diz onde ela vira, então vamos direto a esse ponto.

Depois você escolhe uma política de risco. Conservative, Balanced, Max Savings, ou algo que você mesmo define. Cada uma pega uma fração desse melhor commitment, 65%, 80% ou 90%, o que deixa folga para a semana em que seu uso cai. Políticas personalizadas vão além: até dez por cliente, cada uma com sua própria meta de cobertura e seus próprios passos de compra, para que a recomendação siga as suas regras, e não os três presets que um fornecedor de nuvem imaginou. Expliquei por que essa folga importa, e por que compramos em etapas em vez de tudo de uma vez, em um post anterior sobre o problema do dimensionamento.

Em cima de tudo isso há um pequeno conjunto de ajustes finos. Nós os calibramos conforme compras reais nos ensinam coisas. A função deles é manter a recomendação do lado cauteloso do valor ideal de commitment.

Por exemplo, o fundo da tigela pode parecer plano em alguns casos. Uma faixa de commitments, e não um número exato, economiza quase o mesmo valor. A matemática sozinha apontaria alegremente para o maior deles, mas nós não. Quando vários tamanhos economizam mais ou menos o mesmo, pegamos o menor. Mesma economia, menos dinheiro travado, mais espaço se um workload desaparecer no mês que vem.

Esses ajustes também nos permitem reagir ao que vemos em produção. Se o uso de uma conta tende a cair ao longo da janela, a recomendação tende a ser menor. Se uma compra se mostra menos útil do que o modelo esperava, aprendemos com isso e a próxima recomendação é mais cautelosa.

E como o motor é nosso, quando um cliente pede algo específico, como "nunca fique abaixo de 70% de utilização" ou "deixe uma folga extra, vamos consolidar contas no 3º trimestre", podemos atender. Você não pode pedir à AWS ou ao Google que rodem o recomendador deles com as suas regras. Mas pode pedir a nós, ou criar sua própria política, e nós a seguiremos.

Onde concordamos com as nuvens

Antes de falar das diferenças, vamos falar de confiança. Se o nosso número estivesse longe do número da nuvem, você teria razão em perguntar qual dos dois está errado.

Então verificamos.

Uma coisa precisa estar certa primeiro, ou a comparação inteira vira ruído: os dois recomendadores precisam olhar para os mesmos dias de uso. Todo recomendador dimensiona com base em uma janela de lookback, um trecho fixo de horas passadas. A AWS permite escolher até os últimos 60 dias. O nosso pode ser configurado para qualquer período. Se as duas janelas não coincidirem, mesmo que por poucos dias, os números vão divergir, e essa diferença não tem nada a ver com método e tudo a ver com datas. Então, em cada comparação abaixo, configuramos nosso motor exatamente com as mesmas datas de início e fim usadas pela AWS ou pelo Google. Os mesmos dias entram; depois comparamos o que sai.

Na AWS, rodamos nosso motor contra o AWS Purchase Analyzer em várias contas. Testamos todas as combinações: prazos de um e três anos, sem pagamento adiantado, com pagamento parcial e com pagamento total adiantado. Mesma janela de lookback dos dois lados. Nosso commitment recomendado ficou a menos de 1% do número da AWS em todos os casos. Também rodamos o motor no nosso maior cliente AWS para garantir que ele dá conta em escala. E dá.

No Google Cloud, comparamos com as recomendações exibidas no console do GCP. Em uma conta de billing com preços padrão, batemos com o Google centavo a centavo, em todos os oito escopos de commitment que testamos. Isso inclui CUDs Compute Flexible, Memorystore e Cloud SQL em cada região. Em uma conta com descontos negociados, ficamos a menos de 1%.

Nuvem	Tipo de conta	Escopos testados	Nosso número vs. o da nuvem
AWS	Conta pagadora de médio porte, todas as combinações de prazo e pagamento	6	Diferença inferior a 1%
AWS	Nosso maior cliente	6	Roda sem problemas, diferença inferior a 1%
Google Cloud	Preços padrão	8	Correspondência exata, centavo a centavo
Google Cloud	Descontos negociados	8	Diferença inferior a 1%

A questão é simples. Quando você faz a mesma pergunta, recebe a mesma resposta. Ninguém está inventando um número maior para te vender mais.

Então, por que construir o nosso?

Onde as nuvens param e nós continuamos

Estas são as perguntas que nossos clientes realmente fazem. Em cada caso, o recomendador da nuvem ou não consegue responder, ou faz você esperar. A versão curta, antes dos detalhes:

	AWS	Google Cloud	DoiT
Precisão da recomendação	Referência	Referência	Diferença inferior a 1% em relação às duas
Todas as opções de prazo e pagamento, sob demanda	20 análises por dia, uma de cada vez	Apenas alguns cenários	Todas as combinações em menos de 20 segundos
API síncrona	Job assíncrono, polling por minutos	Não disponível	Sim
Explicar por que o número mudou	Não	Não	Sim, até as linhas de billing
Escopo por conta ou SKU	Não	Não	Sim
Intervalo de datas personalizado	Parcial	Parcial	Sim
Independente da API da nuvem no dia da compra	Não	Não	Sim, lê os dados de billing diretamente
Esteira automatizada de compras escalonadas	Não	Não	Sim
Commitments expirando	Recomenda de novo após a expiração	Recomenda de novo após a expiração	Substituição dimensionada e agendada antes da expiração
Monitoramento humano da utilização	Não	Não	Sim, equipe dedicada da DoiT

"Quero comparar 1 ano vs. 3 anos, sem adiantamento vs. tudo adiantado, e três níveis de risco, antes de decidir."

Na AWS, cada um desses é uma análise separada. O Purchase Analyzer permite 20 análises por conta pagadora por dia. Cada uma leva de alguns segundos a minutos, e elas rodam uma de cada vez. Para ver o quadro completo de uma conta pagadora, você precisa de mais análises do que a AWS permite em um dia. Então você escolhe algumas, espera e torce para ter escolhido certo.

O Google Cloud é mais flexível aqui. O console permite montar cenários com diferentes períodos de lookback, e você pode excluir um conjunto de datas. Útil. Mas para por aí. Você recebe as opções que o Google imaginou, nos termos do Google, e quando quer algo fora dessa lista, está por conta própria.

Nosso motor produz todas as combinações de uma conta pagadora em menos de 20 segundos. Você pode rodá-lo quantas vezes quiser.

"Quero integrar as recomendações às minhas próprias ferramentas."

O recomendador da AWS é um job assíncrono. Você o inicia e depois faz polling até ele terminar, segundos ou minutos depois. Construir um pipeline confiável em cima disso dá trabalho, e o limite diário continua valendo.

A recomendação do console do Google Cloud foi feita para leitura, não para alimentar um fluxo de compra.

A nossa é uma API REST síncrona, parte da API do DoiT Cloud Intelligence. Você chama o endpoint com sua chave de API e recebe a recomendação de volta na mesma resposta. Ela tem o mesmo formato na AWS e no Google Cloud, então uma única integração cobre as duas. Você pode postar a recomendação diária no Slack, abrir um ticket quando ela variar além de um limite, ou puxá-la para o seu próprio dashboard de FinOps, ao lado do restante dos seus dados de custo.

E como é uma API síncrona simples, ela se conecta a um assistente de IA tão facilmente quanto a um dashboard. Conecte-a ao Claude, ou ao que você usar, e pergunte com palavras: "Qual é a recomendação para o Cloud SQL em us-east1?" "Quando expira meu próximo commitment?" "Quanto os commitments de computação nos economizaram no mês passado?" Experimente perguntar isso a um console.

Tudo também é calculado com antecedência. Cada opção, cada política, cada conta, uma vez por dia. Então, quando você ou seu assistente perguntam, nada entra na fila, nada esbarra em limite de requisições, e não há espera por opção. A resposta já está lá.

"Por que o número mudou desde a semana passada?"

Vimos a recomendação de uma conta pagadora da AWS oscilar entre dois níveis bem diferentes dentro de uma única semana. Nada no uso explicava isso. Nosso melhor palpite é que a causa está na janela móvel e no dia da semana em que você pergunta. Mas não temos certeza, porque o Purchase Analyzer não mostra seus cálculos com clareza suficiente para verificar.

Cada número que nosso motor produz pode ser rastreado até as linhas de billing. Quando um cliente pergunta por que a recomendação mudou, podemos mostrar quais horas mudaram e em quanto. Muitas vezes a resposta é simples: um job em lote parou de rodar à noite, ou um novo ambiente entrou no ar na quinta-feira. De qualquer forma, você recebe uma resposta em vez de um dar de ombros.

"Aquela conta está sendo desativada. Pode ignorar."

Ou: "Deixe esses SKUs de fora, estamos migrando esse workload." Ou: "Dimensione com base no trimestre passado, não na janela padrão."

Nenhuma das nuvens permite delimitar a recomendação por conta, por SKU ou por um período explícito. Você recebe uma única resposta para a conta pagadora inteira, na janela que elas escolhem.

O nosso faz as três coisas. Exclua uma conta. Retire uma fração de SKUs específicos. Defina suas próprias datas de início e fim. A elegibilidade também é granular: quais contas vinculadas ou projetos entram no escopo dos commitments é uma configuração, e o motor dimensiona apenas com base neles. Hoje, nós configuramos isso para você; um controle self-service chega em breve. E há mais controles por trás disso do que qualquer um dos consoles expõe.

Uma observação honesta: hoje esses não são botões self-service no console. Você diz à sua equipe DoiT o que deixar de fora ou quais datas usar, e nós rodamos o motor com essas configurações para você. O ponto é que isso é possível, e que a resposta chega no mesmo dia. E tudo isso está no nosso radar: pretendemos entregar os controles aos clientes para que eles mesmos possam ajustar cada parte.

"E se o Cost Explorer estiver fora do ar no dia da compra?"

Isso parece um caso extremo até acontecer. Dimensionar um commitment não é um trabalho pontual. Como argumentei no post sobre dimensionamento, é um alvo em movimento que você precisa continuar acertando, semana após semana, enquanto seu uso muda debaixo dos seus pés. E o alvo se multiplica. Duas nuvens, computação mais banco de dados, várias regiões, cada uma com seu próprio commitment e sua própria data de expiração. Isso não é uma decisão semanal. É uma dúzia.

Um recomendador que depende de um job externo pode perder uma etapa. Se a API estiver lenta, com limite de requisições ou passando por um incidente, a compra daquela semana não acontece. O nosso lê seus dados de billing diretamente. Não há nada externo para esperar.

"Não quero ficar de babá disso."

O ponto é o seguinte. Essa é a verdadeira resposta para "por que eu preciso do de vocês".

Uma recomendação só é útil se alguém agir sobre ela. Nosso motor alimenta uma esteira automatizada de compras escalonadas. As compras acontecem nos bastidores, em uma cadência controlada pelo cliente, em etapas dimensionadas pela política escolhida. E uma equipe dedicada da DoiT monitora a utilização de cada commitment. Se algo começa a ficar ocioso, a equipe percebe antes que vire desperdício na sua fatura. Na AWS, isso pode até significar devolver um Savings Plan enquanto a janela de devolução ainda está aberta.

A expiração é tratada da mesma forma. Quando um plano está prestes a acabar, a próxima recomendação já assume que ele se foi, e a esteira agenda a substituição para começar no momento exato em que o antigo termina. A cobertura não cai por uma semana até alguém notar. Os recomendadores das nuvens só enxergam a lacuna depois que ela já se abriu.

Em breve, os clientes poderão definir a própria política de cadência de compras, além da política de risco que já escolhem hoje.