Olá a todos, Jules Martin aqui, novamente no agntmax.com. Espero que vocês estejam indo muito bem por aí. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que vi emergir em várias conversas e análises de projetos mais do que gostaria de admitir: o custo invisível de uma infraestrutura não otimizada. Todos nós sabemos que precisamos construir rapidamente, evoluir rapidamente e entregar funcionalidades ontem. Mas muitas vezes, nessa corrida desenfreada, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços que operam no modo automático, acumulando faturas que mal olhamos até que a revisão orçamentária trimestral chegue como um relâmpago em céu limpo.
Então, para este artigo, vou me aprofundar na otimização de custos, mas com um ângulo muito específico e oportuno: como parar de perder dinheiro em recursos “sempre ativos” que deveriam ser “sob demanda” ou “ativados por eventos.” Estamos em 2026, amigos. Os dias em que provisionávamos servidores no modo “configura e esquece” acabaram. Se sua fatura na nuvem ainda se parece com uma lista telefônica, é hora de agir.
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 assume um papel secundário em relação à funcionalidade e à velocidade. Provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior, por via das dúvidas”. Lançamos um banco de dados com IOPS provisionadas que poderiam gerenciar toda a internet, apenas para descobrir que permanece principalmente ocioso durante os horários de pico. Esquecemos de definir políticas de escalonamento apropriadas, ou simplesmente deixamos as coisas funcionarem 24 horas por dia, 7 dias por semana, porque, bem, é mais fácil do que pensar nisso.
Eu 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, havia construído um sistema fantástico que fornecia aos agentes visibilidade em tempo real sobre as interações com os clientes. Foi uma grande vitória em termos de desempenho. Mas quando a primeira fatura da nuvem chegou, o CFO quase desmaiou. Eles haviam provisionado um cluster EKS robusto, algumas instâncias RDS de alto nível e uma série de funções Lambda com alocações de memória generosas, todas funcionando sem interrupções. O problema? O painel era usado principalmente pelos agentes durante o horário comercial, das 9h às 17h, de segunda a sexta. Fora desse horário, 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 realmente vai seu dinheiro
Antes de poder consertar algo, você precisa saber o que está errado. A maioria dos provedores de nuvem oferece ferramentas para ajudá-lo a visualizar seus gastos, e você deve absolutamente usá-las. AWS Cost Explorer, Azure Cost Management, os relatórios de faturamento do Google Cloud – não servem apenas para as finanças. Eles são sua primeira linha de defesa.
Os suspeitos normalmente envolvidos
- Instância de computação (EC2, VMs): Geralmente, são os maiores infratores. Estão superdimensionadas? Funcionam quando não precisam? 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 a computação, os bancos de dados podem estar superprovisionados em IOPS, CPU ou memória. Agora há muitas opções sem servidor, que caem a zero ou quase quando estão inativas.
- Armazenamento (volumes EBS, discos desconectados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado funcionando? Isso acontece mais frequentemente do que você imagina.
- Rede (transferência de dados, gateway NAT): Os custos de transferência de dados podem te surpreender, especialmente entre regiões. Os gateways NAT 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 alguns acessos por dia? Um cluster Kafka gerenciado para uma fila de mensagens?
Meu cliente do relato do painel analítico começou examinando seu AWS Cost Explorer. Os maiores custos 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 o tráfego de produção. Pequenas coisas, mas se somam.
Estratégias para transformar Sempre Ativo em Sob Demanda (ou Fora do Pico)
Ok, 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 apenas quando realmente necessário.
1. Planejar Início/Fim das Instâncias
É provavelmente o fruto mais fácil de colher para muitas aplicações. Se suas ferramentas internas ou ambientes de staging são usados apenas durante o horário comercial, não há razão para funcionarem 24 horas por dia, 7 dias por semana. A maioria dos provedores de nuvem oferece maneiras nativas de programar ciclos de potência das instâncias, ou você pode criar sua própria solução usando funções sem servidor.
Exemplo prático: agendador AWS EC2 com Lambda
Você pode criar uma função Lambda simples acionada por eventos 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')
# Definir tags para identificar as instâncias a parar/iniciar
# Por exemplo, 'Schedule': 'business-hours'
# Obter 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 as instâncias em outro momento ---
# Você teria outra função Lambda/evento CloudWatch para o início,
# ou combinar a lógica com uma tag 'start'.
return {
'statusCode': 200,
'body': 'Agendamento das instâncias EC2 completo.'
}
Você configuraria duas regras de eventos CloudWatch: uma para acionar essa Lambda, digamos, às 18:00 UTC para parar as instâncias, e outra às 7:00 UTC para iniciá-las. Isso pode 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 acionada por eventos, o sem servidor é seu melhor amigo. AWS Lambda, Azure Functions, Google Cloud Functions – vão a zero quando não estão em uso, o que significa que você paga apenas pelo processamento quando seu código é realmente executado. É 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 um escalonamento inteligente são poderosas. Os escalonadores de pods horizontais (HPA) podem aumentar ou diminuir seus pods de aplicação com base no uso da CPU ou em métricas personalizadas. Os escalonadores de cluster podem até adicionar ou remover nós de seu cluster com base na evolução da demanda.
Meu cliente refez algumas partes do seu painel analítico para usar Lambda para gerar alguns relatórios que eram necessários apenas algumas vezes ao dia. Em vez de uma instância EC2 dedicada que executava um job cron, uma função Lambda era acionada por um evento S3 (novos dados carregados) ou por uma solicitação API Gateway. As economias obtidas foram imediatas e significativas.
3. Dimensione corretamente seus bancos de dados com Sem Servidor ou Auto-Escalabilidade
Os bancos de dados são frequentemente um assunto delicado, pois a persistência de dados é fundamental. No entanto, muitos bancos de dados modernos oferecem opções sem servidor ou de auto-escalabilidade que não estavam amplamente disponíveis alguns anos atrás.
- AWS Aurora Serverless v2 : É uma mudança significativa. Adapta sua capacidade com base no uso real, de frações de uma ACU (Unidade de Capacidade Aurora) a centenas, e você paga apenas pelo que utiliza. Não é mais necessário provisionar para uma capacidade de pico enquanto a maior parte do tempo opera em carga de base.
- Azure SQL Database Serverless : Semelhante ao Aurora Serverless, ajusta automaticamente o cálculo e entra em pausa quando está inativo, economizando assim custos significativos 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 solicitação, sem precisar provisionar unidades de capacidade de leitura/escrita. Perfeito para modelos de tráfego imprevisíveis.
O painel analítico usava inicialmente uma grande instância RDS PostgreSQL com IOPS provisionadas. Após a migração para Aurora Serverless v2, os custos de banco de dados deles diminuíram em quase 60%, simplesmente porque não funcionava mais em plena carga durante os períodos de inatividade.
4. Limpe o Armazenamento Desanexado e os Snapshots
Isso pode parecer básico, mas é uma fonte constante de despesas desnecessárias. Quando você termina uma instância EC2, seu volume EBS associado nem sempre é excluído 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 os Volumes EBS Desanexados (AWS CLI)
Você pode usar a AWS CLI para encontrar volumes desanexados 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 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ê criar e remover ambientes frequentemente. O cliente descobriu vários terabytes de antigos volumes EBS desanexados e centenas de snapshots obsoletos. Removê-los reduziu sua fatura mensal em algumas centenas de dólares – não é uma quantia enorme, mas cada pequeno gesto 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 implicam custos horários e custos de processamento de dados. Se você tiver várias gateways NAT em diferentes zonas de disponibilidade, mas apenas uma estiver sendo 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, utilize os pontos de acesso VPC. O tráfego circula privadamente dentro da rede AWS, evitando assim os custos da gateway NAT e oferecendo maior segurança.
Descobrimos que o cliente tinha uma gateway NAT em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles puderam consolidar e economizar um pouco desse lado, e depois implementaram os pontos de acesso VPC para acesso ao S3, reduzindo os custos de processamento de dados através da gateway NAT.
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 que sejam intrinsecamente conscientes dos custos. Aqui está o que você pode começar a fazer imediatamente :
- Audite Regularmente sua Fatura na Nuvem: Torne isso um hábito. Utilize as ferramentas de gerenciamento de custos do seu provedor de nuvem. Não se limite a enviá-la para o serviço financeiro. Compreenda para onde vai cada real.
- Rotule Tudo: Isso é inegociável. Rotule os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se podem ser programados para desligamento. Isso torna a identificação e a automação infinitamente mais fáceis.
- Priorize o Planejamento para Ambientes Não Produtivos: Os ambientes de staging, dev e QA são candidatos ideais para desligamentos programados fora do horário de trabalho. Normalmente, é 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 como a primeira opção.
- Reavalie as Escolhas de Bancos de Dados: Se você tem bancos de dados funcionando 24/7 com cargas altamente 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 vinculados, snapshots antigos e outros recursos órfãos.
- 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.
Parar a fuga de recursos “sempre ativos” não é uma solução única; é uma disciplina contínua. Mas, ao implementar essas mudanças, você não apenas 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 torna melhor no setor tecnológico.
É tudo da minha parte desta vez. Continue construindo de forma inteligente, e nos vemos na próxima!
🕒 Published: