1.1 A distribuição típica de uma fatura

Regra de priorização: vá primeiro à maior categoria e ao maior serviço dentro dela. Uma economia de 20% em compute (que é 60% da fatura) vale mais que 80% numa linha que é 2%.

1.2 Medir antes de cortar

• Fonte de verdade: o relatório detalhado de faturamento (AWS CUR, GCP Billing Export, Azure Cost details), idealmente num warehouse ou ferramenta de análise. O padrão aberto FOCUS normaliza esses formatos.
• Métricas de utilização: CPU, memória, rede, IOPS, GPU — do provedor (CloudWatch, Cloud Monitoring) ou do seu observability stack, janela de 2–4 semanas.
• Ligue custo a uma unidade de valor (custo por requisição, por cliente, por job) — a apostila de FinOps detalha; aqui, basta ter o denominador para não confundir "gastou mais porque cresceu" com "gastou mais porque desperdiça".

1.3 As duas grandes alavancas

• Pagar menos pelo mesmo (otimização de taxa): commitments, spot, tiers de storage, ARM, negociação. Não muda o que roda.
• Usar menos (otimização de uso): rightsizing, autoscaling, parking, eliminar desperdício, arquitetura mais eficiente, código mais eficiente.

Ordem: elimine desperdício e faça rightsizing primeiro, depois aplique descontos sobre a base já enxuta — nunca comprometa 1–3 anos de algo superdimensionado.

2.1 Rightsizing

1. Colete métricas de 2–4 semanas (incluir picos e sazonalidade): CPU (média e p95/p99), memória, rede, IOPS.
2. Compare com o provisionado: uma VM com CPU de pico < 40% e memória < 50% é candidata a descer um ou dois tamanhos.
3. Escolha o tipo certo, não só o tamanho: família compute-optimized, memory-optimized, general, burstable (T-family / e2 — ótimas para cargas com CPU baixa e picos curtos, péssimas para CPU sustentada).
4. Gerações mais novas quase sempre têm melhor preço/desempenho — migrar da geração N-2 para a N costuma dar 10–20% de graça.
5. Aplique gradual, com margem para pico e crescimento, monitorando latência/erro depois.

2.2 Autoscaling

Configure com cuidado: métrica-alvo realista, limites mínimo/máximo, cooldown para não oscilar (flapping), e headroom para o autoscaler ter tempo de reagir ao pico. Autoscaling mal ajustado ou causa incidente (subiu tarde demais) ou não economiza (mínimo alto demais).

3.1 Spot / preemptible a fundo

Capacidade ociosa do provedor, 60–90% mais barata, que pode ser retomada com aviso curto (segundos a 2 minutos). O trade-off é explícito: você desiste de garantia de continuidade em troca de preço.

Cargas que combinam com spot

• Jobs batch e pipelines de dados (ETL, Spark) — reiniciam do checkpoint.
• CI/CD runners, testes, builds.
• Rendering, transcodificação, processamento científico.
• Treino de ML com checkpointing; inferência stateless atrás de fila com réplicas em várias pools.
• Workers de fila idempotentes — a mensagem volta para a fila se o worker morre.

Como usar spot com segurança

• Diversifique entre vários tipos de instância e zonas (spot fleet / mixed instances policy / Karpenter) — a chance de todas serem retomadas ao mesmo tempo cai muito.
• Trate o sinal de interrupção: drenar conexões, salvar checkpoint, devolver a tarefa à fila.
• Fallback para on-demand quando não houver capacidade spot (a política do autoscaler faz isso).
• Nunca spot para: bancos de dados stateful primários, nós de controle, cargas que não toleram reinício.

3.2 Parking: parar o não-produtivo

Ambientes de desenvolvimento, staging, QA e demo raramente precisam rodar 24/7. Uma carga que roda 12h em dias úteis (~60 h/semana em vez de 168) custa ~35% do valor; 8h/dia útil, ~25%.

• Agendador de start/stop (Instance Scheduler, cron + API, ferramenta de FinOps, kube-downscaler para K8s).
• "Ligar sob demanda": botão/Slack command para o dev subir o ambiente quando precisar fora de hora.
• Bancos gerenciados de dev também param (RDS/Cloud SQL têm stop; ou snapshot + destroy + restore).
• Exceções conscientes (um ambiente de testes noturnos automatizados) documentadas.

3.3 Ambientes efêmeros

Em vez de ambientes de staging permanentes, crie um ambiente por pull request (preview environment), destruído no merge/close. Zero recurso esquecido ligado, e cada mudança testada em isolamento. Ferramentas: preview deployments (Vercel/Netlify para front), terraform workspace + pipeline, namespaces efêmeros em K8s, Crossplane/vCluster.

4.1 O vocabulário e os instrumentos

4.2 As duas métricas que você gerencia

• Cobertura (coverage): % do uso elegível protegido por commitment. Meta: cobrir ~70–85% da base estável — não 100%, para ter folga de encolher sem ficar com commitment ocioso.
• Utilização (utilization): % do commitment comprado que está sendo usado. Meta: > 95%. Utilização baixa = comprou demais = pior que on-demand.

4.3 Estratégia prática

• Faça a faxina primeiro (Módulos 2–3): commitment sobre desperdício é dinheiro queimado por 1–3 anos.
• Cubra a base sólida: o que você tem quase certeza que estará rodando daqui a 1–3 anos.
• Prefira o instrumento flexível (Compute Savings Plan / CUD flexible) salvo se a carga for imóvel e o desconto extra do RI rígido for grande.
• Escalone (laddering): compre em ondas ao longo do ano, com vencimentos distribuídos, acompanhando o crescimento — evita "renovar tudo" num mês só.
• Comece com 1 ano se há incerteza; migre para 3 anos a parte que provou ser estável.
• Automação: ferramentas como ProsperOps, Spot.io, ou os próprios "recommendations" do provedor ajustam o portfólio continuamente; some marketplace de RIs para revender excedente (na AWS).
• Revisão semanal de cobertura e utilização, com dono.

5.1 Object storage: classes e ciclo de vida

• Lifecycle policies: "após 30 dias → IA; após 90 → Glacier; após 365 → Deep Archive ou expira". Configura uma vez, economiza para sempre.
• Intelligent-Tiering quando o padrão de acesso é imprevisível — evita a taxa de retrieval de mover cedo demais para IA.
• Cuidado com objetos pequenos: classes IA/Glacier têm tamanho mínimo cobrado (128 KB) e taxa por objeto — mover milhões de arquivos minúsculos para Glacier pode aumentar o custo.

5.2 A faxina de storage

• Discos (block) órfãos: volumes EBS/PD sem instância anexada — puro desperdício. Inventário + alarme + expiração.
• Snapshots antigos: política de retenção (manter N diários, M semanais, ...); apagar o resto. Snapshots incrementais escondem custo em cadeia.
• Versões e deletes marcados: buckets com versioning acumulam versões antigas para sempre sem lifecycle rule.
• Uploads multipart incompletos: regra para abortar após X dias.
• Backups além do necessário: alinhar retenção ao requisito real (RPO/legal), mover backups antigos para archive.
• Logs: retenção por criticidade, exportar para storage barato, comprimir.

5.3 Block storage: o tipo certo

• gp3 > gp2 (AWS): gp3 é mais barato por GB e permite provisionar IOPS/throughput separadamente do tamanho — não precisa mais "inflar o disco" para ganhar IOPS. Migrar gp2→gp3 é ganho fácil.
• io2/Provisioned IOPS só onde a latência exige; muita gente provisiona IOPS "por segurança" e nunca usa.
• Redimensionar discos superdimensionados (alguns provedores só permitem crescer — planejar).

5.4 Formato e compressão de dados

Onde você controla o formato (data lake, exports, logs): Parquet + compressão (zstd, snappy) reduz o volume armazenado em 5–10× vs CSV/JSON e ainda barateia as consultas (Módulo 8 e apostila de Engenharia de Dados). Comprimir logs e artefatos antes de arquivar.

6.1 O mapa do egress

6.2 Padrões que reduzem transferência

