Os meus custos de infraestrutura ocultos destruíram o meu orçamento.

Olá a todos, Jules Martin aqui, de volta ao agntmax.com. Espero que todos estejam bem. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que vi surgir em mais conversas e post-mortems de projetos do que quero admitir: a retirada invisível dos custos de infraestrutura não otimizados. Todos nós sabemos que precisamos construir rapidamente, escalar rápido e entregar funcionalidades ontem. Mas, muitas vezes, nessa correria, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços funcionando automaticamente, acumulando faturas que mal olhamos antes que a revisão orçamentária trimestral caia como um tonelada de tijolos.

Portanto, para este artigo, vou me aprofundar naotimização de custos, mas com uma perspectiva muito específica e oportuna: como parar de perder dinheiro em recursos “sempre ativos” que deveriam estar “sob demanda” ou “ativados por eventos”. Estamos em 2026, pessoal. Os dias de fornecer servidores personalizados acabaram. Se a sua fatura de nuvem ainda é parecida com uma lista telefônica, é hora de intervir.

O Assassino Silencioso: Sempre Ativo Quando Deveria Estar 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. Provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior para segurança”. Lançamos um banco de dados com IOPS provisionadas que poderiam gerenciar toda a Internet, apenas para ficar principalmente inativo durante as horas de baixo tráfego. Esquecemos de configurar políticas de escalonamento apropriadas ou simplesmente deixamos as coisas funcionando 24/7 porque, bem, é mais fácil do que se preocupar.

Eu vi isso com meus próprios olhos alguns meses atrás 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 panorâmicas 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 ataque cardíaco. Eles haviam provisionado um cluster EKS robusto, algumas instâncias RDS de alta qualidade e uma infinidade de funções Lambda com alocações generosas de memória, todas funcionando sem interrupção. O golpe final? O painel era usado principalmente pelos agentes durante o horário de trabalho, das 9h às 17h, de segunda a sexta. Fora isso, era uma cidade fantasma.

Estavam gastando 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.

Identifique os Culpados: Para Onde Vai Realmente 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ê definitivamente deve usá-las. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports – não são apenas para as finanças. Eles são sua primeira linha de defesa.

Os Costumes Suspeitos

• Instância de Cálculo (EC2, VMs): Frequentemente, 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?
• 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 serverless que reduzem a zero ou a um custo próximo de zero quando estão inativos.
• Armazenamento (volumes EBS, discos não anexados): Você já iniciou uma instância, a desligou, mas deixou o volume de armazenamento associado por aí? Isso acontece mais frequentemente do que você imagina.
• Networking (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem te surpreender, especialmente entre regiões. Os NAT Gateways também têm um custo horário, mesmo que não estejam fazendo 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 conjunto de mensagens?

Meu cliente da história do painel de análises começou analisando seu AWS Cost Explorer. Os maiores custos eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS associados a instâncias encerradas e uma NAT Gateway em uma VPC que não estava mais sendo utilizada para tráfego de produção. Pequenas coisas, mas que somam.

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

Está bem, você identificou as áreas onde está gastando demais. Vamos passar para a parte divertida: consertar isso. 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 e a Parada das Instâncias

Este é provavelmente o fruto mais fácil para muitas aplicações. Se suas ferramentas internas ou seus ambientes de staging são usados apenas durante o horário comercial, não há razão para funcionarem 24/7. A maioria dos provedores de nuvem oferece maneiras nativas de programar os ciclos de alimentação das instâncias, ou você pode criar sua própria solução com funções serverless.

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 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 tags para identificar as instâncias a serem paradas/iniciadas
 # Por exemplo, 'Schedule': 'business-hours'
 
 # Recupere 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 essa 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 Serverless e a Orquestração de Containers

Se sua carga de trabalho é realmente esporádica ou ativada por eventos, o serverless é 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 pelo cálculo quando seu código está realmente em execução. É uma grande mudança em relação ao paradigma “sempre ligado”.

Para aplicações mais complexas que sempre requerem serviços persistentes, mas têm uma demanda variável, as plataformas de orquestração de containers como Kubernetes (EKS, AKS, GKE) juntamente com escalabilidade inteligente são poderosas. Os Autoscaladores de Pod Horizontal (HPA) podem variar o tamanho de seus pods de aplicação com base no uso da CPU ou em métricas personalizadas. Os Autoscaladores de Cluster também podem adicionar ou remover nós do seu cluster à medida que a demanda muda.

Meu cliente refez algumas partes do seu painel de análises para usar Lambda para gerar alguns relatórios que eram 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 arquivos carregados) ou por uma solicitação do API Gateway. As economias foram imediatas e significativas.

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

