Meus custos de infraestrutura ocultos mataram meu orçamento

Oi a todos, Jules Martin aqui, de volta em agntmax.com. Espero que todos estejam bem. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que vi surgir em mais conversas e post-mortem de projeto do que gostaria de admitir: o consumo invisível dos custos de infraestrutura não otimizados. Todos sabemos que é preciso construir rápido, escalar rapidamente e entregar funcionalidades ontem. Mas muitas vezes, nessa pressa, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços que funcionam em modo automático, acumulando faturas que mal damos uma olhada antes que a revisão do orçamento trimestral caia como uma tonelada de tijolos.

Então, para este artigo, mergulho de cabeça na 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 de provisionamento de servidores sob demanda acabaram. Se a sua fatura na nuvem ainda se parece com uma lista telefônica, é hora de agir.

O Assassino Silencioso: 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 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ó para garantir.” Lançamos um banco de dados com IOPS provisionados que poderia gerenciar toda a Internet, apenas para ver que ele fica principalmente ocioso durante as horas de pico. Esquecemos de configurar políticas de escalabilidade adequadas, ou simplesmente deixamos as coisas funcionarem 24/7 porque, bem, é mais fácil não pensar nisso.

Eu vi tudo isso com meus próprios olhos alguns meses atrás com o novo painel de análises internas 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 chegou a primeira fatura completa da nuvem, o diretor financeiro quase se aposentou de repente. Eles tinham provisionado um cluster EKS robusto, algumas instâncias RDS de alta gama e uma variedade de funções Lambda com alocações generosas de memória, todas operando incessantemente. A reviravolta? 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 na verdade estava inativo 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 o Seu Dinheiro

Antes de poder resolver qualquer coisa, você precisa saber o que está quebrado. A maioria dos fornecedores de nuvem oferece ferramentas para ajudá-lo a visualizar suas despesas, e você deve absolutamente utilizá-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 Costumes Suspeitos

• Instância de Cálculo (EC2, VMs): Esses são frequentemente os principais culpados. Estão superdimensionados? 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 para o cálculo, os bancos de dados podem ser superprovisionados para IOPS, CPU ou memória. Muitos agora oferecem opções serverless que caem para zero ou um custo próximo a zero quando estão inativos.
• Armazenamento (volumes EBS, discos não conectados): Você já iniciou uma instância, a encerrou, mas deixou o volume de armazenamento associado pendente? Isso acontece mais frequentemente do que você pensa.
• Networking (Transferência de dados, Gateway NAT): Os custos de transferência de dados podem surpreendê-lo, especialmente entre regiões. Os Gateways NAT também têm um custo horário, 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 um fluxo de mensagens?

Meu cliente do relato do painel de análises começou a olhar para seu AWS Cost Explorer. As maiores entradas de custo eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS conectados a instâncias encerradas e um Gateway NAT em uma VPC que não estava mais sendo usada para tráfego de produção. Coisas pequenas, mas que somam.

“`html

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

Está bem, você identificou os setores em que está gastando demais. Vamos passar para a parte divertida: corrigir 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

É 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 maneiras nativas de agendar ciclos de alimentação 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 ativada 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 serem paradas/iniciadas
 # Por exemplo, 'Schedule': 'business-hours'
 
 # Recuperar 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 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 CloudWatch: uma para acionar esta Lambda, digamos, às 18:00 UTC para parar as instâncias, e outra às 7:00 UTC para iniciá-las. Isso sozinho 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 ativada por eventos, o sem servidor é seu melhor aliado. 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 pela computação quando seu código é realmente executado. É uma mudança enorme em relação ao paradigma “sempre ligado”.

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 uma escalabilidade inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar 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 reestruturou partes de seu painel de análises 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 executa um cron job, uma função Lambda era ativada por um evento S3 (novos arquivos carregados) ou por uma solicitação do API Gateway. As economias foram imediatas e significativas.

3. Dimensione Corretamente Seus Bancos de Dados com o Sem Servidor ou a Auto- escalabilidade

Bancos de dados são frequentemente problemáticos porque a persistência de dados é crítica. 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.

“““html

• AWS Aurora Serverless v2 : É uma mudança significativa. Regula 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 projetar uma capacidade de pico quando na maioria do tempo opera com carga base.
• Azure SQL Database Serverless : Semelhante ao Aurora Serverless, adapta-se automaticamente à capacidade de computação e entra em pausa quando está inativo, realizando economias significativas para cargas de trabalho intermitentes.
• DynamoDB On-Demand : Para cargas de trabalho NoSQL, o modo sob demanda do DynamoDB significa que você paga por cada solicitação, sem precisar projetar unidades de capacidade de leitura/escrita. Perfeito para padrões de tráfego imprevisíveis.

O dashboard analítico utilizava inicialmente uma instância RDS PostgreSQL grande com IOPS projetadas. Após a migração para o Aurora Serverless v2, os custos do banco de dados diminuíram em quase **60%**, simplesmente porque não estava mais funcionando a plena carga durante os horários de pico.

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

Isso pode parecer básico, mas é uma fonte constante de desperdício de dinheiro. Quando você finaliza uma instância EC2, o volume EBS associado nem sempre é excluído por padrão, especialmente se for 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 Associados (AWS CLI)

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

# Lista todos os volumes não associados
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 do volume real
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Automatize isso com uma função Lambda programada se você criar e excluir frequentemente ambientes. O cliente descobriu vários terabytes de velhos volumes EBS não associados e centenas de snapshots obsoletos. Removê-los resultou em economias de centenas de dólares na fatura 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 for ativamente utilizada, você pagará por redundâncias.

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

Descobrimos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles conseguiram consolidar e economizar dessa forma, depois implementaram os Endpoints VPC para acesso ao S3, reduzindo os custos de processamento de dados através da NAT Gateway.

Ações a Serem Tomadas para o Próximo Sprint

Não se trata apenas de redução de custos; trata-se de construir sistemas mais inteligentes e eficientes, intrinsecamente conscientes dos custos. Aqui está o que você pode começar a fazer a partir de hoje :

“`

1. Audite Regularmente sua Fatura Cloud: Torne isso um hábito. Use as ferramentas de gestão de custos do seu provedor de cloud. Não deixe tudo apenas nas mãos das finanças. Entenda 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 desligar. Isso facilita muito a identificação e a automação.
3. Priorize a Programação 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. Esse é geralmente o ganho mais fácil e rápido.
4. Avalie o Serverless para Novas Cargas de Trabalho: Se você está construindo algo novo, especialmente microserviços baseados em eventos ou tarefas de backend, sempre considere primeiro o serverless.
5. Reavalie suas Escolhas de Banco de Dados: Se você tem bancos de dados que funcionam 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.
6. Automatize a Limpeza: Implemente scripts automatizados ou funções serverless para identificar e remover volumes de armazenamento não associados, snapshots antigos e outros recursos órfãos.
7. Eduque sua Equipe: Promova uma cultura de consciência de custos. Certifique-se de que os desenvolvedores compreendam as implicações financeiras de suas escolhas de provisionamento. Não é mais apenas um problema operacional.

Conter as perdas relacionadas a recursos “sempre ativos” não é uma solução temporária; é uma disciplina contínua. Mas ao fazer 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 pronta para o futuro. E, sinceramente, isso faz de você um agente melhor no campo tecnológico.

É tudo por mim desta vez. Continue a construir de forma inteligente, e nos veremos na próxima!

🕒 Published: April 5, 2026