Olá a todos, Jules Martin aqui, novamente em agntmax.com. Espero que todos estejam bem. Hoje quero falar sobre algo que tem me preocupado recentemente, algo que vi surgir em mais conversas e pós-mortem de projetos do que gostaria de admitir: a retirada invisível dos custos de infraestrutura não otimizados. Sabemos que precisamos construir rapidamente, adaptar-se rapidamente e entregar funcionalidades como se fosse ontem. Mas muitas vezes, nessa pressa, deixamos para trás uma trilha de recursos esquecidos, de instâncias superdimensionadas e de serviços funcionando automaticamente, acumulando faturas que mal damos uma olhada antes que a revisão orçamentária trimestral chegue como um monte de tijolos.
Então, para este artigo, vou mergulhar de cabeça na 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 “ativados por eventos”. Estamos em 2026, pessoal. Os dias de fornecimento de servidores sob consumo acabaram. Se sua fatura na nuvem ainda parece um catálogo de telefones, é hora de agir.
O Assassino Silencioso: Sempre Ligado Quando Deveria Ser Sob Demanda
Sejamos realistas. Quando estamos sob pressão para lançar uma nova ferramenta para agentes ou uma melhoria no serviço 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é “um pouco maior só para garantir”. Lançaremos um banco de dados com IOPS provisionados que poderiam gerenciar toda a Internet, apenas para que fique principalmente inativo durante as horas de baixa. Esquecemos de configurar políticas de escalonamento adequadas, ou simplesmente deixamos tudo funcionando 24/7 porque, bem, é mais fácil não se preocupar com isso.
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, construiu um sistema fantástico que fornecia aos agentes análises em tempo real das interações com os clientes. Foi uma grande vitória em termos de 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 alto nível e uma multitude de funções Lambda com alocações generosas de memória, todas funcionando sem parar. O golpe final? 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 na verdade estava inativo 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 Vai Seu Dinheiro
Antes de poder consertar algo, você precisa saber o que está quebrado. A maioria dos fornecedores de nuvem oferece ferramentas para ajudá-lo a visualizar seus gastos, e você deve absolutamente 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ância de Cálculo (EC2, VMs): Essas são frequentemente os principais culpados. Elas 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 estar superprovisionados em IOPS, CPU ou memória. Muitos agora oferecem opções serverless que diminuem para zero ou quase zero quando estão inativos.
- Armazenamento (volumes EBS, discos não conectados): Você já iniciou uma instância, a terminou, mas deixou o volume de armazenamento associado circulando? Isso acontece com mais frequência do que você pensa.
- Rede (Transferências de dados, NAT Gateways): Os custos de transferência de dados podem te surpreender, especialmente entre regiões. Mesmo os NAT Gateways 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 na história do painel de análise começou olhando seu AWS Cost Explorer. As despesas maiores eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS conectados a instâncias terminadas e uma NAT Gateway em uma VPC que não estava mais sendo utilizada para tráfego de produção. Coisas pequenas, mas que se acumulam.
Estratégias para Transformar Sempre Ativo em Sob Demanda (ou Fora de Pico)
Está bem, você identificou as áreas em que está gastando demais. Vamos para a parte divertida: consertar tudo 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/Parada das Instâncias
Este é provavelmente o fruto mais simples para muitas aplicações. Se suas ferramentas internas ou seus ambientes de teste são utilizados apenas durante o horário comercial, não há razão para que funcionem 24/7. A maioria dos provedores de cloud oferece maneiras nativas de agendar ciclos de fornecimento 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 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')
# Defina as tags para identificar as instâncias a serem paradas/iniciadas
# Por exemplo, 'Schedule': 'business-hours'
# Recupera 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 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 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 sozinho pode reduzir os custos de computação em mais de 70% para esses recursos específicos.
2. Adote Serverless e Orquestração de Contêineres
Se sua carga de trabalho é realmente esporádica ou acionada por eventos, o serverless é seu melhor aliado. AWS Lambda, Azure Functions, Google Cloud Functions – elas ficam em zero quando não estão em uso, o que significa que você paga apenas pelo cálculo quando seu código realmente é executado. É uma grande mudança em relação ao paradigma “sempre ativo”.
Para aplicações mais complexas que requerem constantemente serviços persistentes, mas têm uma demanda flutuante, as plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com scaling inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar o tamanho dos 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 conforme a demanda muda.
Meu cliente reestruturou partes do seu dashboard de análises para utilizar Lambda para gerar alguns relatórios 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 API Gateway. As economias foram imediatas e significativas.
3. Dimensione Corretamente Suas Bases de Dados com Serverless ou Auto-Scaling
As bases de dados são frequentemente problemáticas, pois 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á poucos anos.
- AWS Aurora Serverless v2 : É uma mudança significativa. Regula 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 provisionar para uma capacidade de pico quando a maior parte do tempo a operação é de carga reduzida.
- Azure SQL Database Serverless : Semelhante ao Aurora Serverless, adapta-se automaticamente à capacidade de computação e entra em pausa quando inativo, gerando economias significativas 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 cada solicitação, sem a necessidade de provisionar unidades de capacidade de leitura/gravação. Perfeito para padrões de tráfego imprevisíveis.
O dashboard analítico originalmente utilizava uma instância RDS PostgreSQL grande com IOPS provisionadas. Após a migração para o Aurora Serverless v2, os custos do banco de dados deles diminuíram em quase 60%, simplesmente porque não operava mais em plena capacidade durante as horas de baixa carga.
4. Limpe os Armazenamentos Não Anexados e os Snapshots
Isso pode parecer básico, mas é uma fonte constante de desperdício de dinheiro. Quando você termina uma instância EC2, o volume EBS associado nem sempre é eliminado 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 o AWS CLI para encontrar volumes não anexados e removê-los. É uma tarefa comum de limpeza.
# Listar 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 (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ê cria e remove ambientes frequentemente. 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 reais na fatura mensal – não é muito, mas cada pequeno gesto conta.
5. Otimize os Custos de Rede
As NAT Gateways são ótimas para permitir que instâncias em sub-redes privadas acessem a Internet, mas geram custos horários e custos de processamento de dados. Se você tiver várias NAT Gateways em diferentes zonas de disponibilidade, mas apenas uma está sendo utilizada ativamente, você está pagando por redundâncias.
- Consolide as NAT Gateways : Se a sua arquitetura permitir, consolide em menos NAT Gateways.
- Endpoints VPC : Para acessar os serviços AWS como S3 ou DynamoDB a partir do 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 melhor segurança.
Descobrimos que o cliente tinha uma 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, o que reduziu os custos de processamento de dados pela NAT Gateway.
Ações a Serem Tomadas para o Seu Próximo Sprint
Não se trata apenas de reduzir custos; trata-se de construir sistemas mais inteligentes e eficientes, intrinsicamente conscientes dos custos. Aqui está o que você pode começar a fazer já a partir de hoje:
- Audite Regularmente Sua Fatura de Nuvem: Torne isso um hábito. Utilize as ferramentas de gestão de custos do seu provedor de nuvem. Não deixe isso apenas para a parte financeira. Compreenda para onde vai cada real.
- 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 facilita enormemente a identificação e a automação.
- Dê Prioridade ao Desligamento para Ambientes Não Produtivos: Os ambientes de staging, dev, QA são candidatos ideais para desligamentos programados fora do horário comercial. Geralmente é o ganho mais simples e rápido.
- Avalie 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.
- Reavalie Suas Escolhas de Banco de Dados: Se você tem bancos de dados ativos 24/7 com cargas muito variáveis, examine as opções serverless ou de autoescalonamento para a sua tecnologia de banco de dados específica.
- 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.
- Eduque Seu Time: 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.
Parar 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ê 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 te torna um jogador melhor no campo tecnológico.
É tudo por minha parte desta vez. Continuem construindo de forma inteligente, e nos vemos na próxima!
🕒 Published: