Os meus custos de infraestrutura ocultos estavam matando meu orçamento.

Olá a todos, Jules Martin aqui, novamente ativo em agntmax.com. Espero que todos estejam dando o melhor de si por aí. Hoje quero falar sobre algo que tem ocupado minha mente há um tempo, algo que vi emergir em mais conversas e post-mortem de projetos do que gostaria de admitir: a drag invisível dos custos de infraestrutura não otimizados. Todos sabemos que precisamos construir rapidamente, escalar rápido e entregar funcionalidades ontem. Mas muitas vezes, nessa corrida frenética, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços que rodam em modo automático, acumulando faturas que mal olhamos até que a revisão trimestral do orçamento nos atinge como uma tonelada de tijolos.

Portanto, para este artigo, vou mergulhar de cabeça em otimização de custos, mas com um ângulo muito específico e oportuno: como parar de perder dinheiro com recursos “sempre ligados” que deveriam ser “sob demanda” ou “baseados em eventos”. É 2026, pessoal. Os dias de provisionamento de servidores “configura e esquece” ficaram para trás. Se sua conta na nuvem ainda parece um catálogo telefônico, é hora de uma intervenção.

O Assassino Silencioso: Sempre Ligado Quando Deveria Ser Sob Demanda

Sejam realistas. Quando estamos sob pressão para liberar uma nova ferramenta para agentes ou uma melhoria no atendimento ao cliente, o custo geralmente fica em segundo plano em relação à funcionalidade e à velocidade. Provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “só um pouco maior assim, por precaução”. Criamos um banco de dados com IOPS provisionados que poderia gerenciar a internet inteira, apenas para descobrir que permanece em grande parte ocioso durante as horas de menor movimento. Esquecemos de definir políticas de escalabilidade adequadas ou simplesmente deixamos as coisas ativas 24/7 porque, bem, é mais fácil do que pensar nisso.

Eu vi tudo isso de perto alguns meses atrás com o novo painel de análises internas de um cliente. A equipe, abençoados sejam seus corações, construiu um sistema incrível que fornecia aos agentes informações em tempo real sobre as interações com os clientes. Foi um enorme sucesso em termos de desempenho. Mas quando chegou a primeira conta completa da nuvem, o CFO quase teve um ataque cardíaco. Eles tinham provisionado um robusto cluster EKS, algumas instâncias RDS de alta gama e uma miríade de funções Lambda com alocações generosas de memória, todas em execução sem parar. A ironia? O painel era usado principalmente pelos agentes durante o horário comercial, das 9:00 às 17:00, de segunda a sexta. Fora desse horário, era uma cidade fantasma.

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

Identifique os Culpados: Para Onde Realmente Vai Seu Dinheiro

Antes de poder resolver qualquer coisa, você precisa saber o que está quebrado. A maioria dos fornecedores de nuvem oferece ferramentas para ajudá-lo a visualizar seus gastos, e você absolutamente deve 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 Costumes Suspeitos

