Os meus custos de infraestrutura ocultos destruíram o meu orçamento.

Olá a todos, Jules Martin aqui, novamente no agntmax.com. Espero que todos estejam bem. Hoje quero falar sobre algo que tem me preocupado ultimamente, algo que vi emergir em mais conversas e post-mortem de projeto do que gostaria de admitir: a extração invisível de custos de infraestrutura não otimizados. Todos sabemos que precisamos construir rapidamente, crescer rápido e entregar funcionalidades ontem. Mas, muitas vezes, em toda essa correria, deixamos para trás um rastro de recursos esquecidos, instâncias superdimensionadas e serviços que funcionam no piloto automático, acumulando contas que mal olhamos antes que a revisão trimestral do orçamento caia como uma pedra.

Portanto, para este artigo, me aprofundarei 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 “on-demand” ou “ativados por eventos.” Estamos em 2026, pessoal. Os dias de fornecimento de servidores à la carte acabaram. Se sua conta de nuvem ainda se parece com uma lista telefônica, é hora de agir.

O Assassino Silencioso: Sempre Ligado Quando Deveria Ser On-Demand

Sejamos realistas. Quando estamos sobre pressão para lançar uma nova ferramenta para agentes ou uma melhoria no serviço 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 por garantia.” Lançamos um banco de dados com IOPS provisionados que poderiam gerenciar toda a Internet, apenas para deixar que ficasse principalmente inativo durante os horários de pico. Esquecemos de configurar políticas de escalabilidade apropriadas ou simplesmente deixamos as coisas funcionarem 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, Deus os abençoe, havia construído um sistema incrível que fornecia aos agentes panoramas em tempo real das interações com os clientes. Foi uma grande vitória em termos de performance. Mas quando chegou a primeira conta completa da nuvem, o diretor financeiro quase teve um ataque cardíaco. Eles haviam provisionado um cluster EKS robusto, algumas instâncias RDS de alta gama e uma infinidade de funções Lambda com alocações de memória generosas, todas ativas sem interrupção. A reviravolta? O painel era principalmente utilizado pelos agentes durante o horário comercial, das 9 às 17, de segunda a sexta. Fora isso, era uma cidade fantasma.

Estavam pagando por uma capacidade de nível empresarial por 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: Para Onde Realmente Vão Seus Dinheiros

Antes de poder consertar 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, Google Cloud Billing reports – não servem apenas para as finanças. Eles são sua primeira linha de defesa.

Os Costumeiros Suspeitos

• Instância de Cálculo (EC2, VMs): Estas são frequentemente os maiores 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 sem servidor que se reduzem a zero ou a um custo próximo do zero quando estão inativos.
• Armazenamento (volumes EBS, discos não anexados): Você já iniciou uma instância, a encerrou, mas deixou o volume de armazenamento associado por perto? Isso acontece mais frequentemente do que você pensa.
• Rede (Transferência de dados, NAT Gateways): Os custos de transferência de dados podem surpreendê-lo, especialmente entre regiões. Os NAT Gateways também têm um custo horário, mesmo que não estejam fazendo 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 da história do painel de análise começou olhando seu AWS Cost Explorer. As maiores despesas eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS anexados a instâncias encerradas e um NAT Gateway em uma VPC que não era mais utilizada para tráfego de produção. Coisas pequenas, mas que se acumulam.

“`html

Estrategias para Transformar Sempre Ativo em Sob Demanda (ou Fora dos Picos)

Ok, você identificou as áreas em que 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 somente 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 utilizados apenas durante o horário comercial, não há razão para funcionarem 24/7. A maioria dos provedores de cloud 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 as 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 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': 'Agendamento das instâncias EC2 concluído.'
 }

Você deve configurar 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 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 – reduzem a zero quando não são usadas, o que significa que você paga apenas pela computação 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 uma escalabilidade inteligente, são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar o tamanho dos seus pods aplicacionais 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 refez 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 em execução em um cron job, uma função Lambda era ativada por um evento S3 (novos arquivos carregados) ou por uma solicitação da API Gateway. As economias eram imediatas e significativas.

3. Dimensione Corretamente seus Bancos de Dados com Sem Servidor ou Auto-escala

Os bancos de dados são frequentemente problemáticos, pois a persistência dos 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.

“`

• AWS Aurora Serverless v2 : É uma mudança significativa. Ajusta a capacidade com base no uso real, indo de frações de uma ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que usa. Não é mais necessário prever uma capacidade de pico enquanto, na maior parte do tempo, opera com carga reduzida.
• 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 de capacidade on-demand do DynamoDB significa que você paga por cada solicitação, sem precisar prever unidades de capacidade de leitura/escrita. Perfeito para modelos de tráfego imprevisíveis.

O dashboard analítico usava inicialmente uma instância RDS PostgreSQL grande com IOPS previstas. Após a migração para Aurora Serverless v2, seus custos com o banco de dados diminuíram em quase 60%, simplesmente porque não estava mais operando em plena capacidade durante horários de baixa atividade.

4. Limpe os Armazenamentos Não Conectados 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 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 Volumes EBS Não Conectados (AWS CLI)

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

# Lista todos os volumes não conectados
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table

# Para remover um volume específico (TENHA 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 ambientes frequentemente. O cliente descobriu vários terabytes de antigos volumes EBS não conectados e centenas de snapshots obsoletos. Removê-los permitiu economizar algumas centenas de dólares na fatura mensal – não é enorme, mas cada pequeno gesto conta.

5. Otimize os Custos de Rede

As NAT Gateways são excelentes para permitir que instâncias em sub-redes privadas acessem a Internet, mas envolvem 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, você está pagando por redundâncias.

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

Notamos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles puderam consolidar e realizar economias dessa forma, e 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 Seu 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 Cloud: Faça disso um hábito. Use as ferramentas de gestão de custos do seu fornecedor de cloud. Não deixe apenas para o financeiro. Compreenda para onde vai cada real.
2. Rotule Tudo: Isso é inegociável. Rotule os recursos por projeto, proprietário, ambiente (desenvolvimento, staging, produção) e se podem ser agendados para desligamento. Isso facilita enormemente a identificação e a automação.
3. Priorize o Agendamento para Ambientes Não Produtivos: Os ambientes de staging, desenvolvimento, QA são candidatos ideais para desligamentos programados fora do horário comercial. Geralmente, é o ganho mais fácil e rápido.
4. Avalie o Serverless para Novas Cargas de Trabalho: Se você está construindo algo novo, em particular microserviços baseados em eventos ou tarefas em segundo plano, sempre considere o serverless como a primeira opção.
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 autoescalabilidade 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 utilizados, snapshots antigos e outros recursos órfãos.
7. Eduque sua Equipe: Promova uma cultura de conscientização 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.

Parar as perdas relacionadas aos 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 para sua empresa, mas também construirá uma infraestrutura mais ágil, resiliente e pronta para o futuro. E, sinceramente, isso o torna um jogador melhor no campo tecnológico.

É tudo da minha parte desta vez. Continue construindo de forma inteligente e nos vemos na próxima!

“`

🕒 Published: April 5, 2026