Oi, pessoal, Jules Martin aqui, de volta no agntmax.com. Espero que todos estejam arrasando por aí. Hoje, quero falar sobre algo que tem me incomodado ultimamente, algo que tenho visto aparecer em mais conversas e pós-mortem de projetos do que eu gostaria de admitir: o arrasto invisível dos custos de infraestrutura não otimizados. Todos sabemos que precisamos construir rápido, escalar rapidamente e entregar funcionalidades ontem. Mas muitas vezes, nesse frenesi, deixamos para trás uma trilha de recursos esquecidos, instâncias superdimensionadas e serviços funcionando no piloto automático, acumulando contas que mal olhamos até a revisão orçamentária trimestral chegar como um caminhão de tijolos.
Então, para este texto, estou mergulhando de cabeça na otimização de custos, mas com uma abordagem muito específica e oportuna: como parar de perder dinheiro em recursos “sempre ativos” que deveriam ser “sob demanda” ou “impulsionados por eventos”. Estamos em 2026, pessoal. Os dias de provisionamento de servidores no modo configurar-e-esquecer já se foram. Se sua conta de nuvem ainda parece um catálogo telefônico, é hora de uma intervenção.
O Assassino Silencioso: Sempre Ativo Quando Deveria Ser Sob Demanda
Sendo realistas. Quando estamos sob pressão para lançar uma nova ferramenta voltada para agentes ou uma melhoria no atendimento ao cliente, o custo geralmente fica em segundo plano em relação à funcionalidade e velocidade. Nós provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior, só por precaução”. Criamos um banco de dados com IOPS provisionados que poderia lidar com toda a internet, apenas para ele ficar principalmente inativo durante as horas de baixo tráfego. Esquecemos de configurar políticas de escalonamento adequadas ou simplesmente deixamos as coisas rodando 24/7 porque, bem, é mais fácil do que pensar sobre isso.
Eu vi isso de perto há alguns meses com o novo painel de análises internas de um cliente. A equipe, que merece todo o reconhecimento, construiu um sistema maravilhoso que oferecia insights em tempo real sobre as interações com os clientes. Foi uma grande vitória em termos de desempenho. Mas quando a primeira conta total da nuvem chegou, o CFO quase teve um ataque cardíaco. Eles haviam provisionado um robusto cluster EKS, alguns instâncias RDS de alta performance e uma série de funções Lambda com alocações generosas de memória, tudo funcionando sem parar. O detalhe? O painel era usado principalmente por agentes durante o horário comercial, das 9h às 17h, de segunda a sexta. Fora isso, era uma cidade fantasma.
Eles estavam pagando por capacidade de nível empresarial para um sistema que estava efetivamente inativo por 70% da semana. Isso é como comprar um carro de Fórmula 1 para ir ao supermercado uma vez por semana.
Identifique os Culpados: Para Onde Seu Dinheiro Está Indo Realmente
Antes que você possa consertar qualquer coisa, precisa saber o que está quebrado. A maioria dos provedores 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 – esses não são apenas para finanças. Eles são sua primeira linha de defesa.
Os Suspeitos Costumeiros
- Instâncias de Computação (EC2, VMs): Esses são frequentemente os maiores infratores. Elas estão superdimensionadas? Estão rodando quando não precisam? Você está usando a família de instâncias correta para sua carga de trabalho?
- Bancos de Dados (RDS, Azure SQL, Cloud SQL): Semelhante a computação, os bancos de dados podem ser superprovisionados em IOPS, CPU ou memória. Muitos oferecem opções serverless que agora escalam para zero ou custo quase zero quando inativos.
- Armazenamento (volumes EBS, discos não anexados): Já lançou uma instância, a terminou, mas deixou o volume de armazenamento associado por perto? Acontece mais do que você imagina.
- Rede (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem surpreendê-lo, especialmente entre regiões. NAT Gateways também têm uma cobrança por hora, mesmo que não estejam fazendo nada.
- Serviços Subutilizados: Você está pagando por um cache Redis dedicado que só recebe algumas solicitações por dia? Um cluster Kafka gerenciado para um fluxo de mensagens?
Meu cliente da história do painel de análises começou analisando seu AWS Cost Explorer. Os principais itens de linha eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS anexados a instâncias encerradas e um NAT Gateway em uma VPC que já não estava sendo usada ativamente para tráfego de produção. Coisas pequenas, mas que somam.
Estratégias para Transformar Sempre Ativo em Sob Demanda (ou Fora do Pico)
Certo, então você identificou as áreas onde está gastando demais. Agora vem 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 deles.
1. Programar Início/Parada de Instâncias
Esta é provavelmente a solução mais simples para muitos aplicativos. Se suas ferramentas internas ou ambientes de teste são usados apenas durante o horário comercial, não há razão para estarem funcionando 24/7. A maioria dos provedores de nuvem oferece maneiras nativas de programar ciclos de energia das instâncias, ou você pode criar a sua com funções serverless.
Exemplo Prático: AWS EC2 Scheduler com Lambda
Você pode criar uma simples função Lambda 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 as tags para identificar instâncias para parar/iniciar
# 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 instâncias: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("Nenhuma instância para parar.")
# --- Lógica semelhante para iniciar instâncias em um horário diferente ---
# Você teria outro Lambda/Eventos do CloudWatch para iniciar,
# ou poderia combinar lógica com uma tag 'start'.
return {
'statusCode': 200,
'body': 'Programação de instâncias EC2 concluída.'
}
Você iria configurar duas regras de Eventos do CloudWatch: uma para acionar esta Lambda, por exemplo, às 18h UTC para parar instâncias, e outra às 7h UTC para iniciá-las. Isso sozinho pode cortar os custos de computação em mais de 70% para esses recursos específicos.
2. Abrace Serverless e Orquestração de Contêineres
Se sua carga de trabalho é realmente esporádica ou impulsionada por eventos, o serverless é seu melhor amigo. AWS Lambda, Azure Functions, Google Cloud Functions – eles escalam para zero quando não estão em uso, ou seja, você paga apenas pela computação quando seu código está realmente em execução. Isso é uma mudança significativa do paradigma “sempre ativo”.
Para aplicativos mais complexos que ainda precisam de serviços persistentes, mas com demanda flutuante, plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com autoscaling inteligente são poderosas. Horizontal Pod Autoscalers (HPA) podem escalar seus pods de aplicação para cima e para baixo com base na utilização de CPU ou métricas personalizadas. Cluster Autoscalers podem até adicionar ou remover nós do seu cluster conforme a demanda muda.
Meu cliente reestruturou partes de seu painel de análises para usar Lambda na geração de certos relatórios que eram solicitados apenas algumas vezes ao dia. Em vez de uma instância EC2 dedicada rodando um cron job, uma função Lambda foi acionada por um evento S3 (novo dado enviado) ou um pedido do API Gateway. As economias de custos foram imediatas e significativas.
3. Ajuste seus Bancos de Dados com Serverless ou Auto-Scaling
Bancos de dados costumam ser um desafio porque a persistência de 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: Esta é uma mudança significativa. Ele escala 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 usar. Chega de provisionar para capacidade pico quando a maior parte do tempo está operando em carga base.
- Azure SQL Database Serverless: Semelhante ao Aurora Serverless, escala automaticamente a computação e pausa quando inativo, economizando custos significativos 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/gravação. Perfeito para padrões de tráfego imprevisíveis.
O painel de análises originalmente usava uma grande instância RDS PostgreSQL com IOPS provisionados. Após a migração para Aurora Serverless v2, seus custos com banco de dados caíram quase 60%, simplesmente porque não estava mais funcionando em alta capacidade durante as horas de inatividade.
4. Limpe Armazenamento Não Anexado e Snapshots
Isso parece básico, mas é uma fonte constante de desperdício de dinheiro. Quando você encerra uma instância EC2, seu volume EBS associado nem sempre é excluído por padrão, especialmente se era um volume não-root. O mesmo vale para snapshots – eles se acumulam rapidamente e podem se tornar caros.
Exemplo Prático: Encontrar e Excluir Volumes EBS Não Anexados (AWS CLI)
Você pode usar a AWS CLI para encontrar volumes não anexados e excluí-los. Essa é uma tarefa comum de limpeza.
# Liste todos os volumes não anexados
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Para deletar um volume específico (TENHA CUIDADO, ISSO É 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ê frequentemente criar e deletar ambientes. O cliente encontrou vários terabytes de volumes EBS antigos e não anexados e centenas de snapshots desatualizados. Deletá-los economizou algumas centenas de dólares na conta mensal – não é muito, mas cada centavo conta.
5. Otimize Custos de Rede
Os NAT Gateways são fantásticos para permitir que instâncias em sub-redes privadas acessem a internet, mas geram uma cobrança horária e uma cobrança de processamento de dados. Se você tiver vários NAT Gateways em diferentes zonas de disponibilidade, mas apenas um está sendo usado ativamente, você está pagando por aqueles que são redundantes.
- Consolide NAT Gateways: Se a sua arquitetura permitir, consolide em menos NAT Gateways.
- Pontos de Acesso VPC: Para acessar serviços AWS como S3 ou DynamoDB de dentro da sua VPC, use os Pontos de Acesso VPC. O tráfego flui de forma privada dentro da rede AWS, evitando custos de NAT Gateway e oferecendo melhor segurança.
Descobrimos que o cliente tinha um NAT Gateway em cada AZ, mesmo que seu aplicativo principal só rodasse em duas. Eles conseguiram consolidar e economizar um pouco ali, e depois implementaram os Pontos de Acesso VPC para acesso ao S3, o que reduziu os custos de processamento de dados através do NAT Gateway.
Lições Práticas para seu Próximo Sprint
Isso não é apenas sobre cortar custos; é sobre construir sistemas mais inteligentes e eficientes que são intrinsecamente conscientes de custo. Aqui está o que você pode começar a fazer hoje:
- Audite Sua Conta de Nuvem Regularmente: Faça disso um hábito. Use as ferramentas de gerenciamento de custos do seu provedor de nuvem. Não entregue apenas para a área financeira. Entenda para onde cada dólar está indo.
- Marque Tudo: Isso é inegociável. Marque os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se eles podem ser programados para desligamento. Isso torna a identificação e automação infinitamente mais fáceis.
- Priorize o Agendamento para Ambientes Não Produtivos: Ambientes de staging, dev e QA são candidatos ideais para desligamentos programados fora do horário comercial. Isso geralmente é a vitória mais fácil e rápida.
- Avalie Serverless para Novas Cargas de Trabalho: Se você está construindo algo novo, especialmente microsserviços orientados a eventos ou tarefas em segundo plano, sempre considere serverless primeiro.
- Revise as Escolhas de Banco de Dados: Se você tem bancos de dados funcionando 24/7 com cargas altamente variáveis, investigue opções serverless ou de autoescala para a tecnologia de banco de dados específica que você está utilizando.
- Automatize a Limpeza: Implemente scripts automatizados ou funções serverless para identificar e deletar volumes de armazenamento não anexados, snapshots antigos e outros recursos órfãos.
- Eduque sua Equipe: Promova uma cultura de conscientização sobre custos. Certifique-se de que os desenvolvedores entendam as implicações de custo de suas escolhas de provisionamento. Não é mais apenas um problema de operações.
Parar o vazamento de recursos “sempre ligados” 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 a sua empresa, mas também construirá uma infraestrutura mais ágil, resiliente e à prova de futuro. E, francamente, isso só te torna um agente melhor no jogo da tecnologia.
Isso é tudo por minha parte desta vez. Continue construindo de forma inteligente, e nos vemos na próxima!
🕒 Published: