1.1 O que a nuvem mudou no dinheiro

O resultado: finanças perde a visibilidade e o controle que tinha, e a conta cresce sem que ninguém sinta-se responsável — o clássico "a nuvem saiu cara e ninguém sabe explicar por quê".

1.2 A definição

Segundo a FinOps Foundation (a organização que mantém o framework): FinOps é "uma disciplina de gestão financeira de nuvem e uma prática cultural que permite às organizações obter o máximo valor de negócio, ajudando times de engenharia, finanças e negócio a colaborar em decisões de gasto orientadas por dados".

1.3 O FinOps Framework

Os princípios

• Times colaboram (engenharia, finanças, produto, liderança).
• Decisões são guiadas pelo valor de negócio da nuvem.
• Todos são donos do seu uso da nuvem (accountability distribuída).
• Os dados de FinOps são acessíveis e oportunos.
• Um time central conduz a prática (habilita, não controla tudo).
• Aproveitar o modelo de custo variável da nuvem (é uma vantagem, não só um risco).

As personas

FinOps é um esporte de times: praticante/analista de FinOps, engenharia/DevOps/plataforma, finanças, procurement, liderança de produto e executivos, e cada vez mais times de dados e de IA/ML.

As três fases (um ciclo iterativo)

Não é uma escada — é uma roda que gira continuamente, em maturidade crescente (Módulo 9).

2.1 Os modelos de preço

2.2 Onde o dinheiro vaza

• Recursos ociosos e órfãos: VMs paradas mas ligadas, discos sem VM, IPs reservados sem uso, snapshots antigos, load balancers sem tráfego, ambientes de teste rodando no fim de semana.
• Superdimensionamento (over-provisioning): instância 8x maior do que a carga usa; banco com IOPS provisionado no talo "por segurança".
• Preço cheio evitável: carga estável rodando on-demand quando poderia ter commitment; nada de spot em cargas batch.
• Transferência de dados (egress): tráfego saindo da nuvem, entre regiões, entre zonas — a linha da fatura que mais surpreende.
• Armazenamento sem ciclo de vida: tudo em hot storage para sempre; logs retidos além do necessário; versões antigas nunca expiradas.
• Serviços gerenciados premium usados onde um mais simples bastava.

2.3 A fatura: o dado bruto do FinOps

Todo provedor entrega um arquivo detalhado de faturamento (AWS CUR — Cost and Usage Report; GCP Billing Export; Azure Cost details). É a fonte de verdade: cada linha tem serviço, tipo de uso, região, conta/projeto, tags, quantidade, custo on-demand, custo efetivo (com desconto), e a amortização de commitments. A FOCUS (FinOps Open Cost and Usage Specification) é um esquema aberto que padroniza esses formatos entre provedores — o "Parquet das faturas de nuvem" — e vale conhecer.

3.1 A regra de ouro: você não otimiza o que não consegue atribuir

Antes de qualquer otimização, o custo precisa ser alocável: quanto deste gasto é do time A, do produto X, do cliente Y, do ambiente de produção? Sem isso, FinOps é impossível — ninguém sente responsabilidade por um número que não é "dele".

3.2 Estratégia de tagging/labeling

• Defina um conjunto mínimo obrigatório: por exemplo owner/team, environment (prod/staging/dev), service/app, cost-center, product. Poucas tags, bem aplicadas, valem mais que vinte inconsistentes.
• Padronize os valores: team=payments e não Team: Payments, pmts, payment-team. Documente o vocabulário permitido.
• Force via automação: tags aplicadas no IaC (Terraform), políticas que barram criação de recurso sem tag (AWS SCP / tag policies, Azure Policy, GCP org policy), e tag herdada da conta/projeto quando o recurso não suporta tag.
• Meça a cobertura de tagging como um KPI (% do custo alocável) e persiga o que ficou "untagged".
• Hierarquia de contas/projetos como alocação estrutural: uma conta AWS ou projeto GCP por time/ambiente já resolve a maior parte da alocação, independente de tags.

3.3 Showback × Chargeback

3.4 Custos compartilhados

Rede, cluster de Kubernetes compartilhado, ferramentas de observabilidade, o time de plataforma, os descontos de commitment — nada disso pertence a um time só. Estratégias de rateio:

• Proporcional ao consumo de cada time (ex.: dividir o custo do cluster por uso de CPU/memória por namespace — Módulo 8).
• Igualitário entre times (simples, justo para custos verdadeiramente comuns).
• Por métrica de negócio (por receita, por nº de clientes) — quando faz sentido estratégico.
• Absorvido pela plataforma (o time central "come" o custo comum) — reduz atrito, mas esconde o custo real do time.
• Distribuição de commitments: o desconto do Savings Plan deve ser distribuído aos times que geraram o uso coberto, não ficar todo com quem comprou — senão o incentivo se perde.

Escolha uma regra, documente, e seja consistente. Rateio que muda todo mês destrói a confiança no número.

4.1 Unit economics: o número que importa

"Gastamos R$ 500 mil/mês em nuvem" não diz se está bom. "Gastamos R$ 0,12 por pedido processado, e caiu de R$ 0,15" diz. O custo unitário conecta a nuvem ao valor e permite decidir com clareza.

4.2 Previsão (forecasting)

• Baseline + tendência + sazonalidade: extrapolar o histórico (com cuidado: Black Friday, fim de trimestre, lançamentos).
• Bottom-up por driver: "custo ≈ nº de clientes previsto × custo unitário × fator de eficiência esperado" — mais explicável e defensável que uma curva.
• Incorporar o roadmap: o novo produto que sobe em março, a migração que desliga um sistema em junho.
• Faixas, não ponto: cenário conservador / esperado / agressivo. Finanças precisa da faixa.
• Comparar previsto × realizado todo mês e ajustar o modelo (o forecast é um produto vivo).

4.3 Orçamento e detecção de anomalia

• Budgets por time/produto com alertas em % (50/80/100/forecast-to-exceed). O alerta vai para o dono, não só para o FinOps.
• Anomaly detection (nativo dos provedores ou de ferramenta): detecta um salto fora do padrão — um JOIN cartesiano num warehouse, um loop de retry, um ambiente esquecido ligado, uma chave vazada minerando cripto. Quanto antes o alarme, menor o estrago.
• Alerta acionável: "o serviço X subiu 3× ontem, provável causa Y, dono Z" — não "o custo total variou".

5.1 As duas alavancas de otimização

• Rate optimization (este módulo): reduzir o preço unitário do recurso sem mudar o que você usa — commitments, spot, negociação, tiers de storage.
• Usage optimization (Módulo 6): reduzir o que você usa — desligar, redimensionar, arquitetar melhor.

Ordem prática recomendada: elimine o desperdício primeiro (Módulo 6), depois compre commitments sobre a base já enxuta — senão você compromete 3 anos de uma instância que nem deveria existir.

5.2 Commitments: o vocabulário

5.3 A estratégia de portfólio

Pense nas suas cargas como camadas de risco, e cubra cada uma com o instrumento certo:

   uso (vCPU-hora)
   │
   │            ┌─────────────── pico variável → ON-DEMAND (paga caro, mas só quando precisa)
   │      ┌─────┤
   │      │     └─────────────── carga tolerante a interrupção → SPOT (batch, CI, workers)
   │  ┌───┤
   │  │   └───────────────────── camada intermediária → SAVINGS PLAN de 1 ano (flexível)
   │  │
   │  └───────────────────────── base estável 24/7 há meses → RI / SP de 3 ANOS (desconto máximo)
   └────────────────────────────────────────────────────────────────────▶ tempo

• Comprometa só a base sólida. A regra prática: cubra o que você tem quase certeza de que ainda estará rodando daqui a 1–3 anos. Deixe a parte incerta em on-demand/SP curto.
• Meta de cobertura típica: 70–85% da base estável (não 100% — você quer folga para reduzir sem ficar com commitment ocioso).
• Meta de utilização: > 95%. Utilização baixa significa que você comprometeu demais.
• Escalone os vencimentos (laddering): não deixe tudo vencer no mesmo mês; compre em ondas para acompanhar o crescimento.
• Prefira o instrumento flexível (Savings Plan / compute-flexible) a menos que a economia extra do RI rígido seja grande e a carga seja realmente imóvel.
• Revisão contínua: cobertura e utilização são métricas de dashboard semanal, com dono.

5.4 Outras otimizações de taxa

• Storage tiering: mover dados frios para tiers baratos (infrequent access, archive/Glacier) via políticas de ciclo de vida; escolher a classe certa na escrita.
• Licenças: BYOL (traga sua licença), edições de banco/SO adequadas, evitar SKUs "enterprise" onde não precisa.
• Região: preços variam por região; para cargas sem exigência de latência/soberania, uma região mais barata ajuda (pesando egress).
• Committed spend com o provedor (EDP / MACC): contrato plurianual de gasto mínimo em troca de desconto geral — assunto do Módulo 9.

6.1 Rightsizing

Ajustar o tamanho/tipo do recurso ao que a carga realmente usa, com base em métricas (CPU, memória, rede, IOPS) de um período representativo (2–4 semanas, incluindo pico).

• Alvos: VMs com utilização de pico baixa, bancos superdimensionados, discos com IOPS provisionado ocioso, clusters com nós vazios.
• Considere famílias mais novas (melhor preço/performance) e arquiteturas ARM (Graviton na AWS, Axion no GCP, Cobalt no Azure) — costumam dar 20–40% de custo/performance para cargas compatíveis.
• Cuidado: rightsizing agressivo demais causa incidente. Deixe margem para pico e crescimento; faça gradual e monitore.

6.2 Elasticidade: autoscaling e "parking"

• Autoscaling horizontal por demanda (RPS, fila, CPU) — pague pelo pico só durante o pico. Configure limites e cooldown para não oscilar.
• Scale-to-zero para serviços de uso esporádico (serverless, KEDA, Knative).
• Scheduling / parking: desligar dev, staging, QA fora do horário de trabalho. Uma carga que roda 8h/dia útil em vez de 24/7 custa ~25%. É uma das economias mais fáceis e maiores.
• Ambientes efêmeros: ambiente de PR criado no merge e destruído no fim — nada esquecido ligado.

6.3 Eliminação de desperdício (a faxina permanente)

6.4 Arquitetura como alavanca de custo avançado

As maiores economias raramente vêm de mexer num slider — vêm de decisão de design:

• Serverless/managed vs sempre-ligado para cargas intermitentes.
• Assíncrono e batch em vez de processamento síncrono caro em tempo real, quando o negócio permite.
• Cache (resultado, borda, dados) para não recomputar/reconsultar.
• Escolha de datastore adequada ao padrão de acesso (ver apostilas de SQL/NoSQL e Engenharia de Dados).
• Multi-tenant em vez de stack dedicada por cliente pequeno.
• Data gravity: processar perto de onde o dado está para evitar egress e cópias.

7.1 O time central de FinOps: habilita, não policia

O time de FinOps (às vezes uma pessoa, às vezes um CCoE — Cloud Center of Excellence) não aprova cada recurso nem "é o dono do custo". Ele: constrói a visibilidade e as ferramentas, define padrões e políticas, treina e evangeliza, gerencia o portfólio de commitments e a negociação com o fornecedor, roda a cadência de reuniões, e destrava decisões que precisam de finanças + engenharia + negócio juntos. A responsabilidade pelo custo é de cada time de engenharia — o FinOps dá o mapa e a bússola.

7.2 KPIs de FinOps

7.3 Cadência e rituais

