DevOps & Infra

FinOps para Desenvolvedores: Guia Prático de Otimização de Custos em AWS, Azure e GCP

Entenda o que é FinOps e aprenda a tratar custos de nuvem como métrica de arquitetura. Guia prático com estratégias para AWS, Azure, GCP e automação de infraestrutura.

Marcos Costa
Marcos Costa
09 de setembro de 2026 7 min de leitura
Notebook sobre uma mesa de trabalho exibindo um dashboard de controle de custos de nuvem com gráficos em queda e uma janela de código de programação, representando práticas de FinOps.

Quando projetamos um software, é comum focarmos em latência, throughput, tolerância a falhas e segurança. No entanto, em ambientes de nuvem pública, cada decisão de design de arquitetura carrega um custo financeiro direto. Escolher uma instância m5.large em vez de uma t3.medium, ou optar por um banco de dados relacional totalmente gerenciado em vez de uma solução serverless, são decisões técnicas que impactam diretamente a saúde financeira do projeto.

Por isso, o custo de nuvem deve ser tratado como um requisito não funcional de software — uma métrica de arquitetura de primeira classe. É aqui que entra o FinOps (Financial Operations).

O que é FinOps e por que o desenvolvedor é a chave dessa cultura?

O FinOps é um framework operacional e uma mudança cultural que une finanças, tecnologia e negócios para impulsionar a responsabilidade financeira e otimizar os custos na nuvem. Segundo a FinOps Foundation, o objetivo não é simplesmente economizar dinheiro, mas sim maximizar o valor de negócio gerado por cada centavo investido em nuvem.

Tradicionalmente, a equipe de finanças recebia a fatura da nuvem no fim do mês e tentava entender os gastos sem o contexto técnico. Esse modelo reativo falha porque quem realmente consome e provisiona recursos são os desenvolvedores e engenheiros de software. Cada commit, pipeline de CI/CD ou alteração em arquivos de Terraform altera a infraestrutura. Portanto, o desenvolvedor é a peça mais importante do FinOps: a otimização real acontece na fase de design e provisionamento, não na auditoria financeira.

Os 6 princípios fundamentais e as 3 fases do ciclo FinOps

A cultura FinOps é sustentada por seis princípios fundamentais definidos pela FinOps Foundation:

  1. Equipes precisam colaborar: Engenharia, finanças e negócios trabalham juntos em tempo real.
  2. Decisões orientadas pelo valor de negócio: O custo é avaliado em relação ao retorno (ex: custo por transação ativa).
  3. Responsabilidade individual: Cada time é responsável pelo custo dos recursos que consome.
  4. Relatórios acessíveis e oportunos: Feedback rápido sobre gastos para corrigir desvios imediatamente.
  5. Decisões centralizadas: Uma equipe centralizada (CCoE - Cloud Center of Excellence) gerencia taxas, descontos em massa e compromissos de longo prazo.
  6. Aproveitar o modelo de custo variável da nuvem: Ajustar a capacidade sob demanda em vez de superprovisionar.

O ciclo de vida do FinOps opera em três fases contínuas:

  • Informar (Visibility): Dar visibilidade aos gastos. Sem saber onde o dinheiro está sendo gasto (atribuição de custos por tags/labels), é impossível otimizar.
  • Otimizar (Optimization): Identificar desperdícios e aplicar melhorias de design (rightsizing, desligamento de ociosos, compra de planos de desconto).
  • Operar (Operations): Integrar a governança de custos no dia a dia, definindo políticas contínuas e automações para manter a eficiência.

Estratégias práticas de otimização na AWS

A AWS oferece um ecossistema robusto, mas o desperdício é comum se não houver atenção técnica.

  • Rightsizing: Analise o uso de CPU e memória com o AWS Compute Optimizer. Se uma instância EC2 opera constantemente abaixo de 10% de utilização, reduza sua família ou tamanho.
  • Savings Plans e Reserved Instances: Para workloads previsíveis (como bancos de dados de produção), comprometa-se com um uso mínimo por 1 ou 3 anos para obter descontos significativos.
  • Otimização de AWS Lambda: Ajuste a alocação de memória do Lambda. Mais memória aumenta o poder de CPU proporcionalmente, o que pode reduzir o tempo de execução e, consequentemente, o custo total (use ferramentas como o AWS Lambda Power Tuning).
  • AWS Trusted Advisor: Utilize a ferramenta para identificar volumes EBS órfãos, IPs elásticos não associados e instâncias ociosas.

Comparativo Técnico: Instâncias Spot vs. Sob Demanda

CaracterísticaInstâncias Sob Demanda (On-Demand)Instâncias Spot
PreçoTabela cheia (base de custo padrão)Até 90% de desconto sobre o valor sob demanda
DisponibilidadeGarantida pelo provedorBaseada na capacidade ociosa (pode ser interrompida)
Aviso de DesligamentoNenhum (você decide quando desligar)Aviso prévio de 2 minutos antes da interrupção
Casos de Uso IdeaisBancos de dados, APIs críticas, workloads statefulCI/CD, processamento em lote (batch), workers de filas

Estratégias práticas de otimização no Microsoft Azure

No Azure, a governança de custos exige o uso inteligente de ferramentas nativas e isolamento de ambientes.

  • Otimização de VMs e Autoescalonamento: Configure regras de Virtual Machine Scale Sets (VMSS) baseadas em métricas reais de aplicação (como tamanho da fila de mensagens ou requisições HTTP), evitando manter instâncias ligadas sem necessidade.
  • Azure Advisor: Acesse a aba de “Custos” para obter recomendações automáticas de desligamento de máquinas virtuais subutilizadas e redimensionamento de bancos de dados SQL do Azure.
  • Azure DevTest Labs: Crie ambientes de desenvolvimento e homologação isolados com limites rígidos. O DevTest Labs permite definir cotas de recursos por usuário, proibir tamanhos de VMs caros e configurar horários automáticos de inicialização e desligamento de laboratórios inteiros.

Estratégias práticas de otimização no Google Cloud Platform (GCP)

O GCP possui uma abordagem muito focada em automação e recomendações inteligentes baseadas em IA.

  • FinOps Hub: Painel centralizado que consolida recomendações de custos e calcula o índice de eficiência de nuvem do seu projeto.
  • Google Cloud Recommender API: Permite extrair recomendações de rightsizing e remoção de discos ociosos programaticamente via CLI ou integrá-las ao seu pipeline de infraestrutura.
  • Committed Use Discounts (CUDs): Descontos por compromisso de uso de recursos (vCPUs e memória) por prazos de 1 ou 3 anos, aplicados automaticamente aos recursos qualificados.

Exemplo prático de tagueamento estruturado (Labels no GCP)

A alocação de custos depende de um esquema rígido de tags/labels. Veja um exemplo de configuração de labels em um recurso do GCP via Terraform:

resource "google_compute_instance" "app_server" {
  name         = "prod-app-server-01"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  labels = {
    environment = "production"
    project     = "e-commerce"
    owner       = "checkout-team"
    cost-center = "cc-102"
  }

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
  }
}

Com essas labels estruturadas, o time financeiro consegue filtrar os relatórios de faturamento e identificar exatamente quanto o “checkout-team” gastou no projeto “e-commerce”.

Automação e governança de custos: políticas como código na prática

A otimização manual não escala. Para garantir a eficiência contínua, os times de engenharia devem adotar a automatização na infraestrutura e definir políticas de custos diretamente no fluxo de desenvolvimento.

Ao utilizar Infraestrutura como Código (IaC) com ferramentas como o Terraform, é possível integrar validadores de custos (como o Infracost) no pipeline de CI/CD. O Infracost analisa o plano do Terraform e comenta no Pull Request o impacto financeiro estimado daquela alteração antes mesmo de aplicar o deploy.

Cenário de Automação: Desligamento de Ambientes Ociosos

Ambientes de desenvolvimento e homologação raramente precisam rodar 24 horas por dia, 7 dias por semana. Desligar esses recursos fora do horário comercial (noites e finais de semana) pode reduzir drasticamente o custo de computação desses ambientes.

Ferramentas open-source como o CloudCustodian permitem definir políticas declarativas em YAML para gerenciar recursos em múltiplos provedores. Veja um exemplo de política do CloudCustodian para desligar instâncias EC2 de desenvolvimento às 19h em dias úteis:

policies:
  - name: desligar-dev-fora-horario
    resource: ec2
    filters: 
      - "tag:environment": "development"
      - type: offhour
        default_timezone: "America/Sao_Paulo"
        offhour: 19
    actions:
      - stop

Para garantir que essas automações não causem indisponibilidade indesejada ou falhas silenciosas, manter um sistema robusto de monitoramento e observabilidade é fundamental. Métricas de performance devem ser analisadas em conjunto com os dados de custo para garantir que a redução de recursos não degrade a experiência do usuário final.

Perguntas Frequentes (FAQ)

  • Qual é a diferença prática entre instâncias Spot e instâncias sob demanda? As instâncias sob demanda possuem preço fixo e disponibilidade garantida, enquanto as instâncias Spot aproveitam a capacidade ociosa do provedor com descontos significativos, mas podem ser interrompidas com um aviso prévio curto. Devem ser usadas apenas em workloads tolerantes a falhas.

  • Como começar a aplicar FinOps em times pequenos sem sobrecarregar os desenvolvedores? Comece estabelecendo uma política simples de tagueamento de recursos e automatize o desligamento de ambientes de teste fora do horário comercial. Tratar o custo como métrica de arquitetura desde o início evita refatorações caras no futuro.

  • O que é o FOCUS Framework e como ele ajuda no FinOps multi-cloud? O FOCUS (FinOps Open Cost & Usage Specification) é um projeto que visa padronizar os dados de custo e uso de diferentes provedores de nuvem, facilitando a visualização e a tomada de decisão em arquiteturas multi-cloud.

Referências

Marcos Costa

Sobre Marcos Costa

Desenvolvedor backend com foco em arquitetura de software, automação e produtos digitais.

Ver mais artigos