• CDN na frente de tudo que é servido a usuários (CloudFront, Cloud CDN, Cloudflare): egress via CDN é mais barato que direto do storage/compute, e o cache reduz o volume de origem. Assets, imagens, vídeo, respostas de API cacheáveis.
• Colocalize o que conversa muito: serviço e banco na mesma zona; evitar chamadas cross-AZ no caminho quente. Em K8s, topology aware routing mantém o tráfego na zona.
• VPC endpoints / Private Service Connect / Private Link para acessar S3, DynamoDB, APIs do provedor sem passar pela internet nem pelo NAT Gateway — corta a taxa do NAT e o egress.
• Revise o NAT Gateway: tráfego grande de saída (baixar imagens de contêiner, pacotes, backups para outra nuvem) passando pelo NAT paga por GB. Mover para endpoint privado, cache de imagens (pull-through cache do ECR/Artifact Registry), ou gateway próprio.
• Comprima respostas HTTP (gzip/brotli) e payloads entre serviços.
• Data locality: processe o dado onde ele está (não traga 1 TB para a aplicação para filtrar 1 GB — empurre o filtro para o storage/warehouse).
• Evite multi-region desnecessário: replicação entre regiões é egress contínuo; só onde a latência/DR exigem.
• Egress para fora da nuvem (para outro provedor, on-prem): considerar Direct Connect/Interconnect se o volume for alto e constante.

7.1 Otimizar funções (Lambda / Cloud Functions / Azure Functions)

• Tuning de memória: em Lambda, a CPU é proporcional à memória. Mais memória pode reduzir o custo se a função ficar rápida o suficiente (menos GB-segundo). Use uma ferramenta de "power tuning" para achar o ponto ótimo por função — não chute.
• Arquitetura ARM (Graviton) para funções: ~20% mais barato, quase sempre sem mudança de código.
• Reduza o tempo de execução: conexões reaproveitadas fora do handler, dependências enxutas (cold start menor), evitar I/O desnecessário.
• Provisioned concurrency só onde o cold start dói de verdade — ela é "sempre ligada" e custa como tal.
• Cuidado com o padrão de invocação: função chamada em loop por outra função, ou por um trigger muito granular, multiplica invocações. Batching de eventos reduz.

7.2 Serverless × sempre-ligado: o ponto de virada

Serverless brilha em carga intermitente ou imprevisível (escala a zero, paga por uso). Em carga alta e constante, um contêiner/VM reservado costuma custar bem menos por unidade de trabalho. A conta: estime o custo serverless no volume esperado e compare com N contêineres reservados que dariam o mesmo throughput. Muitos sistemas começam serverless (certo) e deveriam migrar a parte de tráfego constante para contêiner quando amadurecem (e vice-versa para picos).

7.3 Serviços gerenciados: quando compensam e quando não

• Bancos gerenciados: rightsizing da instância, storage autoscaling em vez de superprovisionar, matar réplicas de leitura ociosas, usar tier serverless (Aurora Serverless v2, etc.) para cargas intermitentes, reservar a base.
• Filas/streaming gerenciado: revisar retenção, shards/partições provisionados, e se o volume justifica um tier provisionado vs on-demand.
• Observability SaaS: frequentemente uma das maiores "linhas surpresa" — controlar cardinalidade de métricas, amostragem de traces, retenção de logs, e volume ingerido.

8.1 Data warehouse e analytics

• Monitore as consultas mais caras (top 10 por bytes/tempo) e otimize ou eduque quem as roda.
• Alarme de custo por query e por dia — um JOIN cartesiano ou um dashboard que atualiza a cada 10 s pode gerar milhares num fim de semana.
• Storage do warehouse/lake: compactar arquivos pequenos, expirar snapshots de Iceberg/Delta, particionar por data, tiering.
• Pipelines (Spark/ETL): spot para batch, rightsizing do cluster, evitar reprocessamento e shuffle desnecessário (ver apostila de Engenharia de Dados).

8.2 Kubernetes: alocar e enxugar

• Visibilidade primeiro: OpenCost (CNCF) ou Kubecost alocam o custo dos nós por namespace/deployment/label, mostrando requested vs used.
• O grande desperdício é requests inflado: pods pedindo muito mais CPU/memória do que usam ⇒ o scheduler "enche" nós de reservas ociosas e o cluster autoscaler cria nós à toa. Ajustar requests para perto do uso real + margem (VPA em modo recomendação ajuda).
• Bin packing e consolidação: Karpenter / Cluster Autoscaler para empacotar pods em menos nós, escolher o tipo de nó mais barato que cabe, e derrubar nós subutilizados.
• Spot para workloads tolerantes (batch, stateless com PDB, dev) com node pools separados e fallback.
• Scale-to-zero de serviços sem tráfego (KEDA, Knative).
• Limpar namespaces abandonados, PVCs órfãos, LoadBalancers sem uso, jobs completos acumulados.
• Right-size do control plane e de add-ons (ingress controllers, mesh, agentes de observabilidade — os DaemonSets custam × nº de nós).

