Oi, pessoal, Jules Martin aqui, de volta ao agntmax.com. Espero que vocês estejam arrasando por aí. Hoje, quero falar sobre algo que tem me incomodado ultimamente, algo que notei aparecer em mais conversas e análises de projetos do que eu gostaria de admitir: o custo invisível de uma infraestrutura não otimizada. Todos nós sabemos que precisamos construir rápido, escalar rapidamente e entregar funcionalidades ontem. Mas, muitas vezes, nessa corrida maluca, 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é que a revisão orçamentária trimestral chegue como um raio.
Portanto, para este artigo, vou me aprofundar na otimização de custos, mas com um ângulo muito específico e oportuno: como parar de sangrar dinheiro em recursos “sempre ativos” que deveriam ser “sob demanda” ou “ativados por eventos”. Estamos em 2026, amigos. Os dias em que provisionamos servidores no modo “configurar e esquecer” são coisa do passado. Se a sua conta na nuvem ainda parece um diretório, é hora de agir.
O Assassino Silencioso: Sempre Ativo Quando Deveria Ser Sob Demanda
Vamos ser realistas. Quando estamos sob pressão para lançar uma nova ferramenta para agentes ou uma melhoria no atendimento ao cliente, o custo geralmente assume um lugar secundário em relação à funcionalidade e à velocidade. Provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior para garantir”. Lançamos um banco de dados com IOPS provisionados que poderiam gerenciar toda a internet, só para que ele fique principalmente desocupado durante os horários de pico. Esquecemos de implementar políticas de escalonamento adequadas ou simplesmente deixamos as coisas rodando 24/7 porque, bem, é mais fácil do que pensar nisso.
Vi isso com meus próprios olhos há alguns meses com o novo painel analítico interno de um cliente. A equipe, que Deus a abençoe, construiu um sistema fantástico que dava aos agentes uma visão em tempo real das interações com os clientes. Foi uma enorme vitória para o desempenho. Mas quando a primeira fatura da nuvem chegou, o CFO quase teve um ataque cardíaco. Eles tinham provisionado um cluster EKS robusto, algumas instâncias RDS de alto desempenho e uma série de funções Lambda com alocações de memória generosas, todas funcionando sem interrupção. O problema? O painel era usado principalmente por agentes durante o horário comercial, das 9h às 17h, de segunda a sexta-feira. Fora isso, era uma cidade fantasma.
Eles estavam pagando 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.
Identificando os Culpados: Para Onde Está Indo Realmente Seu Dinheiro
Antes de poder consertar qualquer coisa, você precisa saber o que está errado. A maioria dos provedores de nuvem oferece ferramentas para ajudá-lo a visualizar seus gastos, e você precisa usá-las. AWS Cost Explorer, Azure Cost Management, relatórios de faturamento do Google Cloud – não são apenas para fins financeiros. Eles são sua primeira linha de defesa.
Os Suspeitos Comumente Envolvidos
- Instâncias de Cálculo (EC2, VMs): Essas são frequentemente as maiores infratoras. Estão superdimensionadas? Estão funcionando quando não precisam? Você está usando a família de instâncias certa para sua carga de trabalho?
- Bancos de Dados (RDS, Azure SQL, Cloud SQL): Assim como no cálculo, os bancos de dados podem ser sobreprovisionados em IOPS, CPU ou memória. Muitas opções sem servidor estão agora disponíveis, que diminuem para zero ou quase isso quando inativas.
- Armazenamento (volumes EBS, discos detachados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado parado? Isso acontece mais frequentemente do que você imagina.
- Rede (transferência de dados, gateways NAT): Os custos de transferência de dados podem surpreendê-lo, especialmente entre regiões. Os gateways NAT também têm um custo por hora, mesmo que não estejam fazendo nada.
- Serviços subutilizados: Você está pagando por um cache Redis dedicado que só tem alguns acessos por dia? Um cluster Kafka gerenciado para uma fila de mensagens?
Meu cliente do painel analítico começou examinando seu AWS Cost Explorer. Os maiores gastos eram, sem surpresa, EC2 e RDS. Eles também encontraram alguns volumes EBS anexados a instâncias encerradas e um gateway NAT em um VPC que não estava mais sendo utilizado ativamente para tráfego de produção. Coisas pequenas, mas que se somam.
Estratégias para Transformar Sempre Ativo em Sob Demanda (ou Fora de Pico)
Certo, você identificou as áreas onde está gastando demais. Agora vem a parte divertida: consertá-las. O objetivo não é apenas economizar dinheiro, mas criar um sistema mais resiliente e eficiente que consome recursos somente quando realmente precisa.
1. Planejar Início/Parada de Instâncias
Essa é provavelmente a fruta mais fácil de alcançar para muitas aplicações. Se suas ferramentas internas ou ambientes de teste só são usados durante o horário comercial, não há motivo para funcionarem 24/7. A maioria dos provedores de nuvem oferece maneiras nativas de programar ciclos de energia das instâncias, ou você pode criar sua própria solução com funções sem servidor.
Exemplo Prático: Agendador AWS EC2 com Lambda
Você pode criar uma simples função Lambda que é acionada 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 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 a parar.")
# --- Lógica semelhante para iniciar as instâncias em outro momento ---
# Você teria outra função Lambda/evento CloudWatch para a inicialização,
# ou combinar a lógica com uma tag 'start'.
return {
'statusCode': 200,
'body': 'Agendamento das instâncias EC2 concluído.'
}
Você configuraria duas regras de eventos do CloudWatch: uma para acionar essa Lambda, digamos, às 18h UTC para parar as instâncias, e outra às 7h UTC para iniciá-las. Isso pode reduzir os custos com 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 amigo. AWS Lambda, Azure Functions, Google Cloud Functions – eles descem a zero quando não utilizados, o que significa que você paga apenas pelo cálculo quando seu código realmente está em execução. Essa é uma mudança enorme em relação à noção de “sempre ativo”.
Para aplicações mais complexas que ainda precisam de serviços persistentes, mas têm uma demanda flutuante, as plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com escalonamento inteligente são poderosas. Os escalonadores automáticos de pods horizontais (HPA) podem aumentar ou diminuir seus pods de aplicação com base no uso de CPU ou em métricas personalizadas. Os escalonadores automáticos de clusters podem até adicionar ou remover nós do seu cluster conforme a demanda evolui.
Meu cliente reformulou algumas partes de seu painel analítico para usar Lambda a fim de gerar alguns relatórios que eram solicitados apenas algumas vezes por dia. Em vez de uma instância EC2 dedicada executando um job cron, uma função Lambda era acionada por um evento S3 (novos dados carregados) ou uma solicitação da API Gateway. As economias foram imediatas e significativas.
3. Dimensione Corretamente Suas Bases de Dados com Sem-Servidor ou Auto-Escalonamento
As bases de dados são frequentemente um assunto delicado, pois a persistência dos dados é essencial. No entanto, muitas bases de dados modernas oferecem opções sem servidor ou de autoescala que não estavam amplamente disponíveis há alguns anos.
- AWS Aurora Serverless v2: É uma mudança significativa. Ela adapta sua capacidade com base no uso real, de frações de uma ACU (Unidade de Capacidade Aurora) até centenas, e você só paga pelo que usa. Não é mais necessário provisionar para capacidade de pico enquanto a maior parte do tempo você opera com carga mínima.
- Azure SQL Database Serverless: Semelhante ao Aurora Serverless, ajusta automaticamente o cálculo e pausa quando está inativa, economizando assim 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 requisição, sem precisar provisionar unidades de capacidade de leitura/escrita. Perfeito para padrões de tráfego imprevisíveis.
O painel analítico originalmente utilizava uma grande instância RDS PostgreSQL com IOPS provisionadas. Após a migração para Aurora Serverless v2, seus custos com banco de dados caíram quase 60%, simplesmente porque ele não estava mais funcionando a plena capacidade durante os horários de pico.
4. Limpeza de Armazenamento Desligado e Instantâneos
Isso pode parecer básico, mas é uma fonte constante de despesas desnecessárias. Quando você finaliza uma instância EC2, seu volume EBS associado nem sempre é excluído por padrão, especialmente se era um volume não raiz. O mesmo vale para os instantâneos – eles se acumulam rapidamente e podem se tornar caros.
Exemplo Prático: Encontrar e Excluir Volumes EBS Desligados (AWS CLI)
Você pode usar o AWS CLI para encontrar volumes desligados e excluí-los. É uma tarefa comum de limpeza.
# Lista de todos os volumes não anexados
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table
# Para excluir 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 exclui frequentemente ambientes. O cliente descobriu vários terabytes de antigos volumes EBS não anexados e centenas de instantâneos obsoletos. Excluí-los reduziu sua fatura mensal em algumas centenas de dólares – não é uma quantia enorme, mas cada pequena ação conta.
5. Otimize os Custos de Rede
As gateways NAT são fantásticas para permitir que instâncias em sub-redes privadas acessem a Internet, mas geram custo por hora e taxas de processamento de dados. Se você tem várias gateways NAT em diferentes zonas de disponibilidade, mas apenas uma é usada ativamente, você está pagando por redundâncias.
- Consolide as Gateways NAT: Se sua arquitetura permitir, reduza o número de gateways NAT.
- Pontos de Acesso VPC: Para acessar serviços AWS como S3 ou DynamoDB a partir do seu VPC, use os pontos de acesso VPC. O tráfego circula de forma privada na rede da AWS, evitando assim os custos da gateway NAT e oferecendo uma melhor segurança.
Observamos que o cliente tinha uma gateway NAT em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles conseguiram consolidar e economizar um pouco ali, e então implementaram pontos de acesso VPC para acesso ao S3, o que reduziu os custos de processamento de dados via gateway NAT.
Ações a Tomar para Seu Próximo Sprint
Não se trata apenas de reduzir custos; trata-se de construir sistemas mais inteligentes e eficientes que sejam intrinsecamente conscientes dos custos. Aqui está o que você pode começar a fazer desde já:
- Audite Regularmente Sua Fatura de Nuvem: Faça disso um hábito. Utilize as ferramentas de gestão de custos do seu provedor de nuvem. Não apenas passe isso para o departamento financeiro. Entenda para onde vai cada dólar.
- Tague Tudo: Isso é inegociável. Tague 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-Produção: Os ambientes de staging, dev e QA são candidatos ideais para paradas programadas fora do horário de expediente. Geralmente, essa é a vitória mais fácil e rápida.
- 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 em primeiro lugar.
- Reavalie as Escolhas de Bases de Dados: Se você tem bases de dados funcionando 24/7 com cargas altamente variáveis, examine opções serverless ou de autoescala para sua tecnologia de banco de dados específica.
- Automatize a Limpeza: Implemente scripts automatizados ou funções serverless para identificar e excluir volumes de armazenamento não anexados, velhos instantâneos 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 financeiras de suas escolhas de provisionamento. Isso não é mais apenas uma questão de operação.
Parar o desperdício de recursos “sempre ativos” não é uma solução pontual; é uma disciplina contínua. Mas ao operar essas mudanças, você não só economizará uma quantia considerável de dinheiro para sua empresa, mas também construirá uma infraestrutura mais ágil, resiliente e sustentável. E, francamente, isso simplesmente o tornará melhor na área de tecnologia.
Isso é tudo por agora. Continue a construir de forma inteligente, e nos vemos da próxima vez!
🕒 Published: