FinOps e Custo de Cloud — rightsizing, Reserved Instances e showback

Em 2019, a empresa de streaming DAZN reduziu sua fatura AWS em 50% em seis meses sem reduzir capacidade ou desacelerar crescimento. O processo foi simples em retrospecto: eles taggaram todos os recursos por serviço e time, tornaram o custo visível para cada squad responsável, e identificaram que 40% do gasto estava em instâncias EC2 com utilização média abaixo de 10%. A maior parte do desperdício estava invisível porque ninguém era responsável pela fatura — ela era paga por um centro de custo centralizado de TI sem visibilidade granular. Tornar o custo visível foi mais impactante que qualquer otimização técnica.

FinOps (Financial Operations) é a prática de gestão financeira de cloud que busca equilibrar velocidade de inovação, custo de infraestrutura, e qualidade. O princípio central da FinOps Foundation é que "todos são responsáveis pelo custo de cloud" — não só o time de infraestrutura ou de finanças.

O triângulo FinOps

Cloud permite escalar velocidade e qualidade praticamente sem limitação — mas o custo cresce proporcionalmente. A disciplina FinOps existe para equilibrar os três vértices do triângulo: velocidade de entrega (não throttle a engenharia), custo adequado ao retorno (não pague por recursos ociosos), e qualidade/performance (não degrade a experiência para economizar).

O erro clássico é tratar FinOps como "redução de custo" — cortar infraestrutura para economizar. A abordagem correta é "otimização de valor": garantir que cada dólar de cloud gera valor proporcional. Uma instância cara que serve 10.000 requests/segundo de um serviço crítico é um bom investimento. Uma instância barata rodando 24/7 sem tráfego é desperdício — independente do custo absoluto.

Tagging — a fundação de tudo

Sem tags, a fatura de cloud é uma lista de serviços sem contexto. Com tags corretas, você sabe exatamente quem gasta o quê. Tags mínimas obrigatórias:

# Política de tags obrigatórias — AWS Tag Policy
{
  "tags": {
    "Service": {
      "tag_value": {
        "@@assign": ["api-gateway", "processador-pagamentos", "relatorio", "..."]
      }
    },
    "Environment": {
      "tag_value": {
        "@@assign": ["dev", "staging", "producao"]
      }
    },
    "Team": {
      "tag_value": {
        "@@assign": ["backend", "data", "platform", "..."]
      }
    },
    "Owner": {
      "tag_value": {
        "@@assign": ["*"]   # qualquer email do time
      }
    }
  }
}

AWS Tag Policies (via AWS Organizations) podem bloquear a criação de recursos sem as tags obrigatórias. No Terraform, tags podem ser definidas como variáveis padrão e aplicadas via default_tags no provider — qualquer recurso criado herda as tags automaticamente:

provider "aws" {
  region = "us-east-1"
  default_tags {
    tags = {
      ManagedBy   = "terraform"
      Environment = var.environment
      Team        = "platform"
    }
  }
}

Recursos não taggeáveis (como requests de dados) podem ser atribuídos via Cost Allocation Tags depois — mas recursos taggeados desde a criação são muito mais fáceis de analisar retroativamente.

Showback vs chargeback

Showback é mostrar para cada time quanto gasta, sem cobrar. É o passo inicial — cria visibilidade e consciência de custo sem gerar conflito financeiro. A maioria das organizações começa aqui: um dashboard no Grafana ou no AWS Cost Explorer por tag de serviço e time.

Chargeback é cobrar os custos do departamento de TI para os times de negócio que os geram. Requer sistema de billing interno mais sofisticado e alinhamento financeiro entre TI e produto. Mais eficaz para criar incentivo real de otimização — quando a fatura do squad de pagamentos sobe, o squad sente no orçamento. Mais complexo de implementar e pode criar comportamentos disfuncionais (squads evitando usar cloud para não ser cobrados).

A maioria das organizações começa com showback e migra para chargeback parcial (accountability sem billing real) em 12-18 meses de maturidade FinOps.

Rightsizing — identificando superprovisionamento

Rightsizing é o processo de ajustar o tamanho das instâncias ao uso real. O superprovisionamento é quase universal em cloud: times provisionam para o pico teórico, não para o uso médio. Uma instância m5.2xlarge com utilização de CPU de 5% está desperdiçando 95% da capacidade.

O processo de rightsizing:

1. Coletar métricas: CPU, memória, e network utilization por instância nos últimos 14-30 dias. AWS Cost Optimization Hub e GCP Recommender fazem isso automaticamente.
2. Identificar candidatos: instâncias com percentil 95 de CPU abaixo de 30% são candidatos a downsize. Memória requer cuidado — workloads com caches grandes usam memória intencionalmente.
3. Dimensionar corretamente: target de 60-70% de utilização no percentil 95 — deixa headroom para variações de carga sem superprovisionamento.
4. Validar e monitorar: após mudança, monitorar por 1-2 semanas antes de considerar estável.

Em Kubernetes, o VPA (Vertical Pod Autoscaler) em modo Off faz rightsizing contínuo automaticamente — analisa consumo histórico e recomenda requests ideais. Ver Conceito 03.

Reserved Instances e Savings Plans

On-demand pricing é o mais caro e o mais flexível. Para cargas estáveis e previsíveis, commitments de longo prazo oferecem descontos significativos:

Savings Plans Compute são mais flexíveis que Reserved Instances: o commitment é em $/hora de uso de compute, independente de família de instância, região, ou OS. Se você muda de m5.xlarge para c5.2xlarge (porque descobriu que a carga é CPU-bound), o Savings Plan continua aplicando. Reserved Instances standard são para cargas onde você sabe exatamente qual tipo de instância vai usar pelos próximos 3 anos — raramente a situação real.

Estratégia de commitment

O erro clássico é reservar com base no pico — você compra capacity que fica ociosa na maioria do tempo. A estratégia correta:

1. Identificar o baseline de compute nos últimos 90 dias: quantas instâncias você sempre tem rodando, independente de horário ou pico
2. Cobrir 60-70% do baseline com Savings Plans de 1 ano (não 3 anos — muita coisa muda em 3 anos)
3. Restante do baseline e tráfego variável fica on-demand
4. Picos extremos e workloads fault-tolerant ficam em spot
5. Revisar o commitment trimestralmente

Spot Instances — custo mínimo para workloads tolerantes

Spot instances são capacidade ociosa que a AWS vende com desconto de 70-90%. O trade-off: a AWS pode interromper a instância com 2 minutos de aviso quando precisa da capacidade de volta. Workloads adequados para spot:

• Processamento de jobs em batch (CI/CD runners, machine learning training, ETL)
• Testes automatizados (os runners de teste podem ser interrompidos e reiniciados)
• Nós de worker em clusters Kubernetes com drain grace period configurado
• Workloads stateless que podem recomeçar do checkpoint

Workloads inadequados para spot: bancos de dados (interrupção pode corromper dados), servidores de API síncronos (interrupção cria latência e erros para usuários), e qualquer workload sem capacidade de retomar do estado.

No Kubernetes, spot nodes ficam em um node pool separado com taints, e apenas os workloads adequados têm tolerations para spot. O Karpenter gerencia a escolha entre on-demand e spot automaticamente:

# Karpenter NodePool com mix de on-demand e spot
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]   # Karpenter prefere spot quando disponível
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s

Ferramentas de visibilidade de custo

AWS Cost Explorer: análise de custo por serviço, conta, região, e tag. Recomendações automáticas de Reserved Instances e Savings Plans. Gratuito mas limitado em granularidade.

AWS Cost Anomaly Detection: ML que detecta aumentos de custo anômalos e envia alertas. Útil para detectar vazamentos de custo (loop de autoscaling, teste de carga esquecido rodando em produção).

Kubecost / OpenCost: custo de cloud por namespace Kubernetes, pod, e deployment. Essencial para times com múltiplos serviços em Kubernetes que precisam de showback por squad. OpenCost é a versão open source e padrão CNCF.

Infracost: integração no PR de Terraform que mostra o delta de custo de uma mudança de infraestrutura antes de aplicar. Um PR que cria uma instância p3.8xlarge por engano aparece como "+$4.000/mês" no PR comment — impossível de passar despercebido.

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos