Cloud Cost Runaway: Os 5 Padrões FinOps Que Estão a Destruir o Orçamento de IT

A factura de cloud do mês passado foi superior à do mês anterior. E a do mês anterior foi superior à de há três meses. Este padrão é mais comum do que parece, e o problema raramente é o crescimento do negócio. Na maioria dos casos, é desperdício silencioso que ninguém está a medir.

Trinta por cento. Em empresas com facturas cloud de seis a sete dígitos anuais, esse número representa investimento que não produz nenhum valor de negócio. Não é uma estimativa de mercado académica: é o padrão que encontramos repetidamente quando fazemos os primeiros assessments com clientes em manufacturing, logística e retalho.

Este artigo identifica os cinco padrões de desperdício cloud mais comuns em empresas não-tech com 100 a 2.000 colaboradores, explica por que motivo cada um cresce invisível e descreve o que é necessário para os corrigir de forma sustentável.

Por que motivo o problema se agrava todos os meses

Antes de entrar nos padrões, importa perceber a dinâmica de fundo.

O aumento de investimento por si só não é um problema. O problema é que a maioria das organizações não tem os mecanismos de visibilidade e controlo que acompanham esse crescimento. Provisionam recursos para um projeto, o projeto termina, os recursos ficam. Compram reservas a três anos para workloads que mudam em seis meses. Instalam agentes de monitorização em todas as instâncias mas nunca consultam os dados.

O resultado é uma factura que cresce por inércia, não por decisão.

Padrão 1: Recursos Órfãos e Ambientes Fantasma

Este é o padrão mais comum e, paradoxalmente, o mais fácil de resolver quando se tem visibilidade.

Um ambiente de desenvolvimento é criado para um projeto de integração com um fornecedor. O projeto termina. O ambiente fica activo durante 14 meses enquanto consome compute, storage e transferência de dados. Ninguém questiona porque a factura está integrada numa linha de "infra cloud" que é aprovada em bloco no relatório mensal.

Os recursos órfãos assumem várias formas:

• Volumes de disco não associados a instâncias activas. Quando se termina uma instância EC2 ou uma VM Azure, o disco persistente muitas vezes não é eliminado automaticamente. Acumula-se.
• Load balancers sem targets registados. Continuam a cobrar por hora independentemente de não estarem a servir tráfego.
• Endereços IP elásticos não associados. Em AWS, um IP elástico não associado a uma instância em execução tem custo. Parece marginal; em escala, não é.
• Snapshots antigos sem política de retenção. Algumas organizações têm snapshots de ambientes de produção de dois ou três anos que nunca foram eliminados.

A correcção deste padrão passa por três acções concretas: inventário automatizado de todos os recursos cloud com flag de "último acesso", política de tags obrigatória que associe cada recurso a um centro de custo e responsável, e processo de descomissionamento formal associado ao fim de projecto.

Não é tecnicamente complexo. É operacionalmente disciplinado.

Padrão 2: Sobre-Provisionamento Sistemático

O sobre-provisionamento tem uma origem cultural, não técnica. Quando os servidores eram físicos, havia um custo real de ficar sem capacidade. A memória e CPU não utilizadas eram um seguro barato contra incidentes. Essa mentalidade migrou para cloud sem a correspondente adaptação: em cloud, esse "seguro" tem custo variável e contínuo.

O padrão manifesta-se assim: a equipa de infra define instâncias para o pico de carga esperado no lançamento de um sistema. Dois anos depois, a utilização média de CPU está nos 12% e a de memória nos 18%. Ninguém reviu o dimensionamento porque "está a funcionar".

A questão não é reduzir a performance. É perceber que cloud permite rightsizing dinâmico: dimensionar para a carga real com capacidade de escalar em minutos, não em semanas.

As ferramentas nativas dos três grandes providers (AWS Compute Optimizer, Azure Advisor, GCP Recommender) geram recomendações de rightsizing automaticamente. O problema não é falta de ferramentas. É falta de processo para actuar sobre as recomendações com cadência regular.

Uma revisão trimestral de rightsizing, conduzida pelo IT com validação dos product owners dos sistemas afectados, é suficiente para eliminar a maioria deste desperdício.

Padrão 3: Commitments Desalinhados com a Realidade do Negócio

Reserved Instances, Savings Plans e Committed Use Discounts oferecem descontos substanciais (tipicamente 30 a 72% face a preços on-demand) em troca de compromisso de utilização a 1 ou 3 anos. São um instrumento financeiro legítimo e poderoso quando bem calibrados.

O problema surge quando os commitments são adquiridos com base em projecções optimistas ou em workloads que depois migram, são descomissionados ou mudam de forma significativa.

Cenário típico: uma empresa de logística compra Reserved Instances para suportar a plataforma de gestão de frotas on-premises que está a migrar para cloud. A migração atrasa seis meses. Durante esse período, as reservas correm em vazio. Depois de concluída a migração, a plataforma é redesenhada e usa instâncias de família diferente. As reservas antigas continuam válidas mas inaplicáveis ao novo perfil.

A disciplina necessária aqui é diferente: não é operacional, é de planeamento financeiro integrado com o roadmap técnico. Antes de adquirir qualquer commitment de um ano ou mais, é necessário validar três perguntas: este workload vai existir durante todo o período do commitment? O perfil de instâncias vai manter-se estável? Existe flexibilidade para converter ou revender o commitment se as condições mudarem?

Savings Plans (na AWS e Azure) têm mais flexibilidade que Reserved Instances clássicas e são, na maioria dos casos, o instrumento preferível para empresas com roadmaps técnicos em evolução.

Padrão 4: Transferência de Dados Não Contabilizada

Este é o padrão que mais frequentemente surpreende os directores de IT quando vêem a factura detalhada pela primeira vez.

Os providers cloud cobram pela transferência de dados de formas que não são intuitivas:

• Egress inter-regiões. Dados que saem de uma região para outra têm custo. Uma arquitectura multi-região sem optimização de data locality pode gerar custos de transferência significativos.
• Egress para internet. A transferência de dados para fora da cloud (para utilizadores finais, para sistemas on-premises, para partners) tem custo que escala com o volume.
• Transferência entre Availability Zones. Em AWS e Azure, transferência entre AZs dentro da mesma região também tem custo, apesar de ser frequentemente ignorado no design de arquitecturas.
• API calls a serviços geridos. Alguns serviços geridos (S3, por exemplo) cobram por número de chamadas de API, que podem acumular em arquitecturas de alta frequência.

A visibilidade deste padrão requer análise de factura ao nível de line item, não apenas ao nível de serviço. A maioria das organizações analisa a factura cloud com granularidade de "quanto gastámos em compute este mês" e não com granularidade de "quanto custou a transferência de dados entre o nosso ambiente de produção em Frankfurt e o de DR em Amesterdão".

A correcção começa por instrumentação: tagging de recursos por função e mapeamento de fluxos de dados. A optimização pode passar por consolidação de serviços na mesma AZ, uso de CDNs para reduzir egress directo, ou revisão de arquitecturas que fazem transferência desnecessária de dados.

Padrão 5: Ausência de Ownership Financeiro Claro

Os quatro padrões anteriores são manifestações técnicas. Este último é estrutural e é o que impede os outros de serem resolvidos de forma permanente.

Em muitas organizações, a factura cloud chega ao departamento financeiro como uma única linha, é aprovada, e segue. O IT sabe que a factura existe mas não tem mandato formal para a optimizar. As equipas de produto e desenvolvimento provisionam recursos sem visibilidade do custo real. Os gestores de conta dos providers cloud têm incentivo para aumentar o spend, não para o reduzir.

FinOps não é uma ferramenta. É uma prática organizacional que define quem é responsável por cada euro de cloud spend, com que cadência esse custo é revisto, e qual o processo de decisão para aumentar ou reduzir recursos.

A estrutura mínima viável para uma empresa de 200 a 500 colaboradores inclui:

1. Um FinOps owner (pode ser o IT Manager ou um elemento sénior de infra) com tempo dedicado, não necessariamente a tempo inteiro, mas com horas formalmente alocadas.
2. Dashboard de custo em tempo real acessível a IT, produto e gestão, com granularidade por projecto ou departamento.
3. Reunião mensal de revisão de custo com representantes de IT e dos principais centros de custo cloud.
4. Política de tagging obrigatório antes de qualquer recurso ser provisionado.

Sem ownership claro, os outros padrões reaparecem sistematicamente, mesmo depois de correcções pontuais.

O Impacto Composto: O Que Representa em Termos Financeiros

Para tornar isto concreto: uma empresa com factura cloud anual de €500.000 (um valor frequente em empresas de manufacturing ou retalho com 300 a 800 colaboradores que migraram cargas significativas para cloud) tem potencial de recuperar €150.000 anuais através de práticas FinOps estruturadas.

Esse valor não é alcançado de uma vez. Um programa FinOps típico tem três horizontes:

Horizonte imediato (0 a 60 dias): Eliminação de recursos órfãos e rightsizing óbvio. Impacto rápido, baixo risco operacional. Tipicamente 8 a 12% de redução.

Horizonte de médio prazo (60 a 180 dias): Revisão de commitments, optimização de transferência de dados, implementação de políticas de tagging e governance. Requer coordenação entre IT e produto. Tipicamente 10 a 15% adicional.

Horizonte estrutural (180 dias em diante): Práticas FinOps integradas no ciclo de desenvolvimento, revisões regulares, optimização contínua. Mantém e estende os ganhos anteriores.

Vale notar que o Gartner projecta que, até 2026, organizações que fundirem Software Asset Management com FinOps vão reportar 60% menos financial waste. Para empresas com licenciamento complexo (SAP, Oracle, Microsoft 365 em larga escala), a integração destas duas práticas é o próximo passo lógico após consolidar o FinOps básico.

Por Onde Começar Sem Paralisar a Operação

A inibição mais comum que encontramos não é falta de vontade de resolver o problema. É o receio de que mexer na infra cloud vai criar instabilidade operacional.

Esse receio é legítimo mas gerível. A abordagem correcta começa sempre por visibilidade, não por acção. Antes de eliminar ou redimensionar qualquer recurso, é necessário perceber o que existe, quem usa, e qual o impacto de uma alteração.

As primeiras quatro semanas de um programa FinOps devem ser exclusivamente de inventário e análise:

• Exportação detalhada da factura cloud dos últimos seis meses, com granularidade de linha.
• Mapeamento de recursos activos por serviço, região e centro de custo.
• Identificação de recursos sem tags ou com tags inconsistentes.
• Análise de utilização média de compute e memória nos últimos 30 e 90 dias.

Só com este mapa é possível priorizar acções por impacto financeiro e por risco operacional. Recursos com zero utilização nos últimos 90 dias e sem dono identificado têm risco baixo. Instâncias de produção com 15% de utilização média requerem validação antes de qualquer alteração.

O Papel do IT Director Neste Processo

FinOps não pode ser delegado apenas às equipas técnicas nem apenas ao departamento financeiro. Requer uma ponte entre os dois, e o IT Director ou CIO é a posição natural para fazer essa ponte.

O mandato do IT neste contexto é duplo: garantir que a infra cloud serve os objectivos do negócio de forma eficiente, e garantir que o custo dessa infra é visível, previsível e justificável para a gestão.

Numa empresa não-tech, esse mandato é frequentemente mais político do que técnico. Implica criar coligações com os directores de operações, produto e finanças. Implica defender que o investimento em governance cloud tem retorno directo e mensurável. Implica, por vezes, criar fricção construtiva com equipas de desenvolvimento que preferem a conveniência de provisionar sem restrições.

É um trabalho de gestão, não apenas de tecnologia.

Próximo Passo

Quando dois ou mais destes padrões se reconhecem numa organização, o passo seguinte é quantificar o problema com dados reais da infraestrutura, não com benchmarks de mercado.

O primeiro passo é uma Sessão de Esclarecimento: reunião breve, sem compromisso, para perceber onde está o desperdício e qual o caminho para reduzir o custo. Quando faz sentido, segue-se um Cloud Cost & Reliability Review de âmbito fechado, que produz um plano priorizado.