Meus custos de infraestrutura ocultos arruinaram meu orçamento

Olá a todos, Jules Martin aqui, de volta no agntmax.com. Espero que vocês estejam todos bem. Hoje, quero falar sobre algo que tem me preocupado ultimamente, algo que vi surgir em mais conversas e pós-mortem de projetos do que eu quero admitir: o custo invisível da infraestrutura não otimizada. Todos nós sabemos que precisamos construir rapidamente, escalar rápido e entregar funcionalidades ontem. Mas muitas vezes, nessa pressa, deixamos para trás uma trilha de recursos esquecidos, instâncias superdimensionadas e serviços funcionando no piloto automático, acumulando contas que mal damos uma olhada antes que a revisão orçamentária trimestral chegue como uma tonelada de tijolos.

Então, para este artigo, eu mergulho 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 “acionados por evento.” Estamos em 2026, pessoal. Os dias de provisionar servidores sob demanda acabaram. Se sua fatura na nuvem ainda parece um catálogo telefônico, é 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 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 só por precaução.” Lançamos um banco de dados com IOPS provisionados que poderia suportar toda a Internet, só para que ele fique principalmente ocioso durante os horários de pico. Esquecemos de configurar políticas de escala apropriadas 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 das interações com os clientes. Foi uma grande vitória para a performance. Mas quando a primeira fatura completa da nuvem chegou, 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 infinidade de funções Lambda com alocações de memória generosas, todas funcionando sem interrupções. O clímax do espetáculo? O painel era principalmente utilizado 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 inativo 70% da semana. É como comprar um carro de Fórmula 1 para ir ao supermercado uma vez por semana.

Identifique os Culpados: Onde Vai Realmente Seu Dinheiro

Antes de podermos consertar qualquer coisa, precisamos saber o que está quebrado. A maioria dos fornecedores de nuvem oferece ferramentas para ajudar você a visualizar seus gastos, e você precisa 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 Suspeitos Comuns

• Instâncias de Cálculo (EC2, VMs): Muitas vezes, esses são os maiores culpados. Elas estão superdimensionadas? Funcionam quando não deveriam? Você está usando a família de instâncias correta para sua carga de trabalho?
• Bancos 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 sem servidor que se reduzem a zero ou a um custo próximo de zero quando estão ociosos.
• Armazenamento (volumes EBS, discos não anexados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado por aí? Isso acontece com mais frequência 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 quando não estão fazendo nada.
• Serviços Subutilizados: Você paga por um cache Redis dedicado que tem apenas alguns acessos por dia? Um cluster Kafka gerenciado para um stream de mensagens?

Meu cliente do relato do painel de análise começou a olhar 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 utilizada para tráfego de produção. Coisas pequenas, mas que somam.

Estratégias para Transformar Sempre Ligado em Sob Demanda (ou Fora de Horário)

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 consuma recursos apenas quando realmente precisar.

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

Esse é provavelmente o fruto mais fácil para muitas aplicações. Se suas ferramentas internas ou ambientes de staging são utilizados apenas durante o horário comercial, não há razão para que funcionem 24/7. A maioria dos fornecedores 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 EC2 AWS com Lambda

Você pode criar uma simples função Lambda 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 as instâncias: {stop_instance_ids}")
 ec2.stop_instances(InstanceIds=stop_instance_ids)
 else:
 print("Nenhuma instância para parar.")
 
 # --- Lógica similar para iniciar instâncias em outro momento ---
 # Você teria outra Lambda/Event do CloudWatch para iniciar,
 # ou combina 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 estão sendo usados, o que significa que você só paga pelo cálculo quando seu código realmente é executado. É uma grande mudança em relação ao paradigma “sempre ligado”.

Para aplicações mais complexas que ainda requerem serviços persistentes, mas têm uma demanda flutuante, plataformas de orquestração de contêineres como Kubernetes (EKS, AKS, GKE) combinadas com uma escalabilidade inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem ajustar o tamanho de 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 à medida que a demanda muda.

Meu cliente refez partes de seu painel de análise para utilizar 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 era 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 o Sem Servidor ou Auto-Escalabilidade

Os bancos de dados são frequentemente problemáticos porque a persistência dos dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções sem servidor ou de autoescalabilidade que não estavam amplamente disponíveis há alguns anos.

• AWS Aurora Serverless v2 : É uma mudança significativa. Ela 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 uma capacidade máxima enquanto a maior parte do tempo você opera com carga base.
• Azure SQL Database Serverless : Similar ao Aurora Serverless, ele se adapta automaticamente à capacidade de computação e entra em pausa quando está ocioso, 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 consulta, sem precisar provisionar unidades de capacidade de leitura/escrita. Perfeito para padrões de tráfego imprevisíveis.

O painel de analytics originalmente utilizava 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 despencaram em quase 60%, simplesmente porque não estava mais operando em plena capacidade durante os horários de pico.

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ê 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 ocorre com os snapshots – eles se acumulam rapidamente e podem se tornar caros.

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

Você pode usar o AWS CLI para encontrar volumes não anexados e excluí-los. Esta é 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 (TENHA CUIDADO, ISSO É IRREVERSÍVEL)
# Substitua 'vol-xxxxxxxxxxxxxxxxx' pelo ID do volume real
# 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 snapshots obsoletos. Excluí-los resultou em economias de algumas centenas de dólares na fatura mensal – não é uma quantia enorme, mas cada pequena ação 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 geram taxas horárias e custos de processamento de dados. Se você tem 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 sua arquitetura permitir, consolide para menos NAT Gateways.
• Endpoints VPC : Para acessar serviços da AWS como S3 ou DynamoDB a partir do seu VPC, use Endpoints VPC. O tráfego circula de forma privada dentro da rede AWS, evitando custos das NAT Gateways e oferecendo melhor segurança.

Percebemos 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 depois 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, conscientes dos custos de forma intrínseca. Aqui estão algumas coisas que você pode começar a fazer a partir de hoje:

1. Audite Regularmente Sua Fatura na Nuvem : Torne isso um hábito. Use as ferramentas de gestão de custos do seu provedor de nuvem. Não deixe isso apenas para o setor financeiro. Entenda para onde vai cada dólar.
2. Marque Tudo : Isso é inegociável. Marcque os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se eles podem ser programados para desligamento. Isso facilita muito a identificação e automação.
3. Priorize o Desligamento Para Ambientes Não Produtivos : Os ambientes de staging, dev e QA são candidatos ideais para desligamentos programados fora do horário comercial. Geralmente, é a economia mais fácil e rápida.
4. 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 primeiro.
5. 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 autoescalonamento para sua tecnologia de banco de dados específica.
6. 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.
7. Eduque Sua Equipe : Fomente uma cultura de conscientização de custos. Certifique-se de que os desenvolvedores entendem as implicações financeiras de suas escolhas de provisionamento. Isso não é mais apenas um problema operacional.

Parar as perdas relacionadas a recursos “sempre ativos” não é uma solução pontual; é uma disciplina contínua. Mas ao fazer essas mudanças, você não só economizará uma quantia significativa de dinheiro para sua empresa, como também construirá uma infraestrutura mais ágil, resiliente e pronta para o futuro. E, francamente, isso faz de você um melhor ator na área de tecnologia.

É isso por agora. Continue construindo de forma inteligente, e nós nos encontraremos na próxima vez!

🕒 Published: April 1, 2026