9.1 O custo de inferência de LLM via API

Você paga por token, com preço diferente para entrada e saída (a saída costuma ser 3–5× mais cara). As alavancas, da mais barata de aplicar à mais estrutural:

9.2 GPU: o recurso mais caro

• Utilização de GPU como KPI: GPU a 20% de uso é dinheiro queimado. Medir (DCGM, nvidia-smi exporter) e agir.
• Compartilhamento: MIG (particionar uma GPU em instâncias isoladas) e time-slicing para cargas que não saturam uma GPU inteira.
• Right-size da GPU: nem toda inferência precisa de H100 — modelos menores rodam bem em GPUs mais baratas (L4, A10) ou até CPU.
• Servidores de inferência (vLLM, TGI, TensorRT-LLM, Triton) com continuous batching e paged attention aumentam muito o throughput por GPU ⇒ menos GPUs para o mesmo QPS.
• Autoscaling e scale-to-zero de endpoints de inferência (KServe, escalonar por fila/QPS); aceitar cold start onde o SLA permite.
• Spot para treino com checkpointing frequente; spot para inferência batch.
• Quantização (INT8, FP8, GPTQ/AWQ) e distilação: modelo menor/mais rápido, custo por token menor, com perda de qualidade que você mede e aceita ou não.

9.3 Treino e fine-tuning

• PEFT / LoRA / QLoRA em vez de full fine-tuning: fração da memória e do tempo, roda em GPU menor.
• Spot + checkpointing: retomar de onde parou reduz o custo de treino em 60–90%.
• Mixed precision (bf16/fp16), gradient accumulation e gradient checkpointing para caber em GPU menor / batch maior.
• Não re-treinar à toa: só quando o eval justifica (ver apostilas de MLOps e LLMOps).
• Dados: curar um dataset menor e melhor costuma bater um dataset gigante — menos GPU-hora.

9.4 Self-host × API: o break-even

API gerenciada: zero infra, paga por token, ótimo para volume baixo/variável e para começar. Self-host (modelo aberto em GPU sua): custo fixo alto (GPUs reservadas + operação), barato por token em volume alto e constante.

Regra de bolso para estimar o break-even:
  custo_mensal_API   ≈ tokens/mês × preço_por_token
  custo_mensal_self  ≈ (nº_GPUs × preço_GPU_hora × 730) + operação

  self-host começa a compensar quando os tokens/mês são altos o bastante
  para manter as GPUs bem utilizadas (continuous batching) o tempo todo.
  Volume baixo ou muito variável → API. Volume alto, constante e previsível → self-host.
  Considere também: latência, privacidade/compliance, e o custo de engenharia.

9.5 Observabilidade e guardrails de custo de IA

• Custo por requisição registrado no gateway de LLM (tokens in/out × preço, por modelo, por feature, por usuário) — sem isso você não sabe onde cortar.
• Unit economics: custo por resposta / por documento / por usuário de IA, e se cabe no preço do produto.
• Orçamento por requisição e por tenant, com corte ao estourar; rate limit e quota por usuário (protege contra denial of wallet — ver apostila de Segurança de Aplicações de IA).
• Alarme de anomalia de custo de IA — um loop de agente ou um prompt que cresceu pode multiplicar a conta rápido.

10.1 Os perfis que contratam

10.2 Roadmap de estudo (8 semanas)

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

10.4 Como demonstrar impacto (portfólio)

1. Estudo de caso com números (âncora): pegar um ambiente (real anonimizado, de laboratório, ou dataset de billing público), aplicar um conjunto de otimizações, e documentar o "antes/depois" com a economia mensurada e a prova de que o desempenho não regrediu.
2. Automação publicada: um script/pipeline que faz parking de ambientes, ou detecta recursos órfãos, ou gera recomendações de rightsizing a partir de métricas — com o cálculo de economia.
3. Análise de commitments: um notebook que, a partir do histórico de uso, recomenda a compra escalonada de Savings Plans com cobertura/utilização projetadas.
4. Benchmark de custo/desempenho: a mesma carga em x86 vs ARM, ou em serverless vs contêiner, ou um modelo de LLM antes/depois de quantização — com tabela de custo, latência e qualidade.
5. Instrumentação de custo de IA: um gateway simples que registra custo por requisição por modelo/feature e um dashboard de unit economics.