Meus custos de infraestrutura ocultos destruíram meu orçamento.

Olá a todos, aqui é Jules Martin, novamente em agntmax.com. Espero que todos estejam bem. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que vi emergir em mais conversas e análises pós-mortem de projetos do que gostaria de admitir: o saque invisível dos custos de infraestrutura não otimizada. Todos nós sabemos que precisamos construir rapidamente, escalar velozmente e entregar funcionalidades ontem. Mas muitas vezes, nessa pressa, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços funcionando no piloto automático, acumulando contas que mal olhamos antes que a revisão do orçamento trimestral chegue como uma tonelada de tijolos.

Então, para este artigo, vou me aprofundar na otimização de custos, mas com um ângulo muito específico e oportuno: como parar de perder dinheiro em recursos “sempre ativos” que deveriam ser “sob demanda” ou “ativados por eventos”. Estamos em 2026, pessoal. Os dias de fornecer servidores sob demanda acabaram. Se sua conta de nuvem ainda se parece com uma lista telefônica, é hora de agir.

O Assassino Silencioso: Sempre Ativo Quando Deveria Ser Sob Demanda

Vamos ser realistas. Quando estamos sob pressão para lançar uma nova ferramenta para os agentes ou uma melhoria no atendimento ao cliente, o custo geralmente passa a ser secundário em relação à funcionalidade e à velocidade. Fornecemos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior só por segurança”. Lançamos um banco de dados com IOPS provisionados que poderiam gerenciar toda a Internet, apenas para encontrá-lo principalmente inativo durante as horas de pico. Esquecemos de configurar políticas de escalonamento apropriadas, ou simplesmente deixamos tudo funcionando 24 horas por dia, 7 dias por semana, porque, bem, é mais fácil não pensar nisso.

Eu vi tudo isso com meus próprios olhos há alguns meses com o novo painel de análise interna de um cliente. A equipe, que Deus os abençoe, havia construído um sistema fantástico que fornecia aos agentes panoramas em tempo real das interações com os clientes. Foi uma grande vitória para o desempenho. Mas quando chegou a primeira fatura completa da nuvem, o diretor financeiro quase teve um infarto. Eles haviam provisionado um cluster EKS robusto, algumas instâncias RDS de alto nível e uma infinidade de funções Lambda com alocações de memória generosas, todas operando sem interrupções. O clímax do espetáculo? O painel era utilizado principalmente pelos agentes durante o horário comercial, das 9h às 17h, de segunda a sexta-feira. Fora desse horário, era uma cidade fantasma.

Estavam pagando por uma capacidade de nível empresarial para um sistema que estava efetivamente inativo 70% da semana. É como comprar um carro de Fórmula 1 para ir ao supermercado uma vez por semana.

Identificar os Culpados: Para Onde Vai Realmente Seu Dinheiro

Antes de poder consertar qualquer coisa, é necessário saber o que está quebrado. A maioria dos fornecedores de nuvem oferece ferramentas para ajudá-lo a visualizar seus gastos, e você absolutamente precisa usá-las. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports – não são apenas para finanças. Eles são sua primeira linha de defesa.

Os Suspeitos Habituales

