TL;DR A FinOps Foundation define seis princípios que orientam como as organizações gerenciam gastos com nuvem e tecnologia. Quase toda equipe sabe recitá-los. Bem poucas conseguem traduzi-los nas decisões, estruturas e fluxos do dia a dia que fazem a gestão financeira da nuvem realmente funcionar.
Os seis princípios são: colaboração, valor de negócio, ownership, dados acessíveis, enablement centralizado e aproveitamento do modelo de custo variável. A FinOps Foundation atualizou quatro dos seis princípios em 2025, na primeira revisão desde 2019, para refletir um escopo mais amplo de "Cloud+", que vai além da nuvem pública. As três fases do FinOps (Inform, Optimize, Operate) traduzem os princípios em execução. Operacionalizar os princípios exige uma base de dados sólida, uma função central de enablement, showback antes de chargeback e loops contínuos de otimização. A DoiT ajuda as equipes a fechar a distância entre princípio e prática por meio de análises unificadas de custo, workflows automatizados e cloud architects certificados em FinOps.
A maioria das equipes que adota FinOps dedica tempo real ao estudo dos seis princípios. Alinha as definições, conquista o apoio da liderança e monta uma apresentação. Depois volta a revisar as faturas da nuvem no fim do mês.
É aqui que aparece a distância entre o FinOps como conceito e o FinOps como prática funcional. Os princípios descrevem o modelo operacional correto para a gestão financeira da nuvem. Não descrevem como construí-lo. Esse trabalho de tradução — do princípio ao processo, da intenção ao hábito organizacional — é onde a maioria dos programas empaca.
Este guia mostra o que cada princípio significa na prática, como as três fases do FinOps se conectam a eles e as ações específicas de implementação que transformam princípios em resultados que sua equipe realmente consegue medir. Para se aprofundar em como esses princípios se conectam a uma estratégia mais ampla de implementação, veja o guia da DoiT sobre implementação de FinOps.
O que são os princípios do FinOps e de onde eles vêm?
Os princípios do FinOps são os valores fundamentais publicados pela FinOps Foundation, a organização sem fins lucrativos e neutra em relação a fornecedores que mantém o FinOps Framework. Eles funcionam como a estrela-guia de qualquer prática de FinOps, orientando os comportamentos culturais e as decisões organizacionais que determinam se a gestão financeira da nuvem vai entregar valor duradouro ou ficar só no discurso.
Os seis princípios foram elaborados originalmente em 2019. Em março de 2025, a FinOps Foundation os atualizou pela primeira vez como parte de uma revisão mais ampla do Framework, refletindo como o FinOps se expandiu para além da nuvem pública, no que a Foundation agora chama de abordagem "Cloud+". Quatro dos seis princípios foram reformulados para reconhecer que os praticantes de FinOps hoje também gerenciam SaaS, data centers, custos de licenciamento e nuvem privada, além dos gastos tradicionais com infraestrutura. O significado central de cada princípio permaneceu intacto; a linguagem apenas se atualizou para acompanhar a realidade da prática atual.
Este artigo usa a redação atual, de 2025, em todos os trechos.
Os 6 princípios do FinOps em detalhes
Cada princípio carrega uma expectativa operacional específica. Entender o que o time de FinOps precisa construir para honrá-lo é o que separa as equipes que aplicam o framework daquelas que só acenam para ele.
1. As equipes precisam colaborar
Custo de nuvem é um problema multifuncional. O financeiro define orçamentos, mas não consegue interpretar padrões de uso. A engenharia entende os workloads, mas tem visibilidade limitada do impacto financeiro. O produto é dono das decisões de roadmap que puxam o gasto. Quando esses grupos operam em silos, as faturas de nuvem crescem e ninguém assume o resultado.
Colaboração como princípio significa construir as condições estruturais para a tomada de decisão compartilhada: revisões multifuncionais regulares, um vocabulário comum para custo de nuvem e KPIs compartilhados que dão ao financeiro e à engenharia uma base comum para trade-offs. O papel do time de FinOps é facilitar essa conversa, não conduzi-la em nome de todos. Equipes que tratam colaboração como aspiração, e não como fluxo desenhado, consistentemente entregam menos do que o FinOps promete. Veja como as melhores práticas de FinOps sustentam a colaboração multifuncional em escala.
2. O valor de negócio orienta as decisões de tecnologia
Antes de 2025, esse princípio dizia: "As decisões são orientadas pelo valor de negócio da nuvem". A atualização ampliou o escopo. A mudança de "valor da nuvem" para "orienta as decisões de tecnologia" sinaliza que o FinOps agora aplica a mesma lente de valor a assinaturas SaaS, workloads de IA e infraestrutura de dados, e não só a compute em nuvem.
Em termos operacionais, esse princípio significa que toda decisão relevante de infraestrutura se conecta a um resultado de negócio. Não "esta família de instância é mais barata", mas "esta arquitetura reduz o custo por transação mantendo o SLA". Isso exige que as equipes construam a capacidade de medição que torna essas conexões explícitas: unit economics, custo por cliente, custo por funcionalidade, custo por ambiente. Sem essa infraestrutura, o princípio fica só no discurso.
3. Todos assumem ownership do seu uso de tecnologia
A atualização de 2025 substituiu "uso de nuvem" por "uso de tecnologia", estendendo o modelo de ownership a toda a gama de gastos com tecnologia que os times de FinOps agora gerenciam. A expectativa por trás continua a mesma: engenheiros, product managers e times de aplicação precisam entender as implicações de custo de suas decisões e se sentir responsáveis por elas.
Para isso, duas coisas são necessárias. Primeiro, visibilidade de custo no nível do time: engenheiros não têm como assumir ownership do que não conseguem enxergar. Relatórios de showback, alocação de custos por time ou produto e dashboards de gasto em tempo real dão às pessoas as informações necessárias para agir. Segundo, permissão cultural: as equipes não vão otimizar gastos se acreditarem que responsabilidade sobre custo conflita com velocidade de entrega. O programa de FinOps precisa deixar claro que ownership significa tomada de decisão informada, não policiamento de custos. Para mais sobre estratégia de alocação de custos, veja o detalhamento da DoiT sobre alocação de custos por ambiente.
4. Os dados de FinOps devem ser acessíveis, oportunos e precisos
A revisão de 2025 acrescentou "precisos" a esse princípio, que antes dizia apenas "acessíveis e oportunos". A adição reflete uma dor real de quem pratica: equipes que recebem dados de custo no prazo, mas cheios de erros de alocação ou de tags ausentes, não conseguem agir de forma eficaz. Precisão não é consequência automática de acessibilidade.
Operacionalmente, esse princípio define os requisitos da base de dados de FinOps: os dados de custo precisam chegar rapidamente aos times que precisam deles (diariamente ou em quase tempo real, não mensalmente), precisam estar corretamente atribuídos aos times e produtos certos e precisam ser completos o suficiente para sustentar decisões. Dados atrasados geram respostas reativas. Dados imprecisos corroem por completo a confiança no programa de FinOps. Dados ausentes criam pontos cegos que se acumulam ao longo do tempo.
5. O FinOps deve ser habilitado centralmente
Essa é uma das reformulações mais significativas de 2025. O princípio original dizia "Uma equipe centralizada conduz o FinOps". A atualização mudou para "O FinOps deve ser habilitado centralmente", o que, segundo a FinOps Foundation, captura melhor a abordagem bottom-up que um FinOps eficaz emprega.
A distinção importa. Uma equipe centralizada que conduz o FinOps pode virar gargalo, mais um grupo fazendo trabalho de custo em nome de todos os outros. Enablement centralizado significa que a função de FinOps cria as ferramentas, processos, frameworks e expertise que os times distribuídos usam para gerenciar custo por conta própria. Ela constrói capacidade em toda a organização, em vez de centralizar o trabalho. O time central cuida de negociações de tarifas, gestão de commitments, ferramentas e governança. Os times de engenharia cuidam do right-sizing e do ciclo de vida dos recursos dentro dos seus próprios workloads.
6. Aproveite o modelo de custo variável da nuvem
Custos de infraestrutura em nuvem variam com o uso. Diferente do investimento fixo em infraestrutura on-premises, o gasto em nuvem responde a decisões tomadas no nível do workload. É uma vantagem operacional enorme que muitas organizações não conseguem explorar por completo.
Aproveitar o modelo variável significa construir as práticas de engenharia e financeiras que usam a variabilidade de forma estratégica: auto-scaling para casar capacidade e demanda, uso de commitments (Reserved Instances, Savings Plans, committed use discounts) para reduzir a tarifa em workloads previsíveis, right-sizing para eliminar capacidade ociosa e migração de workloads para configurações de menor custo quando os requisitos de negócio permitirem. Equipes que tratam a nuvem como infraestrutura fixa perdem a alavanca fundamental de custo que faz o FinOps valer a pena. Para abordagens específicas por plataforma, veja as melhores práticas de FinOps para Google Cloud da DoiT.
As três fases do FinOps (Inform, Optimize, Operate) e como se conectam aos princípios
A FinOps Foundation organiza a execução em três fases: Inform, Optimize e Operate. Essas fases descrevem o que o time de FinOps faz, enquanto os princípios descrevem por que e como devem fazer. As fases traduzem os princípios em trabalho concreto.
1. Inform: visibilidade, atribuição e orçamento
A fase Inform aborda diretamente o princípio de acessibilidade e precisão dos dados. Antes de qualquer otimização, os times precisam enxergar seus gastos: o que existe, quem é dono, quanto custa e como evolui. O trabalho de Inform inclui estabelecer alocação de custos via tagging, construir relatórios de showback que exponham o gasto por time, criar orçamentos e previsões e configurar detecção de anomalias para capturar mudanças inesperadas de custo antes que se acumulem.
A maioria das organizações investe pouco aqui. Assume que visibilidade é um problema resolvido porque o provedor de nuvem envia uma fatura. Não é. Uma fatura detalhada não é visibilidade de custo. Visibilidade de custo significa que cada time consegue enxergar seu gasto, corretamente atribuído, com granularidade suficiente para agir. Chegar lá exige governança de tagging, lógica de alocação e investimento em ferramentas. Sem uma base completa de Inform, os esforços de Optimize esbarram em paredes: as equipes tentam fazer right-sizing de workloads que sequer conseguem identificar por completo, ou reagem a anomalias que só descobriram semanas depois do início.
2. Optimize: right-sizing, commitments, automação
A fase Optimize é onde o princípio do modelo de custo variável se torna executável. Munidas de visibilidade precisa por time vinda do Inform, as equipes podem tomar decisões estruturadas sobre redução de gastos: fazer right-sizing de recursos superprovisionados, comprar commitments contra workloads previsíveis de baseline, eliminar recursos ociosos e órfãos e implementar agendamento para ambientes de não produção. Para um detalhamento abrangente das alavancas de otimização, veja as estratégias de otimização de custos de nuvem da DoiT.
O trabalho de Optimize também operacionaliza o princípio do valor de negócio. Toda decisão de otimização deve se conectar a um enquadramento de negócio: custo por workload, custo por transação, custo como percentual da receita. Equipes que otimizam sem essa conexão tendem a caçar economia de forma isolada, às vezes trocando performance ou confiabilidade por uma redução marginal de custo. A lente do valor de negócio mantém as decisões de otimização ancoradas em resultados que importam.
3. Operate: prática contínua e integração cultural
Operate é onde os princípios de colaboração e ownership deixam de ser compromissos declarados e viram hábitos culturais. Nessa fase, o FinOps deixa de ser projeto e vira prática: revisões de custo passam a ser parte regular dos ciclos de planejamento de engenharia, recomendações de otimização entram diretamente no trabalho do sprint e o gasto em nuvem se conecta às conversas de roadmap de produto.
A fase Operate também traz o princípio de enablement centralizado à sua forma mais visível. Um time de FinOps que precisa conduzir cada otimização manualmente não escala. A fase Operate funciona quando a função central de FinOps consegue incorporar capacidade suficiente nos times de engenharia para que a responsabilidade sobre custo se sustente sozinha: os times identificam e resolvem suas próprias ineficiências, escalam decisões complexas para a função central e participam de revisões multifuncionais como parte rotineira de como trabalham.
Como traduzir os princípios do FinOps em uma prática funcional
Princípios não viram resultados sozinhos. A sequência de implementação a seguir constrói a camada operacional que transforma os seis princípios em prática mensurável. Para mais contexto sobre a jornada completa de implementação, veja o guia da DoiT sobre implementação da gestão financeira da nuvem.
Construa primeiro a base de dados
Antes de mais nada, estabeleça uma atribuição de custo precisa e completa. Implemente um padrão de tagging que cubra todos os recursos: time, ambiente, aplicação, centro de custo. Aplique no momento do provisionamento, não como campanha de limpeza retroativa. Configure a lógica de alocação para infraestrutura compartilhada, para que os custos caiam nos times certos. Estabeleça detecção de anomalias com limites de alerta para que surpresas de custo apareçam rapidamente.
Sem essa base, toda iniciativa de FinOps subsequente opera com informação incompleta. Decisões de right-sizing deixam de fora os workloads sem tag. Conversas sobre orçamento naufragam porque financeiro e engenharia têm números diferentes. A base de dados é inegociável e exige investimento inicial antes que os times vejam resultados.
Estabeleça a função central de enablement (não um time de controle de custos)
O mandato do time de FinOps importa. Enquadre-o como uma função que cria capacidade e gera valor, não como um time que faz cumprir orçamentos ou tem redução de custo como meta. Essa distinção molda como os times de engenharia se relacionam com o FinOps e determina se o princípio da colaboração vai vingar.
A função central cuida do trabalho que exige expertise especializada e escopo organizacional: compra e gestão de commitments, negociações de tarifas, seleção e manutenção de ferramentas, políticas de governança e facilitação de revisões multifuncionais. Os times de engenharia cuidam das decisões no nível do workload, que exigem conhecimento de domínio que o time de FinOps não tem. É essa divisão de responsabilidade que faz o enablement centralizado escalar.
Implemente showback antes de chargeback
Showback significa dar aos times visibilidade sobre seus gastos em nuvem sem consequência financeira. Chargeback significa alocar esses custos diretamente aos orçamentos de time ou de produto. Comece pelo showback.
Chargeback antes que os times tenham dados de custo confiáveis e ownership estabelecido cria atrito que corrói a credibilidade do programa de FinOps. Os times contestam métodos de alocação, questionam faturas que não entendem e perdem a confiança nos dados. O showback constrói a familiaridade e a qualidade de dados necessárias para que o chargeback funcione. Ele também traz à tona questões de ownership que precisam ser resolvidas antes de a responsabilidade financeira se firmar. A maioria das organizações que corre para o chargeback passa o ano seguinte relitigando as mesmas disputas de alocação que poderiam ter resolvido na fase de showback.
Torne a otimização contínua, não trimestral
Revisões trimestrais manuais não acompanham o ritmo em que os ambientes de nuvem mudam. Novos serviços são provisionados. Workloads escalam. Configurações mudam. Uma auditoria trimestral captura o que aconteceu três meses atrás. A essa altura, o custo do problema já se concretizou.
Otimização contínua significa detecção automatizada de oportunidades de right-sizing, recursos ociosos e anomalias de custo, alimentando uma cadência regular de revisão pela engenharia. As recomendações aparecem em ciclo semanal ou de sprint, são priorizadas junto com o trabalho de features e acompanhadas até a conclusão. Esse fluxo operacionaliza tanto o princípio de acessibilidade dos dados quanto o do modelo de custo variável: usa dados oportunos para tomar decisões contínuas que exploram a flexibilidade que a nuvem oferece. Para um conjunto de métricas de referência, veja o guia de KPIs de FinOps da DoiT e a visão geral de FinOps tools.
Conecte o gasto de nuvem a resultados de negócio
Unit economics ancoram o princípio do valor de negócio em algo mensurável. Custo por usuário ativo, custo por transação, gasto em nuvem como percentual da receita, custo por funcionalidade lançada: essas métricas traduzem o gasto de infraestrutura em uma linguagem que produto, financeiro e a liderança executiva entendem e usam para tomar decisões.
Construir unit economics exige combinar dados de custo com dados de produto e de uso: volumes de transação, número de usuários, eventos de deploy. A maioria dos programas de FinOps adia esse trabalho porque exige integração entre sistemas. Equipes que fazem essa integração consistentemente tomam melhores decisões de trade-off, porque conseguem responder "quanto essa mudança de arquitetura custa por cliente?" em vez de operar em cima de totais mensais agregados.
Armadilhas comuns ao aplicar os princípios do FinOps
Vários padrões parecem FinOps, mas não entregam os resultados que os princípios descrevem.
Confundir reporting com FinOps. Construir dashboards e distribuir relatórios de gasto não é uma prática de FinOps. Reporting é o pré-requisito. O FinOps começa quando os times usam esses dados para tomar decisões que mudam os resultados. Organizações que investem pesado em ferramentas de reporting e depois pulam o trabalho de governança e otimização construíram infraestrutura para uma prática que nem sequer começaram.
Tratar redução de custo como o objetivo. Redução de custo é um resultado de um FinOps eficaz, não o objetivo. O objetivo é gerar valor de negócio a partir do gasto com tecnologia: os recursos certos, rodando os workloads certos, no ponto de custo mais eficiente para a performance e a confiabilidade exigidas. Times que miram diretamente a redução de custo tendem a otimizar de formas que comprometem a confiabilidade, minam a confiança da engenharia ou geram economias de curto prazo que custam mais para manter do que valem.
Subinvestir na função central de enablement. Programas de FinOps montados com um único analista e uma planilha não conseguem entregar a capacidade que os princípios exigem. Gestão de commitments, governança, facilitação multifuncional, ferramentas e resposta a anomalias exigem capacidade dedicada. Organizações que subdimensionam a função central e depois se frustram com os resultados de FinOps confundiram o princípio do enablement centralizado com a ideia de que o FinOps deve ser barato de operar.
Ignorar a confiança da engenharia. Se os engenheiros vivenciam o FinOps como policiamento de custos, alertas de orçamento, revisões obrigatórias e atrito adicionado ao provisionamento, eles se desengajam. Os princípios de colaboração e ownership exigem que os times de engenharia queiram participar. Isso demanda que o time de FinOps se apresente como um parceiro que remove obstáculos e cria eficiência, não como uma função de compliance que adiciona overhead. Confiança leva tempo para ser construída e pode ser perdida rapidamente se as primeiras ações visíveis do programa de FinOps soarem punitivas.
Dos princípios do FinOps à prática de FinOps
Os seis princípios do FinOps descrevem o destino. Definem como se parece uma prática madura de gestão financeira da nuvem quando funciona: colaboração multifuncional, decisões conectadas ao valor de negócio, ownership distribuído, dados confiáveis, capacidade habilitada centralmente e exploração sistemática do modelo de custo variável da nuvem.
Chegar lá exige a camada operacional por baixo: uma base de tagging e alocação, um time de FinOps com o mandato certo, um rollout com showback primeiro, fluxos de otimização contínua e unit economics que conectem o gasto às métricas de negócio que a liderança executiva realmente acompanha. Nada disso acontece automaticamente. Exige investimento, sequenciamento e compromisso sustentado entre engenharia, financeiro e operações.
A DoiT apoia essa jornada por meio de análises unificadas de custo, workflows automatizados de otimização e cloud architects certificados em FinOps que atuam ao lado da sua equipe para transformar insight em execução. Se você está pronto para sair do princípio e ir para a prática, fale com um especialista em FinOps da DoiT.
Perguntas frequentes sobre os princípios do FinOps
Quantos princípios do FinOps existem?
Existem seis princípios do FinOps, conforme definidos pela FinOps Foundation. São eles: as equipes precisam colaborar; o valor de negócio orienta as decisões de tecnologia; todos assumem ownership do seu uso de tecnologia; os dados de FinOps devem ser acessíveis, oportunos e precisos; o FinOps deve ser habilitado centralmente; e aproveite o modelo de custo variável da nuvem. Esses seis princípios se aplicam a toda a gama de gastos com tecnologia que os times de FinOps gerenciam, incluindo nuvem pública, SaaS, data centers e infraestrutura de nuvem privada.
Qual é a diferença entre os princípios do FinOps e as fases do FinOps?
Os princípios do FinOps são os valores fundamentais que definem como o FinOps deve funcionar, o que a prática representa e para onde ela caminha. As fases do FinOps (Inform, Optimize, Operate) descrevem como os times executam esses valores. Os princípios respondem à pergunta sobre que tipo de prática construir. As fases respondem à pergunta de como construí-la e que trabalho realizar em cada estágio de maturidade. Um time pode estar na fase Inform e, ao mesmo tempo, trabalhar em direção a todos os seis princípios, usando o trabalho de visibilidade para operacionalizar os princípios de acessibilidade de dados e colaboração antes de avançar para a otimização.
De onde vêm os princípios do FinOps?
Os seis princípios do FinOps vêm da FinOps Foundation, a organização sem fins lucrativos e neutra em relação a fornecedores que mantém o FinOps Framework. A Foundation é a autoridade reconhecida sobre a prática de FinOps, e seus princípios refletem contribuições de uma comunidade global de praticantes. Os princípios foram originalmente elaborados em 2019 e atualizados pela primeira vez em 2025 para refletir como o FinOps se expandiu para além da nuvem pública, em direção a uma abordagem mais ampla de Cloud+. A FinOps Foundation também publica orientações detalhadas sobre cada princípio, junto com indicadores de maturidade, visões específicas por persona e capacidades de suporte que ajudam os times a aplicá-los na prática.text