• Semanal: o time de FinOps revisa anomalias, cobertura/utilização de commitments, e recomendações novas.
• Mensal: revisão de custo com cada time de engenharia — seu gasto, sua tendência, seu custo unitário, suas recomendações pendentes; previsto × realizado com finanças.
• Trimestral: revisão de estratégia — compra de commitments, metas de eficiência do próximo trimestre, roadmap e seu impacto de custo, negociação com fornecedor.
• Contínuo: custo no design review; alertas indo para os donos; canal onde times pedem ajuda.

7.4 Automação e "policy as code"

• Tags obrigatórias forçadas na criação; recurso sem tag é bloqueado ou marcado para remoção.
• Start/stop agendado de ambientes não-produtivos.
• Limpeza automática de recursos órfãos e de ambientes efêmeros com TTL vencido.
• Políticas de tamanho máximo / tipos permitidos por ambiente (guardrails, não gates).
• Recomendações de rightsizing e de commitment geradas e roteadas automaticamente para o time dono.
• Alertas de anomalia e de budget para o Slack/Teams do time, não para um e-mail que ninguém lê.

8.1 Kubernetes: alocar o cluster compartilhado

Um cluster é uma fatura só, mas dezenas de times rodam nele. O custo precisa ser dividido por consumo real de cada workload.

• Ferramentas: OpenCost (padrão CNCF, open source) e Kubecost — alocam o custo dos nós por namespace/deployment/label, com base em CPU e memória requested vs used.
• Request vs usage: o grande desperdício de K8s é gente pedindo (requests) muito mais do que usa — o cluster "enche" de reservas ociosas e escala nós à toa. Meça o gap e ajuste requests (VPA ajuda).
• Bin packing e autoscaling de nós (Cluster Autoscaler, Karpenter): consolidar pods em menos nós, usar spot para workloads tolerantes, escalar a base para o mínimo.
• Custo compartilhado do cluster (control plane, system pods, folga): ratear proporcionalmente ou absorver na plataforma — regra documentada.
• Idle cost: quanto do cluster está pago e vazio — KPI de eficiência do time de plataforma.

8.2 Dados: o custo que se esconde nas queries

• Warehouses (BigQuery, Snowflake, Redshift): custo por dado escaneado ou por tempo de warehouse ligado. Alavancas: particionar/clusterizar para escanear menos, materializar o que se repete, matar full-refresh desnecessário, desligar warehouse ocioso, alertar nas 10 queries mais caras, e educar sobre SELECT *.
• Pipelines (Spark, ETL): spot para jobs batch, rightsizing de cluster, evitar shuffle e reprocessamento (ver apostila de Engenharia de Dados).
• Storage do lake: compactar arquivos pequenos, tiering, expirar snapshots de Iceberg/Delta.
• Alocação: custo por dataset / por time / por dashboard — quem gera a query, paga.

8.3 IA e GenAI: a nova fronteira de custo

Cargas de IA têm drivers de custo próprios e crescem rápido. FinOps aqui olha:

• Custo por token (APIs de LLM): entrada vs saída, escolha de modelo por tarefa, tamanho de contexto, prompts enxutos, caching, batching, "model routing" (modelo barato para o fácil).
• GPU: o recurso mais caro — utilização de GPU como KPI, spot/reserved para treino, compartilhamento (MIG, time-slicing), scale-to-zero de endpoints de inferência, quantização.
• Unit economics de IA: custo por resposta, por documento, por usuário de IA — e se isso cabe no preço do produto.
• Denial of wallet: abuso que infla custo — quota e rate limit por usuário, teto de custo por requisição (ver apostila de Segurança de Aplicações de IA).
• A FinOps Foundation trata isso como o "FinOps for AI" — e há uma apostila irmã (Otimização de Custos de Cloud e IA) com as táticas técnicas em detalhe.

9.1 Maturidade: Crawl → Walk → Run

Cada capability do framework (alocação, forecast, rate optimization, anomaly management…) pode estar em estágios diferentes. Avalie por capability e priorize as que dão mais retorno.

