Os meus custos de infraestrutura ocultos mataram o meu orçamento.

Olá a todos, Jules Martin aqui, de volta ao agntmax.com. Espero que todos estejam bem. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que tenho visto emergir em mais conversas e post-mortems de projetos do que gostaria de admitir: a extração invisível dos custos de infraestrutura não otimizados. Todos nós sabemos que precisamos construir rapidamente, escalar rapidamente e entregar funcionalidades ontem. Mas muitas vezes, nessa pressa, deixamos para trás uma trilha de recursos esquecidos, de instâncias superdimensionadas e de serviços que operam em piloto automático, acumulando faturas a que mal olhamos antes que a revisão orçamentária trimestral caia como toneladas de tijolos.

Então, para este artigo, enfrento de cabeça erguida a otimização de custos, mas com um ângulo muito específico e oportuno: como parar de perder dinheiro em recursos “sempre ligados” que deveriam ser “sob demanda” ou “ativados por eventos”. Estamos em 2026, pessoal. Os dias da provisionamento de servidores à la carte acabaram. Se a sua fatura de nuvem ainda parece uma lista telefônica, é hora de agir.

O Silencioso Assassino: Sempre Ligado Quando Deveria Ser Sob Demanda

Sejamos 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 fica em segundo plano 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, apenas para vê-lo permanecer principalmente inutilizado durante as horas não pico. Esquecemos de configurar políticas de escalabilidade adequadas, ou simplesmente deixamos as coisas funcionando 24/7 porque, bem, é mais fácil não pensar nisso.

Eu vi isso com meus próprios olhos alguns meses atrás com o novo painel de análise interna de um cliente. A equipe, que Deus os abençoe, havia construído um sistema fantástico que fornecia 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 completa da nuvem chegou, o diretor financeiro quase teve um ataque cardíaco. Eles tinham provisionado um cluster EKS robusto, algumas instâncias RDS de alto nível, e uma infinidade de funções Lambda com alocações de memória generosas, todas funcionando sem interrupção. A cereja do bolo? O painel era utilizado principalmente pelos agentes durante o horário comercial, das 9 às 17, de segunda a sexta. Fora desse horário, era uma cidade fantasma.

Eles pagavam 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 Vai Realmente o Seu Dinheiro

Antes de poder consertar algo, você precisa saber o que está quebrado. A maioria dos provedores de nuvem oferece ferramentas para ajudar você 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 contas. Eles são sua primeira linha de defesa.

Os Suspeitos Habituales