• Instância de Cálculo (EC2, VMs): Muitas vezes são os maiores culpados. Estão superdimensionadas? Funcionam quando não deveriam? Você está usando a família de instâncias certa para sua carga de trabalho?
• Bancos de Dados (RDS, Azure SQL, Cloud SQL): Assim como o cálculo, os bancos de dados podem estar sobrecarregados para IOPS, CPU ou memória. Muitos agora oferecem opções sem servidor que se reduzem a zero ou a um custo próximo a zero quando estão inativos.
• Armazenamento (volumes EBS, discos não anexados): Você já iniciou uma instância, a encerrou, mas deixou o volume de armazenamento associado desprotegido? Isso acontece com mais frequência do que você pensa.
• Rede (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem te surpreender, especialmente entre regiões. As NAT Gateways também têm um custo horário, mesmo que não façam nada.
• Serviços Subutilizados: Você está pagando por um cache Redis dedicado que tem apenas alguns acessos por dia? Um cluster Kafka gerenciado para um fluxo de mensagens?

Meu cliente do painel de análise começou a examinar seu AWS Cost Explorer. As entradas de gastos mais relevantes eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS anexados a instâncias encerradas e uma NAT Gateway em uma VPC que não estava mais sendo usada para tráfego de produção. Pequenas coisas, mas se acumulam.

Estratégias para Transformar Sempre Acesso em Sob Demanda (ou Fora de Pico)

Tudo bem, você identificou as áreas onde gasta demais. Vamos para a parte divertida: consertá-las. O objetivo não é apenas economizar dinheiro, mas construir um sistema mais resiliente e eficiente que consome recursos apenas quando realmente precisa.

1. Planeje Início/Parada das Instâncias

Este é provavelmente o fruto mais fácil para muitas aplicações. Se suas ferramentas internas ou ambientes de staging são utilizados apenas durante o horário comercial, não há motivo para funcionarem 24 horas por dia, 7 dias por semana. A maioria dos provedores de nuvem oferece métodos nativos para programar os ciclos de ativação das instâncias, ou você pode criar sua própria solução com funções sem servidor.

Exemplo Prático: Planejador EC2 AWS com Lambda

Você pode criar uma função Lambda simples ativada por eventos CloudWatch (expressões CRON) para parar e iniciar as instâncias EC2 com base nas tags. Aqui está uma versão simplificada do código da função Lambda (Python):

import boto3

def lambda_handler(event, context):
 ec2 = boto3.client('ec2')
 
 # Definir tag para identificar as instâncias a parar/iniciar
 # Por exemplo, 'Schedule': 'business-hours'
 
 # Recuperar todas as instâncias em execução com a tag 'Schedule' definida como 'business-hours'
 running_instances = ec2.describe_instances(
 Filters=[
 {'Name': 'instance-state-name', 'Values': ['running']},
 {'Name': 'tag:Schedule', 'Values': ['business-hours']}
 ]
 )
 
 stop_instance_ids = []
 for reservation in running_instances['Reservations']:
 for instance in reservation['Instances']:
 stop_instance_ids.append(instance['InstanceId'])
 
 if stop_instance_ids:
 print(f"Parando as instâncias: {stop_instance_ids}")
 ec2.stop_instances(InstanceIds=stop_instance_ids)
 else:
 print("Nenhuma instância a parar.")
 
 # --- Lógica semelhante para iniciar as instâncias em outro momento ---
 # Você teria outro Lambda/Event CloudWatch para iniciar,
 # ou combinaria a lógica com uma tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Planejamento das instâncias EC2 concluído.'
 }

Você deve configurar duas regras de eventos CloudWatch: uma para acionar essa Lambda, digamos, às 18:00 UTC para parar as instâncias, e outra às 7:00 UTC para iniciá-las. Isso pode reduzir os custos de computação em mais de 70% para esses recursos específicos.

2. Adote o Sem Servidor e a Orquestração de Contêineres

Se sua carga de trabalho é realmente esporádica ou ativada por eventos, o sem servidor é seu melhor aliado. AWS Lambda, Azure Functions, Google Cloud Functions – eles vão a zero quando não estão em uso, o que significa que você paga apenas pela computação quando seu código é realmente executado. É uma grande mudança em relação ao paradigma “sempre ligado”.

Para aplicações mais complexas que sempre necessitam de serviços persistentes, mas têm uma demanda flutuante, plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com dimensionamento inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar o tamanho de seus pods de aplicativo com base no uso da CPU ou em métricas personalizadas. Os Cluster Autoscalers podem até adicionar ou remover nós do seu cluster à medida que a demanda muda.

Meu cliente reestruturou partes do seu painel de análise para utilizar Lambda para gerar alguns relatórios solicitados apenas algumas vezes ao dia. Em vez de uma instância EC2 dedicada executando um cron job, uma função Lambda era ativada por um evento S3 (novos arquivos carregados) ou por uma solicitação do API Gateway. As economias foram imediatas e significativas.

3. Dimensione Corretamente Seus Bancos de Dados com o Sem Servidor ou Auto-Escalabilidade

Os bancos de dados são frequentemente problemáticos, pois a persistência de dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções sem servidor ou de auto-escalabilidade que não estavam amplamente disponíveis há poucos anos.

• AWS Aurora Serverless v2 : É uma mudança significativa. Ajusta a capacidade com base no uso real, desde frações de um ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que utiliza. Não é mais necessário prever uma capacidade de pico enquanto a maior parte do tempo opera com carga normal.
• Azure SQL Database Serverless : Semelhante ao Aurora Serverless, se ajusta automaticamente à capacidade de computação e é colocado em pausa quando inativo, gerando economias consideráveis para cargas de trabalho intermitentes.
• DynamoDB On-Demand : Para cargas de trabalho NoSQL, o modo de capacidade sob demanda do DynamoDB significa que você paga por solicitação, sem precisar prever unidades de capacidade de leitura/gravação. Perfeito para modelos de tráfego imprevisíveis.

