A fatura mente sobre o mês parcial: como projetar custo AWS quando a RI cai como lançamento único no dia 1

O contexto: validar a economia antes do mês fechar

Uma aplicação transacional passou por otimização de custos: rightsizing de RDS e compra de Reserved Instances. A pergunta da gestão no meio do mês: "a economia está vindo mesmo?". Trajetória: janeiro US$1.670 (baseline) → março US$1.220 (-27%, mês parcial) → abril projetado ~US$724 (-57%). O problema é projetar o abril parcial sem mentir.

A armadilha: pró-rata ingênuo superestima

O instinto é pegar o gasto até hoje e multiplicar pela fração do mês. Isso quebra por dois motivos:

Benefício parcial das mudanças. O rightsizing entrou no dia 15 (16 dias de benefício no mês); as RIs no dia 22 (9 dias). Os dias antes ainda eram caros — projetar a partir da média do mês mistura tarifas.

RI No-Upfront não é diluída. Ela aparece como UM lançamento, geralmente no dia 1, equivalente ao mês todo — não como custo diário. Multiplicar o acumulado pela fração do mês conta a RI duas vezes.

Reserved Instance No-Upfront é cobrança fixa que cai de uma vez, não custo por hora diluído. Tratá-la como variável no pró-rata é o erro mais comum ao projetar um mês parcial.

A fórmula correta

Separe o que é fixo do que é variável e só faça pró-rata do variável:

Projeção do mês = (RI fixa, valor cheio do mês)
               + (custo variável até hoje ÷ dias decorridos × dias do mês)
               + (impostos sobre o total)

Conferência da RI como lançamento único:
  r6g.xlarge No-Upfront: US$0,248/h × 24 × 30 ≈ US$178,56/mês
  Real na fatura:        US$178,76   ✓  (cai como 1 linha, não 720 por hora)

Com a RI fora do pró-rata e o variável projetado corretamente, a projeção bateu nos ~US$724 (-57%) — e a gestão viu o número certo, não um inflado pelo método errado.

Como puxar os números

aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-04-30 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[].Groups[].{T:Keys[0],V:Metrics.UnblendedCost.Amount}' --output table
# HeavyUsage = RI (fixa) ; BoxUsage = on-demand (variável a pró-ratear)

Lições

1. RI No-Upfront é lançamento único, não custo/hora. Some o valor cheio do mês uma vez; nunca a pró-rateie.

2. Pró-rata só vale para o variável (BoxUsage). Separe HeavyUsage de BoxUsage antes de projetar.

3. Mudanças no meio do mês têm benefício parcial. Rightsizing/RI que entraram no dia 15/22 só economizam nos dias seguintes; não projete a partir da média do mês inteiro.

Conclusão

Otimizar custo é metade do trabalho; provar a otimização sem mentir é a outra. A fatura AWS de um mês parcial mistura uma cobrança fixa que caiu no dia 1 com custo variável diário — e o pró-rata ingênuo conta a RI duas vezes. Separando fixo de variável, a projeção de -57% se sustentou na fatura final.