• Instância de Cálculo (EC2, VMs): Estas são frequentemente os principais culpados. 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 para IOPS, CPU ou memória. Muitos agora oferecem opções serverless que vão para zero ou quase zero quando estão inativos.
• Armazenamento (volumes EBS, discos não anexados): Você já iniciou uma instância, a terminou, mas deixou o volume de armazenamento associado funcionando? Isso acontece mais do que você imagina.
• Networking (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem surpreendê-lo, especialmente entre regiões. As NAT Gateways 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 rede de mensagens?

Meu cliente do relato do painel de análise começou olhando seu AWS Cost Explorer. As maiores entradas de despesa eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS conectados a instâncias terminadas e um NAT Gateway em uma VPC que não estava mais sendo utilizada para tráfego de produção. Pequenas coisas, mas isso se acumula.

Estratégias para Transformar Sempre Ativo em Sob Demanda (ou Fora de Pico)

Está bem, você identificou as áreas em que gasta demais. Vamos para a parte divertida: consertar isso. O objetivo não é apenas economizar dinheiro, mas construir um sistema mais resiliente e eficiente que consuma recursos somente quando realmente precisar.

1. Planejar o Início/Parada das Instâncias

É provavelmente o fruto mais fácil para muitas aplicações. Se suas ferramentas internas ou ambientes de teste 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 maneiras nativas de programar os ciclos de alimentação 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')
 
 # Definir tags para identificar as instâncias a serem paradas/iniciadas
 # Por exemplo, 'Schedule': 'horário-comercial'
 
 # Recuperar todas as instâncias em execução com a tag 'Schedule' definida para 'horário-comercial'
 running_instances = ec2.describe_instances(
 Filters=[
 {'Name': 'instance-state-name', 'Values': ['running']},
 {'Name': 'tag:Schedule', 'Values': ['horário-comercial']}
 ]
 )
 
 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 Lambda/Event CloudWatch para iniciar,
 # ou combinar a lógica com uma tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Planejamento 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 por si só pode reduzir os custos de computação em mais de 70% para esses recursos específicos.

2. Adotar o Serverless e a 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 – eles caem para 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 enorme mudança em relação ao paradigma “sempre ativo”.

Para aplicações mais complexas que ainda requerem serviços persistentes, mas têm uma demanda flutuante, as plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com escalabilidade 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 também podem adicionar ou remover nós do seu cluster à medida que a demanda muda.

Meu cliente reestruturou partes do seu painel de análise para usar Lambda para gerar alguns relatórios que eram 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 uma solicitação da API Gateway. As economias foram imediatas e significativas.

3. Dimensionar Corretamente Seus Bancos de Dados com o Serverless ou Auto-escala

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 serverless ou de auto-escala que não estavam amplamente disponíveis alguns anos atrás.

• AWS Aurora Serverless v2: É uma mudança significativa. Ajusta 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 dimensionar para uma capacidade de pico enquanto a maior parte do tempo funciona em carga básica.
• Azure SQL Database Serverless: Semelhante ao Aurora Serverless, adapta-se automaticamente à capacidade de computação e entra em pausa quando está inativo, gerando 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 solicitação, sem precisar dimensionar unidades de capacidade de leitura/gravação. Perfeito para modelos de tráfego imprevisíveis.

O dashboard analítico inicialmente usava uma grande instância RDS PostgreSQL com IOPS dimensionadas. Após a migração para o Aurora Serverless v2, seus custos com o banco de dados diminuíram em quase **60%**, simplesmente porque não funcionava mais em plena capacidade durante as horas de inatividade.

4. Limpe os Armazenamentos Não Conectados e os Snapshots

Pode parecer trivial, 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 raiz. O mesmo vale para os snapshots – eles se acumulam rapidamente e podem se tornar caros.

Exemplo Prático: Encontrar e Excluir Volumes EBS Não Conectados (AWS CLI)

Você pode usar a AWS CLI para encontrar volumes não conectados e removê-los. É uma tarefa comum de limpeza.

# Lista todos os volumes não conectados
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 frequentemente ambientes. O cliente descobriu vários terabytes de antigos volumes EBS não conectados e centenas de snapshots obsoletos. A exclusão deles permitiu economizar algumas centenas de dólares na conta mensal – não é muito, mas cada pequeno gesto conta.

5. Otimizar os Custos de Rede

As NAT Gateways são ótimas 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 NAT Gateways em diferentes zonas de disponibilidade, mas apenas uma estiver sendo usada ativamente, está pagando por aquelas redundantes.

• Consolide as NAT Gateways: Se sua arquitetura permitir, consolide para menos NAT Gateways.
• Endpoints VPC: Para acessar serviços AWS como S3 ou DynamoDB do seu VPC, utilize os Endpoints VPC. O tráfego circula de forma privada dentro da rede AWS, evitando os custos das NAT Gateways e oferecendo uma melhor segurança.

Descobrimos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que seu aplicativo principal funcionasse apenas em duas. Eles conseguiram consolidar e economizar dessa forma, depois implementaram os Endpoints VPC para acesso ao S3, reduzindo assim os custos de processamento de dados via NAT Gateway.

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, intrinsecamente conscientes dos custos. Aqui está o que você pode começar a fazer já hoje:

“`html

1. Audite Regularmente Sua Fatura de Nuvem: Faça disso um hábito. Use as ferramentas de gestão de custos do seu fornecedor de nuvem. Não deixe isso apenas para o financeiro. Compreenda para onde vai cada real.
2. 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.
3. 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 de trabalho. Geralmente, é o ganho mais fácil e rápido.
4. Considere 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 primeiro o serverless.
5. Reavalie Suas Escolhas de Banco de Dados: Se você possui bancos de dados que funcionam 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.
6. Automatize a Limpeza: Implemente scripts automatizados ou funções serverless para identificar e eliminar volumes de armazenamento não conectados, snapshots antigos e outros recursos órfãos.
7. 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 as perdas relacionadas aos recursos “sempre ativos” não é uma solução temporária; é uma disciplina contínua. Mas fazendo essas mudanças, você não só 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 o torna um jogador melhor no campo da tecnologia.

É tudo para mim desta vez. Continue construindo de forma inteligente, e nos vemos na próxima!

“`

🕒 Published: April 5, 2026