Gestão de custos na nuvem: cobrança, rightsizing, compromissos e FinOps

Um orçamento on-premises é decidido uma vez por ano por pessoas cujo trabalho é decidir orçamentos. Um orçamento de nuvem é decidido continuamente por qualquer pessoa que faça merge de um pull request que adiciona uma política de retenção, troca uma família de instâncias ou introduz uma chamada entre regiões. O poder de gastar passou para a engenharia e, na maioria das organizações, a responsabilidade não foi junto. A gestão de custos existe para fechar essa lacuna.

Este guia parte da mecânica e vai subindo: como uma fatura é montada, o que cada medidor cobra de fato, como compromissos e capacidade interrompível mudam a conta e, depois, as práticas — rightsizing, políticas de ciclo de vida, tags, orçamentos e o ciclo de FinOps — que mantêm o gasto proporcional ao valor. Nenhum preço específico aparece aqui: os preços de tabela mudam e variam por região, e o que continua útil são as proporções e os formatos.

Como uma fatura é montada de fato

Uma fatura de nuvem é uma lista enorme de itens medidos, cada um registrando um tipo de uso, uma quantidade, uma tarifa e um identificador de recurso. Quatro propriedades dessa lista explicam a maior parte da confusão em torno dela.

A unidade de cobrança é granular e baseada em tempo. Computação é cobrada por segundo ou por hora de tempo alocado, armazenamento por gigabyte-mês proporcional à hora, requisições por milhão, transferência de dados por gigabyte. Nada é cobrado por “aplicação”, então a ligação entre um item da fatura e uma função de negócio só existe se você a criar com tags.

As cobranças continuam enquanto um recurso está ocioso. Uma máquina virtual parada ainda tem um disco anexado, um IP público reservado, um snapshot e talvez um load balancer, e tudo isso é cobrado. Essa é, de longe, a fonte mais comum de gasto esquecido.

O relatório de uso detalhado é a fonte da verdade. Os dois provedores exportam um relatório por hora, no nível de cada item — AWS Cost and Usage Report, Azure Cost Details — para um armazenamento de objetos, com cerca de um dia de atraso. Os dashboards do console são agregações dele; quando um número precisar de explicação, consulte a exportação.

A amortização muda o retrato. Pagamentos antecipados de capacidade reservada aparecem como uma cobrança grande em um único mês nos custos não combinados (unblended) e se distribuem de forma uniforme nos custos amortizados. Analise tendências com custos amortizados, ou um único pré-pagamento vai parecer um serviço fora de controle.

-- Cost and Usage Report carregado em um motor de consultas: maiores variações mês a mês
SELECT line_item_product_code,
       resource_tags_user_team               AS team,
       SUM(CASE WHEN month = 8 THEN line_item_unblended_cost END) AS prev,
       SUM(CASE WHEN month = 9 THEN line_item_unblended_cost END) AS curr
FROM cur_daily
WHERE line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY (curr - prev) DESC NULLS LAST
LIMIT 25;

Duas decisões estruturais facilitam tudo o que vem depois: consolidar contas ou assinaturas sob um único acordo de cobrança, para que as faixas de volume e os compromissos sejam compartilhados por toda a organização, e separar os ambientes em contas diferentes, para que o gasto de produção e o de desenvolvimento nunca precisem ser desembaraçados por tag.

Economia unitária: para onde vai o dinheiro

Três medidores dominam quase toda fatura.

Computação costuma ser a maior fatia. Você paga por capacidade alocada ao longo do tempo, não por trabalho realizado — uma máquina virtual a 4% de CPU custa o mesmo que a 90% —, então, em cargas baseadas em servidores, tudo gira em torno da utilização. O comportamento ocioso varia muito conforme o modelo de execução: máquinas virtuais e nós de contêineres são cobrados continuamente, enquanto funções serverless só são cobradas durante a execução, a uma tarifa mais alta por unidade de tempo de computação. Funções vencem com folga em trabalho com picos e baixo ciclo de atividade, e perdem em serviços sustentados de alto throughput, onde o adicional por invocação se acumula.

