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

Olá a todos, Jules Martin aqui, novamente no agntmax.com. Espero que todos vocês estejam bem. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que vi emergir em mais conversas e post-mortem de projetos do que gostaria de admitir: o consumo invisível de custos de infraestrutura não otimizados. Sabemos que precisamos construir rápido, escalar rapidamente e entregar funcionalidades ontem. Mas muitas vezes, nessa pressa, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços em modo piloto automático, acumulando faturas que mal conseguimos dar uma olhada antes que a revisão trimestral do orçamento caia como uma tonelada de tijolos.

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

O Assassinato Silencioso: Sempre Ligado Quando Deveria Ser Sob Demanda

Sejamos 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 é deixado em segundo plano em relação à funcionalidade e à velocidade. Provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior por segurança.” Lançamos um banco de dados com IOPS provisionados que poderiam gerenciar toda a internet, apenas para permanecer principalmente ocioso durante as horas de inatividade. Esquecemos de configurar políticas de escalonamento apropriadas, ou simplesmente deixamos as coisas funcionando 24/7 porque, bem, é mais fácil não se preocupar com isso.

Eu vi isso com meus próprios olhos há alguns meses com o novo painel de análises internas de um cliente. A equipe, que Deus os abençoe, havia construído um sistema fantástico que fornecia aos agentes visões em tempo real das interações com os clientes. Foi uma grande vitória para o desempenho. Mas quando a primeira fatura completa da nuvem chegou, o diretor financeiro quase teve um ataque cardíaco. Eles tinham 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 funcionando sem interrupções. A reviravolta? O painel era principalmente utilizado pelos agentes durante o horário comercial, das 9 às 17, de segunda a sexta. Fora disso, 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 consertar qualquer coisa, você precisa saber o que está quebrado. A maioria dos provedores 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 Suspeitos de Sempre

