FinOps na AWS: guia completo para reduzir a conta sem perder performance

A conta da nuvem cresce por um motivo simples: é fácil ligar e ninguém é dono de desligar. Em contas de produção de empresas de médio e grande porte, a economia relevante raramente está em negociar desconto. Está em configuração, arquitetura e governança: mídia servida sem CDN, banco dimensionado para um pico que passou, ambientes de teste ligados em fim de semana, snapshots eternos, dados que ninguém lê armazenados na classe mais cara. Este guia mostra como um trabalho de FinOps na AWS funciona na prática, do diagnóstico à rotina, e o que esperar em cada etapa.

O que é FinOps, sem o jargão

FinOps é a disciplina de tratar o custo de nuvem como um custo de negócio: com dono, com meta, com número por área e com decisão informada sobre o que vale pagar. Não é cortar por cortar; é pagar pela nuvem que a empresa usa, na arquitetura que o negócio precisa. Envolve engenharia (quem configura), finanças (quem paga) e quem decide (quem prioriza), olhando o mesmo relatório.

Na AWS, isso se traduz em três camadas de trabalho. A primeira é visibilidade: saber o que custa o quê, por serviço, por ambiente e por área do negócio. A segunda é otimização: eliminar desperdício e ajustar o que está superdimensionado. A terceira é governança: garantir que a conta não volte a crescer sem ninguém perceber. A maioria das empresas que procura ajuda está presa na primeira camada.

O tamanho do desperdício, segundo quem mede

O problema é global e está medido. O relatório State of the Cloud 2025 da Flexera, com mais de 750 respondentes, mostra que 84% das organizações têm dificuldade para gerir o gasto em nuvem, que 27% desse gasto é desperdício (o pico foi 32% quatro anos antes) e que os orçamentos de nuvem são estourados em 17%, em média. A Gartner projeta US$ 723,4 bilhões de gasto global com nuvem pública em 2025, alta de 21,5% sobre 2024. Aplicar 27% de desperdício a uma conta que cresce mais de 20% ao ano dá a dimensão do que está em jogo.

O State of FinOps 2025, da FinOps Foundation, confirma a prioridade dos praticantes: otimização de workload e redução de desperdício aparece em primeiro lugar por larga margem, seguida de alocação completa do gasto e previsão acurada. O mesmo relatório mostra o escopo se ampliando: 63% das equipes de FinOps já gerem gasto com IA, o dobro do ano anterior, e a maioria passou a acompanhar SaaS e licenças. A conta de nuvem deixou de ser assunto de infraestrutura.

O framework da FinOps Foundation organiza o trabalho em três fases que se repetem: Inform (visibilidade, alocação, benchmark e previsão), Optimize (eliminar ocioso, redimensionar, usar descontos por compromisso) e Operate (governança, indicadores, automação e cultura de responsabilidade compartilhada). O diagnóstico descrito a seguir é a fase Inform feita com rigor; as ordens de ataque são a fase Optimize; a rotina no fim do artigo é a fase Operate.

Como funciona um diagnóstico de custo

Um diagnóstico sério começa somente leitura. Ninguém altera nada no ambiente até entender o que existe, por que existe e quem depende dele. Com acesso de leitura ao billing, ao Cost Explorer, ao CloudWatch e à configuração dos serviços, em dez dias úteis é possível montar um inventário completo: cada recurso, seu custo mensal, sua utilização real e seu dono provável.

O resultado é um relatório com baseline (quanto custa hoje, por onde), oportunidades priorizadas por economia anualizada e risco, e o que cada ação exige: se pode ser feita sem janela, se precisa de mudança de arquitetura, se envolve compromisso financeiro. A empresa decide o que executar. Diagnóstico com preço fechado e sem alteração no ambiente é o ponto de entrada de menor risco que existe em tecnologia.

Onde a conta costuma vazar

As alavancas se repetem em quase todo diagnóstico. Não porque as empresas errem, mas porque a nuvem cresce por acúmulo de decisões individualmente razoáveis.

• Tráfego de saída sem CDN: mídia, downloads e APIs servidos direto de S3 ou de instâncias, pagando egress cheio quando uma regra de cache no CloudFront resolveria
• Banco superdimensionado ou no modelo errado: serverless em carga constante custa mais que instância reservada; instância grande para um pico de campanha que já passou
• Ambientes de desenvolvimento e homologação ligados 24 horas, sete dias por semana, com o mesmo porte de produção
• Recursos órfãos: volumes EBS sem instância, IPs elásticos sem uso, load balancers sem destino, snapshots e AMIs antigas sem política de retenção
• Armazenamento na classe errada: logs e backups em S3 Standard quando deveriam envelhecer para classes frias ou expirar
• Compute sem reserva: cargas previsíveis rodando sob demanda há meses, quando Savings Plans ou instâncias reservadas devolvem parte relevante do valor
• Arquitetura x86 onde ARM (Graviton) entrega o mesmo trabalho por menos
• Logs e métricas em excesso: CloudWatch retendo tudo, para sempre, em ambientes que ninguém consulta

Em uma plataforma de conteúdo com milhões de usuários, o diagnóstico encontrou mídia servida sem CDN e um banco serverless em carga constante. Regra de cache, migração para instância reservada e plano de reservas reduziram a conta mensal em 30%, com 30 segundos de indisponibilidade na migração do banco e nenhuma mudança percebida pelo usuário.

Em que ordem atacar

A ordem importa mais do que a lista, porque define risco e velocidade de retorno. Primeiro, o que economiza sem risco e sem compromisso: desligar o que está órfão, aplicar política de retenção em snapshots e logs, colocar cache na frente do que é servido sem cache, agendar desligamento dos ambientes que não são produção. Isso costuma sair na primeira semana de execução e paga o diagnóstico.

Segundo, o que exige janela mas não compromisso: redimensionar bancos e instâncias, mudar classe de armazenamento, migrar cargas para ARM. Cada ação com critério de rollback, canário antes do lote e validação com quem opera.

Terceiro, o que exige compromisso financeiro: Savings Plans e instâncias reservadas. Só depois de estabilizar o consumo, senão a empresa compra reserva para um porte que vai encolher. Com o baseline limpo, a reserva devolve o máximo e o payback de cada compromisso é calculado antes de assinar.

Por último, o que exige mudança de arquitetura: serverless onde o tráfego é irregular, filas onde há picos, caches distribuídos, decomposição de monólitos caros. São projetos, não ajustes, e entram no plano com custo e prazo próprios.

Migrar para a nuvem também é FinOps

Para quem ainda roda em data center próprio, a conta começa antes: a decisão de migrar. Uma migração bem desenhada troca custo fixo de hardware, licenças, energia e pessoas dedicadas por custo variável com dono. Em uma empresa com mais de 60 anos de operação, a saída do data center on-premises para a nuvem levou menos de seis meses, com a operação em andamento, e reduziu os custos de infraestrutura em 40%. O caso foi reconhecido globalmente pela AWS.

O que fez diferença não foi a ferramenta de migração, e sim a ordem: inventário completo, canário com um serviço de baixo risco, ondas com validação, cutover planejado e a infraestrutura redesenhada para a nuvem em vez de copiada do data center. Copiar servidores para a nuvem como estão é o jeito mais rápido de pagar mais do que antes.

Como manter a conta sob controle

Otimizar uma vez e voltar ao normal é o padrão de quem não muda a governança. O que segura o resultado:

• Um dono por conta e por ambiente, com meta mensal e alerta de desvio
• Tags obrigatórias por área, produto e ambiente, para que o relatório de custo fale a língua do negócio
• Orçamento por área com alerta automático antes de estourar, não depois da fatura
• Política de ciclo de vida para armazenamento, snapshots e logs, aplicada por código
• Revisão mensal de 30 minutos entre engenharia e finanças sobre o mesmo relatório
• Toda nova carga entra com estimativa de custo antes de ir para produção

Isso é o que transforma um projeto de redução em um custo que se comporta. E é o que permite ao CFO responder, com fatura na mão, o que a tecnologia custa, o que devolve e onde cortar sem risco.

Azure e Google Cloud: o mesmo raciocínio, nomes diferentes

Tudo o que vale para a AWS vale para Azure e Google Cloud, com outros nomes. Egress sem CDN é egress em qualquer nuvem. Banco superdimensionado se chama SQL Database ou Cloud SQL, mas custa do mesmo jeito. Reservas se chamam Reserved Instances, Savings Plans ou Committed Use Discounts, e a regra é a mesma: só depois de estabilizar o consumo. Ambientes de não produção ligados o tempo todo aparecem em qualquer fatura. O diagnóstico segue o mesmo método, somente leitura, com inventário, baseline e oportunidades priorizadas por economia e risco, e a governança que segura o resultado é idêntica: dono, tag, orçamento com alerta, ciclo de vida e revisão mensal entre engenharia e finanças.

Empresas com mais de uma nuvem costumam ter o problema em dobro: ninguém enxerga o total, cada time defende a sua fatura e as reservas são compradas sem olhar o conjunto. O primeiro passo é um relatório único, na linguagem do negócio, antes de qualquer otimização.

Perguntas que o CFO deve fazer

• Quanto a tecnologia custa por real de receita, mês a mês, e quem é o dono desse número?
• Quais recursos foram criados nos últimos 90 dias e quem aprovou cada um?
• Quanto dos gastos está em compromisso (reservas) e quanto sob demanda, e por quê?
• Que parte da conta é ambiente de não produção, e ele precisa ficar ligado fora do horário?
• Se a receita cair pela metade, que parte da conta cai junto?
• Qual foi a última vez que alguém apagou algo?

Se essas perguntas não têm resposta com fatura na mão, o problema não é de tecnologia. É de governança, e o diagnóstico somente leitura é a forma mais barata de começar a respondê-las.

O que esperar de quem contratar

Desconfie de percentual prometido antes de olhar a conta. Exija diagnóstico somente leitura com preço fechado, economia anualizada por ação com o risco de cada uma, e a decisão na sua mão sobre o que executar. Pergunte quem executa: se for o mesmo time que diagnosticou, a responsabilidade pelo resultado não se perde na passagem de bastão. E peça que todo número venha com origem: fatura, Cost Explorer, relatório. Se o resultado não puder ser conferido na próxima fatura, não é resultado.