Armazenamento é barato por gigabyte e caro no agregado, porque nada é apagado nunca. Os medidores a observar são capacidade, número de requisições (que pode superar o custo da capacidade em cargas com muitas leituras pequenas), taxas de recuperação nas camadas frias, durações mínimas de armazenamento que cobram por exclusão antecipada e snapshots — incrementais, mas mantidos para sempre a menos que uma política os remova. Armazenamento em bloco anexado a máquinas virtuais custa várias vezes mais por gigabyte que o armazenamento de objetos e é provisionado, não consumido: um disco de 1 TB com 5% de ocupação custa o mesmo que um cheio.

Transferência de dados é o medidor que pega as pessoas de surpresa, porque o preço é direcional e assimétrico. O tráfego de entrada na nuvem geralmente é gratuito. Entre recursos na mesma zona de disponibilidade, normalmente também; entre zonas de uma região, custa um valor modesto, muitas vezes cobrado dos dois lados; entre regiões, mais; e para a internet, o máximo, a uma tarifa várias vezes maior que a de tráfego entre regiões. Um service mesh tagarela espalhado por três zonas, ou um job de analytics que puxa toda noite um dataset de um bucket em outra região, pode gerar uma conta de transferência maior que a da computação que faz o trabalho.

Dois efeitos colaterais merecem ser nomeados. NAT gateways cobram por gigabyte processado, além de uma taxa por hora, então rotear todo o tráfego de saída por um deles — inclusive o tráfego para o próprio armazenamento de objetos do provedor — é um imposto silencioso que os private endpoints eliminam. E serviços gerenciados frequentemente cobram por uma dimensão em que você não pensou: ingestão de logs por gigabyte, dados escaneados por consulta, unidades de throughput provisionadas ou uma tarifa por requisição em um cofre de segredos chamado a cada requisição em vez de ficar em cache.

Modelos de compra

Para cargas estáveis, o preço de tabela só é o preço que você paga se nunca prestar atenção. Quatro modelos coexistem.

Compromissos são instrumentos financeiros, não técnicos: você se compromete com um nível de uso ou de gasto por hora durante um ou três anos, pago totalmente adiantado, parcialmente adiantado ou mensalmente, em troca de uma tarifa substancialmente menor. Prazos de três anos e pagamento antecipado dão os maiores descontos e a menor margem para mudar de ideia. A regra geral é se comprometer com o piso do seu gráfico de uso — o nível que você tem certeza de que ainda vai consumir daqui a dezoito meses — e deixar a parte variável em on-demand. Comprometer-se de menos desperdiça economia; comprometer-se demais significa pagar por capacidade que você não usa mais, o que é pior, porque não dá para desfazer.

Prefira o instrumento flexível quando ele existir. Um compute savings plan se aplica automaticamente a qualquer computação elegível que você esteja rodando, então migrar de máquinas virtuais para contêineres ou para uma geração de instâncias mais nova não deixa o compromisso encalhado. Reservas para bancos de dados, caches e clusters de busca gerenciados geralmente ficam presas a uma configuração específica e, por isso, devem ser dimensionadas de forma mais conservadora.

Capacidade spot é o estoque ocioso do provedor, oferecido por uma fração da tarifa on-demand e retomado com pouco aviso. Ela transforma a economia de tudo o que é interrompível: runners de CI, analytics em batch, processamento de mídia, treinamento de machine learning com checkpoints e camadas web stateless que toleram perder parte da frota. Para usá-la bem, diversifique entre vários tipos de instância e zonas, para que uma retomada em um pool não esvazie a frota; trate o aviso de interrupção para drenar de forma ordenada; faça checkpoints em jobs longos; e combine uma base de capacidade on-demand ou comprometida com um restante em spot.

Rightsizing, agendamento e autoscaling

Comprar capacidade mais barata vale menos do que não comprá-la. Três técnicas entregam a maior parte da redução disponível em um ambiente típico.

Rightsizing ajusta a capacidade provisionada ao uso observado. Os dois provedores geram recomendações a partir de métricas históricas; trate-as como uma lista inicial, porque elas enxergam CPU e memória, mas não a janela de batch em que a carga realmente precisa de folga. Olhe a utilização máxima e o p99 ao longo de várias semanas em vez da média, e mude uma dimensão por vez. Famílias de instância mais novas costumam oferecer melhor desempenho por unidade de custo, então trocar de geração muitas vezes é um rightsizing sem contrapartida.

Agendamento desliga o que ninguém está usando. Ambientes que não são de produção e são usados em horário comercial ficam ociosos cerca de dois terços da semana; desligá-los fora do expediente elimina essa proporção do custo de computação deles. É a ação de maior retorno e menor risco na maioria das organizações, e precisa de um dono, porque nunca acontece espontaneamente.

# Aplique a tag uma vez e depois pare, em um agendamento, tudo o que tiver essa tag
aws ec2 create-tags --resources i-0a1b2c3d --tags Key=schedule,Value=office-hours

ids=$(aws ec2 describe-instances \
  --filters "Name=tag:schedule,Values=office-hours" "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].InstanceId' --output text)
[ -n "$ids" ] && aws ec2 stop-instances --instance-ids $ids

Autoscaling é um controle de custo tanto quanto de disponibilidade, mas só se ele reduzir. Muitos ambientes escalam horizontalmente sob carga e nunca voltam atrás, porque a política de scale-in está ausente, é conservadora demais ou fica bloqueada por conexões de longa duração. Verifique se a capacidade de fato cai durante a noite; se o gráfico é uma escada que só sobe, a política não está cumprindo seu papel. No Kubernetes, o mesmo vale em dois níveis — autoscaling de pods a partir de métricas reais e um cluster autoscaler autorizado a remover nós —, além de requests honestos, já que requests superdimensionados reservam capacidade que é cobrada e nunca usada. Veja os fundamentos de Kubernetes para a mecânica.

Ciclo de vida do armazenamento é o equivalente para os dados. Escreva uma política que mova os objetos para camadas mais frias à medida que envelhecem e os apague ao fim do período de retenção, e aplique o mesmo raciocínio a snapshots, imagens de contêiner em registries e retenção de logs. A ingestão de logs e telemetria costuma estar entre os cinco maiores itens da fatura; amostrar traces, descartar logs de nível debug em produção e encurtar a retenção quente, arquivando em armazenamento de objetos, geralmente a reduz de forma substancial sem perder a capacidade de investigar. Plataformas de analytics cobradas por byte escaneado respondem de forma impressionante a particionamento e formatos colunares, como discutido em arquitetura de big data.

Alocação: tags, showback e chargeback

Não dá para delegar a responsabilidade pelo custo a um time que não enxerga os próprios custos, e essa visibilidade depende inteiramente da alocação.

Defina um conjunto pequeno de tags obrigatórias — normalmente dono ou time, ambiente, aplicação ou serviço, centro de custo e classificação de dados — e exija-o no momento da criação, em vez de auditar depois. Os motores de políticas das duas plataformas podem recusar a criação de recursos sem tags, e módulos de infraestrutura como código podem aplicar tags por padrão, para que a conformidade seja o caminho de menor resistência. Ative as tags como tags de alocação de custos no console de cobrança; caso contrário, elas nunca chegam aos relatórios.

Parte do gasto é de fato compartilhada: o hub de rede, a plataforma de observabilidade, as ferramentas de segurança, o desconto dos compromissos. Decida e publique uma regra de alocação — igualitária, por uso, por time ou deixada em um pool central — antes que alguém comece a discutir. Alocação perfeita não é o objetivo; uma regra que todos entendam, sim.

Showback publica o gasto de cada time sem movimentar dinheiro e basta, na maioria das organizações, para mudar comportamentos. Chargeback de fato transfere o custo para o orçamento do time, o que cria incentivos mais fortes e bem mais discussão; vale o esforço principalmente quando os times têm autonomia orçamentária real.

O número que muda as conversas não é o gasto total, e sim o custo unitário: custo por cliente ativo, por mil pedidos, por gigabyte ingerido. Um gasto total que sobe 20% enquanto o custo unitário cai 10% é um negócio em crescimento ficando mais eficiente. Sem o denominador, todo aumento parece um fracasso e toda redução parece uma vitória.

Orçamentos, anomalias e o ciclo de FinOps

Defina orçamentos por conta, por time e por serviço principal, com alertas em vários limites e sobre a previsão, não apenas sobre o gasto real — um alerta de previsão no dia 8 do mês é útil; um alerta de gasto real no dia 29 é um post-mortem. Adicione por cima a detecção de anomalias: os dois provedores oferecem detecção baseada em machine learning que sinaliza um serviço cujo gasto foge do próprio padrão, e é isso que pega um cluster provisionado por engano ou um loop de retry descontrolado em um dia, em vez de no fim do mês.

FinOps, como a prática costuma ser chamada, descreve um ciclo recorrente de três fases. Informar: alocação, dashboards, métricas unitárias, previsões — todo mundo enxerga os próprios números. Otimizar: rightsizing, agendamento, compra de compromissos, mudanças de arquitetura, cada ação com um dono e uma economia estimada. Operar: tornar tudo contínuo — custo como item nas revisões de arquitetura, uma estimativa de custo anexada a mudanças de infraestrutura significativas, uma revisão periódica do portfólio de compromissos e guardrails que impeçam os piores erros. O pilar de custo do Well-Architected Framework traduz esse mesmo ciclo em perguntas de revisão.

Sustos na fatura que vale a pena prevenir

Recursos esquecidos. Load balancers sem targets, discos desanexados, NAT gateways ociosos, snapshots de uma migração de dois anos atrás, um cluster de prova de conceito em uma região que ninguém monitora. Procure por eles de forma agendada; eles nunca somem sozinhos.

Tráfego entre zonas e entre regiões. Uma malha de microsserviços espalhada por zonas para garantir disponibilidade multiplica a transferência entre zonas. Um roteamento que leve em conta as zonas e prefira uma réplica local elimina a maior parte disso.

Egress de um serviço com muitos dados. Servir mídia ou exportações grandes diretamente do armazenamento de objetos para a internet contabiliza cada byte. Uma CDN na frente geralmente é mais barata, além de mais rápida.

Explosões de logs e métricas. Uma única flag de debug esquecida em produção, ou um label de métrica de alta cardinalidade como um identificador de usuário, pode multiplicar uma fatura de observabilidade da noite para o dia.

Cobranças por requisição chamadas em loop. Cofres de segredos, parameter stores e serviços de gerenciamento de chaves cobram por chamada de API. Buscar um segredo a cada requisição em vez de guardá-lo em cache transforma um item desprezível em um bem visível.

Ambientes de não produção ligados o tempo todo. Quase universal, totalmente evitável e, em geral, a maior economia disponível em uma primeira revisão de custos.

Principais conclusões

• Uma fatura de nuvem é um registro de medidores muito granular; a exportação de uso detalhado é a fonte da verdade, e recursos ociosos continuam sendo cobrados até serem apagados.
• Computação é cobrada por tempo alocado, independentemente da utilização; armazenamento se acumula porque nada é apagado; e transferência de dados é direcional e assimétrica — egress e tráfego entre regiões dominam.
• Comprometa-se com o piso do uso estável usando savings plans flexíveis, reserve recursos fixos e duradouros e rode o trabalho interrompível em spot, com diversificação e tratamento de interrupções.
• Não comprar capacidade é melhor do que comprá-la barato: dimensione a partir dos picos observados, desligue a não produção fora do expediente, verifique se o autoscaling reduz e expire dados com políticas de ciclo de vida.
• Exija um conjunto pequeno de tags obrigatórias na criação, publique showback por time e acompanhe o custo unitário para que crescimento não seja confundido com desperdício.
• FinOps é um ciclo contínuo de informar, otimizar e operar, apoiado por orçamentos sobre a previsão e alertas de anomalia que revelam os erros em dias, e não no fim do mês.