O custo invisível do Azure: o que ninguém olha até a fatura chegar

Olá pessoal! Blz?

Nesse artigo quero trazer a vocês algo não muito técnico mas de muita importância quando voce trabalha com Cloud que são os “custos invisiveis” que não vemos no dia a dia mas traz um impacto gigante na fatura no final do mês.

Seu problema não é o preço do Azure. É a ausência de observabilidade financeira.

Essa frase costuma incomodar porque desloca a culpa. É fácil dizer que a nuvem ficou cara, que o Azure está cobrando demais ou que a fatura veio acima do esperado. Mas, na prática, boa parte dos sustos com custo não nasce de uma máquina virtual grande demais ou de um serviço premium escolhido por engano.

O problema geralmente está naquilo que ninguém observa todos os dias: tráfego de rede, logs crescendo sem retenção, snapshots esquecidos, discos órfãos, ambientes de homologação ligados durante a madrugada, alertas inexistentes e uma configuração de monitoramento que coleta mais do que entrega valor.

No passado eu trouxe um artigo de como diminuir custos removendo recursos órfãos.

Um disco gerenciado que sobrou após uma VM removida. Um snapshot criado para uma mudança emergencial e nunca apagado. Um workspace do Log Analytics recebendo logs verbosos de todos os recursos. Um ambiente de teste que deveria funcionar das 8h às 18h, mas roda 24 horas por dia, inclusive aos finais de semana. Um fluxo de dados saindo constantemente para fora do Azure sem ninguém acompanhar o volume.

Nenhum desses itens parece grave isoladamente. O problema é que eles se acumulam silenciosamente até aparecerem juntos na fatura.

O custo invisível começa onde o monitoramento técnico termina

Muitas empresas monitoram CPU, memória, disponibilidade, latência e erros de aplicação. Isso é essencial, mas incompleto.

Um ambiente pode estar tecnicamente saudável e financeiramente descontrolado ao mesmo tempo. A aplicação responde rápido, os dashboards estão verdes, os alertas não disparam, mas a conta continua subindo.

Esse é o ponto em que FinOps deixa de ser apenas uma prática financeira e passa a fazer parte da engenharia. Observar custos não significa olhar a fatura no final do mês. Significa tratar consumo como um sinal operacional.

Assim como uma alta de latência exige investigação, um aumento repentino de ingestão de logs, tráfego de saída ou criação de snapshots também deveria chamar atenção.

Tráfego de rede: o campeão invisível

Um dos custos mais subestimados no Azure é o tráfego de rede.

É comum arquiteturas serem desenhadas considerando processamento, armazenamento e disponibilidade, mas deixando o fluxo de dados em segundo plano. A pergunta geralmente é: “O serviço funciona?”. A pergunta financeira deveria ser: “Para onde os dados estão indo, com que frequência e em qual volume?”.

Ter os serviços disponíveis em várias regiões é lindo, mas o que ninguém pensa é no custo do tráfego de rede entre as regiões.

Um exemplo simples é uma aplicação hospedada em uma região consumindo dados pesados de outra região. Outro exemplo é a saída frequente de arquivos para clientes, integrações externas, pipelines de dados ou ferramentas de terceiros.

O egress, ou tráfego de saída, merece atenção especial. Muitas equipes sabem quanto custa armazenar dados, mas não sabem quanto custa movimentá-los. Isso cria uma falsa sensação de previsibilidade. O armazenamento parece barato até o dado começar a sair em grande volume.

Meu ambiente é pequeno e mais para laboratório, por isso, você não vê muitos gastos de largura de banda entre regiões

Logs: quando observar demais também custa caro

Azure Monitor, Log Analytics e Application Insights são ferramentas poderosas. O problema começa quando tudo é enviado para logs, nada tem retenção definida e ninguém sabe exatamente o que está sendo consultado.

Observabilidade técnica sem governança pode virar desperdício financeiro.

Em muitos ambientes, a ingestão de logs cresce porque diagnósticos são habilitados com pressa. Durante um incidente, alguém ativa logs detalhados para investigar um problema. A aplicação volta ao normal, mas a configuração permanece.

Semanas depois, o workspace continua recebendo dados em volume alto. Quando a fatura chega, o custo aparece como monitoramento, mas a causa real foi falta de revisão.

Outro caso comum é configurar Diagnostic Settings de forma ampla demais. Enviar logs de todos os recursos, todas as categorias e todas as métricas para um único workspace parece prático, mas pode ser caro e pouco útil.

Nem todo log precisa ser armazenado pelo mesmo período. Nem todo recurso precisa ter o mesmo nível de detalhamento. Nem todo dado operacional precisa ir para Log Analytics.

Snapshots esquecidos: cópia temporária que virou despesa permanente

Snapshots são ótimos para reduzir risco operacional. Antes de uma mudança importante, criar um snapshot de disco pode ser uma decisão prudente.