Os bancos de dados costumam ser problemáticos, pois a persistência dos dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções serverless ou de auto-escalonamento que não estavam amplamente disponíveis há apenas alguns anos.

• AWS Aurora Serverless v2 : É uma mudança significativa. Ajusta a capacidade com base no uso real, variando de frações de um ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que utiliza. Não é mais necessário fazer provisioning para uma capacidade de pico quando a maior parte do tempo você opera com carga base.
• Azure SQL Database Serverless : Semelhante ao Aurora Serverless, adapta automaticamente a capacidade de cálculo e entra em pausa quando está inativo, realizando 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 cada solicitação, sem precisar fazer provisioning de unidades de capacidade de leitura/escrita. Perfeito para modelos de tráfego imprevisíveis.

O dashboard analítico usava inicialmente uma grande instância RDS PostgreSQL com IOPS provisionados. Após a migração para o Aurora Serverless v2, seus custos de banco de dados diminuíram em quase **60%**, simplesmente porque não funcionava mais em plena capacidade durante as horas de baixo tráfego.

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ê encerra 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 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 remover um volume específico (CUIDADO, É 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ê cria e remove frequentemente ambientes. O cliente descobriu vários terabytes de antigos volumes EBS não anexados e centenas de snapshots obsoletos. Removê-los permitiu economizar algumas centenas de dólares em sua conta mensal – não é uma enormidade, mas cada pequeno gesto conta.

5. Otimize os Custos de Rede

As NAT Gateways são fantásticas para permitir que as instâncias nas sub-redes privadas acessem a Internet, mas envolvem custos por hora e despesas com processamento de dados. Se você tiver várias NAT Gateways em diferentes zonas de disponibilidade, mas apenas uma estiver sendo utilizada ativamente, você pagará pelas redundantes.

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

Constatamos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles conseguiram consolidar e realizar economias como resultado, e depois implementaram os Endpoints VPC para acesso ao S3, o que reduziu os custos de processamento de dados através da 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:

1. Audite Regularmente sua Conta na Nuvem: Faça disso um hábito. Use as ferramentas de gerenciamento de custos do seu provedor de nuvem. Não delegue isso apenas às finanças. Compreenda para onde vai cada dólar.
2. Rotule Tudo: Isso não é negociável. Rotule os recursos por projeto, proprietário, ambiente (desenvolvimento, staging, produção) e se podem ser programados para desligamento. Isso facilita enormemente a identificação e a automação.
3. Priorize o Desligamento de Ambientes Não Produtivos: Os ambientes de staging, desenvolvimento, QA são candidatos ideais para desligamentos programados fora do horário comercial. Este é geralmente o economia mais fácil 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 o serverless como a primeira opção.
5. Reavalie Suas Escolhas de Banco de Dados: Se você tiver bancos de dados que operam 24/7 com cargas muito variáveis, explore 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 anexados, snapshots antigos e outros recursos órfãos.
7. Eduque sua Equipe: Promova uma cultura de conscientização sobre custos. Certifique-se de que os desenvolvedores compreendam as implicações financeiras de suas escolhas de provisionamento. Não é mais apenas um problema operacional.

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

É tudo para mim desta vez. Continue construindo de forma inteligente e nos vemos na próxima!

🕒 Published: April 5, 2026