• Instâncias de Computação (EC2, VMs): Estas são frequentemente as maiores transgressões. Estão superdimensionadas? Estão rodando quando não deveriam? Você está usando a família de instâncias correta para sua carga de trabalho?
• Bancos de Dados (RDS, Azure SQL, Cloud SQL): Semelhante às instâncias de computação, os bancos de dados podem ser superprovisionados para IOPS, CPU ou memória. Muitos agora oferecem opções sem servidor que escalonam até zero ou quase-zero quando estão ociosos.
• Armazenamento (volumes EBS, discos não conectados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado pendente? Acontece mais frequentemente do que você pensa.
• Rede (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem te pegar de surpresa, especialmente entre regiões. Os NAT Gateways também têm uma taxa por hora, mesmo que não estejam fazendo nada.
• Serviços Subutilizados: Você está pagando por um cache Redis dedicado que recebe apenas alguns acessos por dia? Um cluster Kafka gerenciado para um draman de mensagens?

Meu cliente da história do painel de análise começou a olhar para o AWS Cost Explorer. Os itens mais caros eram, previsivelmente, **EC2** e **RDS**. Eles também encontraram alguns volumes **EBS** anexados a instâncias terminadas e um **NAT Gateway** em uma **VPC** que não estava mais sendo utilizada ativamente para o tráfego de produção. Coisas pequenas, mas que somam.

Estratégias para Transformar Always-On em On-Demand (ou Fora do Pico)

Ok, então você identificou as áreas onde está gastando demais. Agora começa a parte divertida: resolver o problema. O **objetivo** não é apenas economizar dinheiro, mas construir um sistema mais resiliente e eficiente que consome recursos apenas quando realmente precisa.

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

Este é provavelmente o fruto mais acessível para muitas aplicações. Se suas ferramentas internas ou ambientes de **staging** são utilizados apenas durante o horário comercial, não há razão para que estejam ativos 24/7. A maioria dos provedores de **cloud** oferece maneiras nativas de programar os ciclos de ativação das instâncias, ou você pode criar um sistema próprio com funções **serverless**.

Exemplo Prático: **AWS EC2 Scheduler** com **Lambda**

Você pode criar uma simples função **Lambda** ativada por eventos **CloudWatch** (expressões CRON) para parar e iniciar as instâncias **EC2** com base em 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')
 
 # Defina as tags para identificar as instâncias a serem paradas/iniciadas
 # Por exemplo, 'Schedule': 'business-hours'
 
 # Obtenha 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 para parar.")
 
 # --- Lógica semelhante para iniciar as instâncias em outro horário ---
 # Você teria outra função **Lambda**/**Event CloudWatch** para iniciar,
 # ou combinar a lógica com uma tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Programação das instâncias **EC2** concluída.'
 }

Você configuraria 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 por si só pode reduzir os custos de computação em mais de **70%** para esses recursos específicos.

2. Adote Serverless e Orquestração de Containers

Se a sua carga de trabalho é realmente esporádica ou baseada em eventos, **serverless** é seu melhor amigo. **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 pelo cálculo quando seu código está realmente em execução. Isso representa uma grande mudança em relação ao paradigma “always-on”.

Para aplicações mais complexas que ainda precisam de serviços persistentes, mas com demanda flutuante, plataformas de orquestração de containers, como **Kubernetes** (**EKS**, **AKS**, **GKE**), combinadas com **autoscaling** inteligente, são poderosas. Os **Horizontal Pod Autoscalers** (**HPA**) podem escalar os pods da sua aplicação para cima e para baixo com base no uso da **CPU** ou em métricas personalizadas. Os **Cluster Autoscalers** também podem adicionar ou remover nós do seu cluster à medida que a demanda muda.

Meu cliente reestruturou partes de seu painel de análise para usar **Lambda** para gerar determinados relatórios que são solicitados apenas algumas vezes ao dia. Em vez de uma instância **EC2** dedicada que executava um **cron job**, uma função **Lambda** era ativada por um evento **S3** (novos dados enviados) ou uma solicitação de **API Gateway**. As economias de custos foram imediatas e significativas.

3. Dimensione Corretamente seus Bancos de Dados com Serverless ou Auto-Scaling

Os bancos de dados costumam ser um problema delicado porque a persistência dos dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções **serverless** ou de **auto-scaling** que não estavam amplamente disponíveis há alguns anos.

• AWS Aurora Serverless v2: Isso representa uma mudança significativa. Escala a capacidade com base no uso real, de frações de uma ACU (Aurora Capacity Unit) até centenas, e você paga apenas pelo que usa. Nada mais de provisionamento para capacidade de pico quando, na maior parte do tempo, opera em carga base.
• Azure SQL Database Serverless: Semelhante ao Aurora Serverless, escala automaticamente o processamento e para quando está inativo, economizando custos significativos para cargas de trabalho intermitentes.
• DynamoDB On-Demand: Para cargas de trabalho NoSQL, o modo de capacidade on-demand do DynamoDB significa que você paga por solicitação, sem a necessidade de provisionar unidades de capacidade de leitura/gravação. Perfeito para padrões de tráfego imprevisíveis.

O painel de análise inicialmente utilizava uma grande instância RDS PostgreSQL com IOPS provisionados. Após a migração para Aurora Serverless v2, seus custos com o banco de dados diminuíram em quase **60%**, simplesmente porque não estava mais em execução em plena capacidade durante as horas não-pico.

4. Limpe o Armazenamento Desconectado e os Snapshots

Isso parece básico, mas é uma fonte constante de dinheiro desperdiçado. Quando você encerra uma instância EC2, seu volume EBS associado nem sempre é eliminado por padrão, especialmente se era um volume não root. O mesmo vale para os snapshots – eles se acumulam rapidamente e podem se tornar caros.

Exemplo Prático: Encontrar e Deletar Volumes EBS Desconectados (AWS CLI)

Você pode usar a AWS CLI para encontrar os volumes desconectados e deletá-los. Essa é 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 eliminar um volume específico (TENHA CUIDADO, ISSO É IRREVERSÍVEL)
# Substitua 'vol-xxxxxxxxxxxxxxxxx' pelo ID do volume real
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Automatize isso com uma função Lambda programada se você frequentemente criar e destruir ambientes. O cliente encontrou vários terabytes de antigos volumes EBS não associados e centenas de snapshots obsoletos. Eliminar esses volumes economizou algumas centenas de dólares na conta mensal – não é muito, mas toda pequena economia conta.

5. Otimize os Custos de Rede

Os NAT Gateway são ótimos para permitir que instâncias em sub-redes privadas acessem a Internet, mas envolvem um custo por hora e um custo de processamento de dados. Se você tiver vários NAT Gateway em diferentes zonas de disponibilidade, mas apenas um estiver em uso ativo, você está pagando pelos redundantes.

• Consolide os NAT Gateway: Se a sua arquitetura permitir, consolide para menos NAT Gateway.
• VPC Endpoints: Para acessar os serviços AWS, como S3 ou DynamoDB, de dentro da sua VPC, use os VPC Endpoints. O tráfego flui privadamente dentro da rede AWS, evitando os custos do NAT Gateway e oferecendo maior segurança.

Descobrimos que o cliente tinha um NAT Gateway em cada AZ, mesmo que sua aplicação principal rodasse apenas em duas. Eles conseguiram consolidar e economizar um pouco lá, e em seguida implementaram os VPC Endpoints para acesso ao S3, o que reduziu os custos de processamento de dados através do NAT Gateway.

Considerações Práticas 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 hoje:

1. Controle Regularmente Sua Fatura na Nuvem: Faça disso um hábito. Utilize as ferramentas de gerenciamento de custos do seu fornecedor de nuvem. Não limite isso apenas às finanças. Entenda para onde vai cada dólar.
2. Rotule Tudo: Isso é inegociável. Rotule os recursos por projeto, proprietário, ambiente (desenvolvimento, teste, produção) e se podem ser programados para desligamento. Isso torna a identificação e a automação infinitamente mais simples.
3. Priorize a Programação dos Ambientes Não Produtivos: Os ambientes de teste, desenvolvimento, e QA são candidatos ideais para desligamentos programados fora do horário comercial. Normalmente, essa é a ganha mais fácil e rápida.
4. Considere o Serverless para Novas Cargas de Trabalho: Se você está construindo algo novo, especialmente microserviços orientados a eventos ou tarefas em segundo plano, considere sempre primeiro o serverless.
5. Revise as Opções de Banco de Dados: Se você tem bancos de dados funcionando 24 horas por dia, 7 dias por semana, com cargas altamente variáveis, investigue opções serverless ou de escalonamento automático para a sua tecnologia de banco de dados específica.
6. Automatize a Limpeza: Implemente scripts automatizados ou funções serverless para identificar e eliminar volumes de armazenamento não associados, snapshots antigas e outros recursos órfãos.
7. Capacite Sua Equipe: Promova uma cultura de conscientização de custos. Certifique-se de que os desenvolvedores compreendam as implicações de custo de suas escolhas de provisionamento. Não é mais apenas um problema operacional.

Prevenir o desperdício de recursos “sempre ativos” não é uma solução única; é 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 à prova de futuro. E, francamente, isso simplesmente o torna um agente melhor no jogo tecnológico.

Isso é tudo por agora. Continue construindo de forma inteligente e até a próxima!

🕒 Published: April 5, 2026