• Instâncias de Cálculo (EC2, VMs): Elas costumam ser os principais culpados. Estão superdimensionadas? Estão funcionando quando não deveriam? Você está usando a família de instâncias certa para sua carga de trabalho?
• Banco de Dados (RDS, Azure SQL, Cloud SQL): Assim como no cálculo, os bancos de dados podem ser superprovisionados para IOPS, CPU ou memória. Muitos agora oferecem opções sem servidor que se reduzem a zero ou a um custo próximo do zero quando estão inativos.
• Armazenamento (volumes EBS, discos não anexados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado por aí? Acontece com mais frequência do que você pensa.
• Networking (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 por hora, mesmo que não façam nada.
• Serviços Subutilizados: Você está pagando por um cache Redis dedicado que tem apenas algumas acessos por dia? Um cluster Kafka gerenciado para um fluxo de mensagens?

Meu cliente do relato do painel de análises começou olhando seu AWS Cost Explorer. Os maiores gastos 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 era mais utilizada para o tráfego de produção. Pequenas coisas, mas que se acumulam.

Estratégias para Transformar Sempre Ligado em Sob Demanda (ou Fora de Ponta)

Certo, você identificou as áreas onde está gastando demais. Vamos para a parte divertida: consertar isso. O objetivo não é apenas economizar dinheiro, mas construir um sistema mais resistente e eficiente que consome recursos apenas quando realmente precisa.

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

Provavelmente é a fruta 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/7. A maioria dos fornecedores de nuvem oferece maneiras nativas de agendar os ciclos de alimentação das instâncias, ou você pode criar sua própria solução com funções sem servidor.

Exemplo Prático: Agendador EC2 AWS com Lambda

Você pode criar uma função Lambda simples ativada por eventos do CloudWatch (expressões CRON) para parar e iniciar 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 tags para identificar as instâncias a serem paradas/iniciadas
 # 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 para parar.")
 
 # --- Lógica similar para iniciar as instâncias em outro momento ---
 # Você teria outra Lambda/Event CloudWatch para iniciar,
 # ou combinar a lógica com uma tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Agendamento das instâncias EC2 concluído.'
 }

Você deve configurar duas regras de eventos do CloudWatch: uma para ativar esta Lambda, digamos, às 18:00 UTC para parar as instâncias, e outra às 7:00 UTC para iniciá-las. Isso pode, por si só, 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 – reduzem 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 enorme mudança em relação ao paradigma “sempre ligado”.

Para aplicações mais complexas que ainda requerem serviços persistentes, mas têm uma demanda flutuante, as plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com escalabilidade inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar o tamanho de seus pods de aplicação 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 refez algumas partes do seu painel de análise para usar Lambda para gerar alguns relatórios que eram 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 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-Escalonamento

Os bancos de dados costumam ser 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-escalonamento que não estavam amplamente disponíveis há alguns anos.

• AWS Aurora Serverless v2: É uma mudança significativa. Ajusta a capacidade com base no uso real, de frações de um ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que utiliza. Não é mais necessário provisionar para uma capacidade máxima enquanto a maior parte do tempo funciona a carga base.
• Azure SQL Database Serverless: Semelhante ao Aurora Serverless, ajusta automaticamente a capacidade de computação e entra em pausa quando está inativo, permitindo economias significativas 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 provisionar unidades de capacidade de leitura/escrita. Perfeito para modelos de tráfego imprevisíveis.

“`html

O painel de análise utilizava inicialmente uma instância RDS PostgreSQL grande com IOPS provisionadas. Após a migração para o Aurora Serverless v2, os custos de banco de dados deles diminuíram em quase **60%**, simplesmente porque não funcionava mais a pleno vapor durante as horas de baixa atividade.

4. Limpe os Armazenamentos Não Anexados e os Snapshots

Isso pode parecer trivial, mas é uma fonte constante de desperdício de dinheiro. Quando você termina uma instância EC2, seu volume EBS associado não é sempre eliminado por padrão, especialmente se se tratava de um volume não raiz. O mesmo vale para os snapshots – eles se acumulam rapidamente e podem se tornar caros.

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

Você pode usar a AWS CLI para encontrar volumes não anexados e removê-los. É uma tarefa de limpeza comum.

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

# Para eliminar um volume específico (TENHA CUIDADO, É 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ê cria e remove ambientes frequentemente. O cliente descobriu vários terabytes de antigos volumes EBS não anexados e centenas de snapshots obsoletos. A remoção deles permitiu economizar algumas centenas de dólares na fatura mensal – não é muito, mas cada pequeno gesto conta.

5. Otimize os Custos de Rede

Os NAT Gateways são fantásticos para permitir que instâncias em sub-redes privadas acessem a Internet, mas implicam custos por hora e custos pelo tratamento de dados. Se você tem vários NAT Gateways em diferentes zonas de disponibilidade, mas apenas um está sendo usado ativamente, você está pagando por redundâncias.

• Consolide os NAT Gateways: Se sua arquitetura permitir, consolide para menos NAT Gateways.
• Endpoints VPC: Para acessar serviços da AWS como S3 ou DynamoDB do seu VPC, utilize os Endpoints VPC. O tráfego se move de forma privada dentro da rede AWS, evitando os custos dos NAT Gateways e oferecendo melhor segurança.

Notamos que o cliente tinha um NAT Gateway em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles conseguiram consolidar e economizar dessa forma, e depois implementaram os Endpoints VPC para acesso ao S3, reduzindo os custos de tratamento de dados através do NAT Gateway.

Ações a Tomar para o Seu 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:

1. Audite Regularmente Sua Fatura na Nuvem: Torne isso um hábito. Utilize as ferramentas de gestão de custos do seu fornecedor de nuvem. Não deixe isso apenas nas mãos das finanças. Entenda onde vai cada dólar.
2. Rotule Tudo: Isso não é negociável. Rotule os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se podem ser programados para desligamento. Isso torna muito mais fácil a identificação e a automação.
3. Priorize a Programação para Ambientes Não Produtivos: Ambientes de staging, dev, QA são candidatos ideais para paradas programadas fora do horário comercial. Este é geralmente o ganho mais fácil e rápido.
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 o serverless primeiro.
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 autoescala 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 anexados, snapshots desatualizados e outros recursos órfãos.
7. Eduque Sua Equipe: Promova uma cultura de conscientização de custos. Certifique-se de que os desenvolvedores compreendam as implicações financeiras de suas escolhas de provisionamento. Não é mais um problema apenas das operações.

“`

Reduzir as perdas relacionadas aos recursos “sempre ativos” não é uma solução única; é uma disciplina contínua. Mas ao fazer essas mudanças, você não só economizará uma quantia significativa de dinheiro para a sua empresa, mas também construirá uma infraestrutura mais ágil, resiliente e pronta para o futuro. E francamente, isso o torna um ator melhor no setor de tecnologia.

É tudo por minha parte desta vez. Continue construindo de forma inteligente, e nos vemos na próxima!

🕒 Published: April 5, 2026