O problema é quando esse snapshot é tratado como temporário no discurso, mas permanente na prática.

O padrão é conhecido: alguém cria um snapshot antes de uma atualização, migração ou teste. A mudança funciona. A equipe comemora. O snapshot permanece. Depois de alguns meses, ninguém lembra mais se ele pode ser removido. O medo de apagar algo importante mantém o recurso vivo. O custo continua correndo.

Snapshots esquecidos são um exemplo perfeito de custo invisível porque raramente aparecem em dashboards técnicos. Eles não geram incidente, não afetam performance e não incomodam ninguém. Apenas existem. E enquanto existem, custam.

O exemplo acima tem snashots de 2023, hoje em 2026 será que ainda faz sentido manter esses snapshots?

Um script simples para listar snapshots com data de criação ajuda muito em revisões periódicas:

az snapshot list \
  --query "[].{name:name, resourceGroup:resourceGroup, location:location, created:timeCreated, sizeGB:diskSizeGb}" \
  -o table

O ideal é que snapshots temporários recebam tags no momento da criação.

Tags como Owner, CreatedBy, Purpose e DeleteAfter ajudam a transformar uma decisão manual em um processo governável.

Discos órfãos: quando a VM vai embora, mas a conta fica

Discos gerenciados órfãos são outro clássico.

Uma VM é removida, mas o disco permanece. Às vezes isso acontece por segurança, para evitar perda acidental de dados. O Azure permite manter o disco mesmo depois da exclusão da VM.

Essa flexibilidade é útil, mas cria um risco: o disco deixa de ter função clara e passa a consumir orçamento indefinidamente.

Em ambientes com muitas criações e remoções de máquinas, principalmente laboratórios, homologação, equipes independentes ou ambientes de projeto, discos órfãos podem se multiplicar rapidamente.

Para automatizar a identificação, Azure CLI resolve bem:

az disk list \
  --query "[?managedBy==null].{name:name, resourceGroup:resourceGroup, location:location, sizeGB:diskSizeGb, sku:sku.name}" \
  -o table

Ambientes de homologação ligados: o 24x7 que ninguém pediu

Nem todo ambiente precisa existir o tempo todo. Essa frase parece óbvia, mas muitas faturas mostram o contrário. Ambientes de desenvolvimento, teste, QA e homologação frequentemente ficam ligados 24 horas por dia, sete dias por semana, mesmo sendo usados apenas em horário comercial.

A economia aqui não exige necessariamente redesenhar a arquitetura. Em muitos casos, agendar desligamento e religamento já reduz bastante o custo.

Azure Automation, Logic Apps, Functions ou até scripts executados por pipeline podem ajudar. Para VMs, o próprio recurso de auto-shutdown pode ser suficiente em cenários simples.

Existem diversos artigos na internet de como criar automações para desligar máquinas virtuais baseado em TAGs, segue um exemplo Como realizar um Start/Stop em VMs no Azure fora do horário de uso com TAGs

Tags: o detalhe simples que separa custo de adivinhação

Sem tags, a fatura vira um quebra-cabeça. Você até sabe quanto gastou, mas não sabe exatamente quem gastou, por quê e para qual produto, projeto ou ambiente.

Um modelo mínimo de tags deveria responder quatro perguntas:

• Quem é o dono?
• Qual é o ambiente?
• Qual aplicação ou produto usa o recurso?
• Qual centro de custo deve receber a cobrança?

Em muitos contextos, também vale incluir criticidade, data de expiração e finalidade.

Budget e alertas: não espere a fatura para descobrir

Cost Management permite criar budgets e alertas. Ainda assim, muita gente só olha para custos quando a cobrança fecha.

Um alerta no meio do mês não resolve tudo, mas dá tempo de investigar, conter e corrigir.

O ideal é criar budgets por assinatura, resource group, produto, ambiente ou centro de custo. Um orçamento único para toda a organização costuma ser amplo demais. Quando ele estoura, ninguém sabe exatamente onde agir.

Já budgets segmentados ajudam a identificar desvios com mais precisão.

Concluindo!

A fatura do Azure raramente é o primeiro aviso. Antes dela, existem sinais: crescimento de ingestão, aumento de tráfego, recursos sem dono, ambientes esquecidos, snapshots antigos, discos não associados, budgets ausentes e alertas ignorados.

O problema é que muitas organizações só olham para esses sinais depois que o custo já virou cobrança. A maturidade financeira na nuvem começa quando custo deixa de ser assunto mensal e passa a ser métrica operacional.

Seu problema não é o preço do Azure. É a ausência de observabilidade financeira.

Quando você corrige isso, a fatura deixa de ser surpresa e passa a ser consequência de decisões visíveis.

Bom pessoal, eu tenho usado isso em alguns ambientes e acredito que possa ser bem útil a vocês!

Artigos relacionados

Apply billing tags

What is Microsoft Cost Management

Compartilhe o artigo com seus amigos clicando nos icones abaixo!!!