9.2 Ferramentas

Regra: comece com o nativo + um dashboard. Plataforma paga se justifica com multi-cloud, muitas contas, ou necessidade de alocação/automação sofisticada — e ela mesma custa (às vezes % do gasto).

9.3 Contratos e negociação com o provedor

• Committed spend agreements (AWS EDP/PPA, Google, Azure MACC): compromisso plurianual de gasto mínimo em troca de desconto percentual sobre toda a fatura, créditos e suporte. Negocie com dados de forecast na mão e não comprometa acima do piso confiável.
• Marketplace: compras via marketplace do provedor às vezes contam para o committed spend — pode ser alavanca de negociação.
• Timing: fim de trimestre/ano do fornecedor melhora a margem de negociação.
• Não deixe o desconto virar preguiça: desconto contratual não substitui otimização de uso — ele multiplica a economia de um ambiente já enxuto.

9.4 FinOps + sustentabilidade e + segurança

• GreenOps: reduzir desperdício de nuvem quase sempre reduz emissões; regiões mais limpas, horários de menor intensidade de carbono para batch, e o carbono como métrica ao lado do custo.
• Segurança: recursos órfãos e não-tagueados também são risco de segurança; picos de custo podem indicar comprometimento (cripto-mineração). FinOps e SecOps compartilham o inventário.

9.5 Armadilhas que afundam programas de FinOps

• Virar polícia de custo — gates manuais, "não pode criar nada" — a engenharia sabota.
• Só falar de corte — sem ligar a valor, FinOps vira o vilão e perde apoio.
• Chargeback prematuro sobre alocação ruim — gera briga interna.
• Comprar commitment sobre desperdício — comprometer 3 anos do que deveria ser desligado.
• Ferramenta antes de cultura — comprar plataforma cara e ninguém olhar os relatórios.
• Alertas sem dono — vão para uma lista que ninguém lê.
• Otimização de uma vez — sem cadência, o desperdício volta em três meses.
• Ignorar dados e IA — onde o custo mais cresce hoje.

10.1 Os perfis que contratam

10.2 Certificação e comunidade

• FinOps Certified Practitioner (FOCP) — a certificação de entrada da FinOps Foundation, quase sempre citada em vagas. Há trilhas avançadas (Engineer, Professional) e específicas (FinOps for AI, para setores).
• FinOps Framework (documentação aberta da FinOps Foundation) — leitura obrigatória; conheça princípios, personas, fases e as capabilities.
• Comunidade: FinOps Foundation (Slack, eventos FinOps X), State of FinOps report anual.
• Certificações de nuvem (AWS/GCP/Azure a nível de arquitetura/prática) complementam bem.

10.3 Roadmap de estudo (8 semanas)

10.4 Banco de perguntas de entrevista (com a resposta que aprova)

10.5 Projetos de portfólio que geram entrevista

1. Análise de conta (âncora): pegue uma conta de nuvem (sua, de laboratório, ou um dataset de billing público) e produza um relatório FinOps completo: alocação por time/serviço, unit economics, cobertura/utilização de commitments, top desperdícios com economia estimada e risco, e um plano Inform/Optimize/Operate. Publique como estudo de caso.
2. Dashboard de custo do zero: billing export → warehouse (BigQuery/DuckDB) → dashboard (Looker Studio/Metabase) com showback, tendência e alarme de anomalia; bônus se normalizar via FOCUS.
3. Automação de economia: um script/pipeline que agenda start/stop de ambientes não-produtivos, ou que detecta e reporta recursos órfãos, com o "antes/depois" da economia.
4. Alocação de Kubernetes: subir OpenCost num cluster de estudo e produzir showback por namespace com o gap request-vs-uso e recomendações.
5. Modelo de unit economics de um produto de IA: planilha/notebook que calcula custo por resposta em função de modelo, tokens, cache e volume, com cenários.