O painel de análise inicialmente usava uma instância RDS PostgreSQL de grande porte com IOPS previstas. Após a migração para o Aurora Serverless v2, os custos de banco de dados diminuíram em quase **60%**, simplesmente porque não funcionava mais em plena capacidade durante os horários de pico.

4. Limpar Armazenamentos Não Associados e Snapshots

Isso pode parecer trivial, mas é uma fonte constante de desperdício de dinheiro. Ao encerrar uma instância EC2, o volume EBS associado nem sempre é excluído por padrão, especialmente se era um volume não raiz. O mesmo se aplica aos snapshots: eles se acumulam rapidamente e podem se tornar caros.

Exemplo Prático: Encontrar e Excluir Volumes EBS Não Associados (AWS CLI)

É possível usar a AWS CLI para encontrar volumes não associados e removê-los. É uma tarefa comum de limpeza.

# Lista todos os volumes não associados
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table

# Para excluir um volume específico (ATENÇÃO, É IRREVERSÍVEL)
# Substitua 'vol-xxxxxxxxxxxxxxxxx' pelo ID real do volume
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Automatize isso com uma função Lambda programada se você criar e excluir ambientes com frequência. O cliente descobriu vários terabytes de antigos volumes EBS não associados e centenas de snapshots obsoletos. Remover esses volumes permitiu economizar algumas centenas de reais na fatura mensal – não é muito, mas cada pequeno gesto conta.

5. Otimizar os Custos de Rede

As NAT Gateways são ótimas para permitir que instâncias em sub-redes privadas acessem a Internet, mas envolvem custos horários e despesas com o tratamento de dados. Se você tiver várias NAT Gateways em diferentes zonas de disponibilidade, mas apenas uma estiver sendo usada ativamente, está pagando por redundâncias.

• Consolide as NAT Gateways : Se sua arquitetura permitir, consolide para menos NAT Gateways.
• Endpoints VPC : Para acessar serviços AWS como S3 ou DynamoDB a partir de seu VPC, utilize os Endpoints VPC. O tráfego circula de maneira privada dentro da rede AWS, evitando os custos das NAT Gateways e oferecendo maior segurança.

Notamos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles conseguiram consolidar e gerar economias a partir disso, então implementaram os Endpoints VPC para acesso ao S3, o que reduziu os custos de tratamento de dados via NAT Gateway.

Ações a Serem Tomadas para o Próximo Sprint

Não se trata apenas de reduzir custos; trata-se de construir sistemas mais inteligentes e eficientes, intrinsecamente conscientes dos custos. Aqui está o que você pode começar a fazer a partir de hoje:

“`html

1. Audite Regularmente sua Fatura Cloud: Faça disso um hábito. Utilize as ferramentas de gerenciamento de custos do seu fornecedor de nuvem. Não deixe tudo apenas para a contabilidade. Compreenda para onde vai cada real.
2. Rotule Tudo: Isso é inegociável. Rotule os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se podem ser programados para desligamento. Isso facilita bastante a identificação e a automação.
3. Priorize a Programação para Ambientes Não Produtivos: Os ambientes de staging, dev e QA são candidatos ideais para interrupções programadas fora do horário de trabalho. Normalmente, essa é a economia mais simples e rápida.
4. Considere o Serverless para Novas Cargas de Trabalho: Se você está construindo algo novo, especialmente microserviços baseados em eventos ou tarefas em segundo plano, sempre considere primeiro o serverless.
5. Reavalie suas Escolhas de Banco de Dados: Se você tem bancos de dados que funcionam 24/7 com cargas muito variáveis, examine as opções serverless ou de autoescalonamento para sua tecnologia de banco de dados específica.
6. Automatize a Limpeza: Implemente scripts automatizados ou funções serverless para identificar e remover volumes de armazenamento não associados, snapshots antigos e outros recursos órfãos.
7. Eduque sua Equipe: Promova uma cultura de conscientização de custos. Certifique-se de que os desenvolvedores entendam as implicações financeiras de suas escolhas de provisionamento. Não é mais apenas um problema operacional.

Parar as perdas relacionadas aos recursos “sempre ativos” não é uma solução temporária; é uma disciplina contínua. Mas, ao fazer essas mudanças, você não apenas economizará uma quantia significativa de dinheiro para sua empresa, mas também construirá uma infraestrutura mais ágil, resiliente e pronta para o futuro. E, francamente, isso o torna um melhor player no campo tecnológico.

É tudo por mim desta vez. Continue construindo de forma inteligente, e nos veremos na próxima!

“`

🕒 Published: April 5, 2026