Olá, pessoal, Jules Martin aqui, de volta no agntmax.com. Espero que todos vocês estejam indo bem. Hoje, quero falar sobre algo que tem me incomodado ultimamente, algo que vi surgir em mais conversas e post-mortems de projetos do que quero admitir: o consumo invisível de custos de infraestrutura não otimizados. Todos nós sabemos que é preciso construir rapidamente, escalar rapidamente 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 no piloto automático, acumulando contas que mal olhamos antes que a revisão orçamentária trimestral caia como um peso de pedras.
Então, para este artigo, vou me aprofundar em otimização de custos, mas com um ângulo muito específico e oportuno: como parar de desperdiçar dinheiro em recursos “sempre ligados” que deveriam ser “sob demanda” ou “ativados por eventos.” Estamos em 2026, pessoal. Os dias da provisionamento de servidores sob demanda acabaram. Se sua conta de nuvem ainda parece um catálogo telefônico, é hora de agir.
O Silencioso Assassino: Sempre Ligado Quando Deveria Ser Sob Demanda
Vamos ser realistas. Quando estamos sob pressão para lançar uma nova ferramenta para os agentes ou uma melhoria no serviço ao cliente, o custo geralmente fica em segundo plano em relação à funcionalidade e à rapidez. Provisionamos uma instância EC2 que é “grande o suficiente”, talvez até “um pouco maior só para garantir.” Lançamos um banco de dados com IOPS provisionados que poderiam gerenciar toda a Internet, apenas para que ele fique principalmente ocioso durante os horários de pico. Esquecemos de configurar políticas de escalonamento adequadas, ou simplesmente deixamos as coisas funcionando 24/7 porque, bem, é mais fácil do que se preocupar com isso.
Eu vi 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 insights em tempo real sobre as interações com os clientes. Foi uma enorme vitória para a performance. Mas quando a primeira conta de nuvem completa chegou, o diretor financeiro quase teve um infarto. Eles tinham provisionado um cluster EKS robusto, algumas instâncias RDS de alto desempenho e uma infinidade de funções Lambda com alocações de memória generosas, todas funcionando sem interrupção. O melhor de tudo? O painel era usado principalmente pelos agentes durante o horário comercial, das 9h às 17h, de segunda a sexta. Fora isso, era uma cidade fantasma.
Eles estavam pagando por uma capacidade de nível empresarial para um sistema que estava efetivamente ocioso 70% da semana. É como comprar um carro de Fórmula 1 para ir ao supermercado uma vez por semana.
Identifique os Culpados: Para Onde Realmente Vai Seu Dinheiro
Antes de poder corrigir 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ê deve absolutamente utilizá-las. AWS Cost Explorer, Azure Cost Management, relatórios de faturamento do Google Cloud – não são apenas para finanças. Eles são sua primeira linha de defesa.
Os Suspeitos Comuns
- Instâncias de Computação (EC2, VMs): Muitas vezes, são os maiores culpados. Estão superdimensionadas? Estão funcionando quando não deveriam? 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 na computação, os bancos de dados podem ser superprovisionados para IOPS, CPU ou memória. Muitos agora oferecem opções sem servidor que se reduzem a zero ou a um custo próximo de zero quando estão inativos.
- Armazenamento (volumes EBS, discos não anexados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado para trás? Isso acontece mais frequentemente do que você imagina.
- Rede (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem te surpreender, especialmente entre regiões. As NAT Gateways 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 tem apenas algumas acessos por dia? Um cluster Kafka gerenciado para um fluxo de mensagens?
Meu cliente do relato do painel de análise começou observando seu AWS Cost Explorer. Os maiores itens de despesa eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS anexados a instâncias encerradas e uma NAT Gateway em uma VPC que não estava mais sendo usada para tráfego de produção. Coisas pequenas, mas que se acumulam.
Estratégias para Transformar Sempre Ligado em Sob Demanda (ou Fora de Pico)
Ok, você identificou as áreas onde está gastando demais. Vamos 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/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 que funcionem 24/7. A maioria dos provedores de nuvem oferece meios nativos para programar ciclos de alimentação de instâncias, ou você pode criar sua própria solução com funções sem servidor.
Exemplo Prático: Agendador EC2 AWS com Lambda
Você pode criar uma função Lambda simples 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 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 instâncias: {stop_instance_ids}")
ec2.stop_instances(InstanceIds=stop_instance_ids)
else:
print("Nenhuma instância a 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 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, por si só, 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 aliado. AWS Lambda, Azure Functions, Google Cloud Functions – eles se reduzem a zero quando não utilizados, o que significa que você paga apenas pela computação quando seu código está realmente em execução. É uma mudança enorme em relação ao paradigma “sempre ligado”.
Para aplicações mais complexas que ainda exigem serviços persistentes, mas têm uma demanda fluctuante, as plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com escalonamento inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar o tamanho de seus pods de aplicação com base no uso de CPU ou em métricas personalizadas. Os Cluster Autoscalers podem até adicionar ou remover nós do seu cluster à medida que a demanda muda.
Meu cliente refatorou partes de seu painel de análise para usar Lambda para gerar alguns relatórios que eram solicitados apenas algumas vezes por dia. Em vez de uma instância EC2 dedicada executando um cron job, uma função Lambda foi acionada por um evento S3 (novos arquivos carregados) ou uma requisição da API Gateway. As economias foram imediatas e significativas.
3. Dimensione Corretamente Seus Bancos de Dados com Sem Servidor ou Auto-Scaling
Os bancos de dados costumam ser problemáticos porque a persistência dos dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções sem servidor ou de autoescalonamento que não estavam amplamente disponíveis há alguns anos.
- AWS Aurora Serverless v2 : É uma mudança significativa. Ele ajusta a capacidade com base no uso real, variando de frações de uma ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que utiliza. Não é mais necessário provisionar capacidade máxima enquanto a maior parte do tempo você opera em carga básica.
- Azure SQL Database Serverless : Semelhante ao Aurora Serverless, ele se adapta automaticamente à capacidade de computação e faz pausa quando está inativo, garantindo 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 consulta, sem a necessidade de provisionar unidades de capacidade de leitura/escrita. Perfeito para modelos de tráfego imprevisíveis.
O painel de analytics usava originalmente uma instância RDS PostgreSQL grande com IOPS provisionadas. Após a migração para o Aurora Serverless v2, os custos de banco de dados deles caíram quase 60%, simplesmente porque não estavam mais operando em plena carga durante os horários de menor movimento.
4. Limpe os Armazenamentos Não Anexados e os Snapshots
Pode parecer básico, mas é uma fonte constante de desperdício de dinheiro. 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 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 (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 volumes EBS não anexados antigos e centenas de snapshots obsoletos. Removê-los gerou uma economia de algumas centenas de dólares na fatura mensal deles – não é muito, mas cada pequeno gesto conta.
5. Otimize os Custos de Rede
As NAT Gateways são fantásticas para permitir que instâncias em sub-redes privadas acessem a Internet, mas elas geram taxas horárias e custos de processamento de dados. Se você tiver várias NAT Gateways em diferentes zonas de disponibilidade, mas apenas uma estiver sendo usada ativamente, você está pagando por redundâncias.
- Consolide as NAT Gateways : Se sua arquitetura permitir, consolide para menos NAT Gateways.
- Endpoints VPC : Para acessar serviços AWS como S3 ou DynamoDB a partir de seu VPC, use Endpoints VPC. O tráfego flui de forma privada dentro da rede AWS, evitando os custos das NAT Gateways e oferecendo melhor segurança.
Observamos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que seu aplicativo principal funcionasse apenas em duas. Eles conseguiram consolidar e economizar com isso, e em seguida implementaram Endpoints VPC para acesso ao S3, o que reduziu os custos de processamento de dados pela NAT Gateway.
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, intrinsicamente conscientes dos custos. Aqui está o que você pode começar a fazer a partir de hoje:
- Audite Regularmente Sua Fatura na Nuvem: Transforme isso em um hábito. Use as ferramentas de gestão de custos do seu provedor de nuvem. Não deixe apenas para o setor financeiro. Entenda para onde cada dólar está indo.
- Classifique Tudo: Isso é inegociável. Classifique os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se podem ser programados para desligamento. Isso facilita enormemente a identificação e automação.
- Priorize o 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, esse é o ganho mais fácil e rápido.
- Considere o Serverless para Novas Cargas de Trabalho: Se você estiver construindo algo novo, especialmente microsserviços baseados em eventos ou tarefas em segundo plano, sempre considere o serverless em primeiro lugar.
- Reavalie Suas Escolhas de Banco de Dados: Se você tem bancos de dados funcionando 24/7 com cargas muito variáveis, examine as opções serverless ou de auto-escalonamento para 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 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 de operações.
Parar as perdas relacionadas a recursos “sempre ativos” não é uma solução pontual; é 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 preparada para o futuro. E, francamente, isso fará de você um ator melhor no campo tecnológico.
É isso por enquanto. Continue a construir de forma inteligente, e nos vemos na próxima!
🕒 Published: