Olá 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 tenho visto surgir em mais conversas e post-mortem de projetos do que gostaria de admitir: a retirada invisível dos custos de infraestrutura não otimizados. Todos sabemos que é preciso construir rapidamente, evoluir rapidamente e entregar funcionalidades ontem. Mas muitas vezes, nessa pressa, deixamos para trás uma trilha de recursos esquecidos, instâncias superdimensionadas e serviços que operam em piloto automático, acumulando faturas que apenas damos uma olhada antes que a revisão trimestral do orçamento chegue como uma tonelada de tijolos.
Portanto, 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 com recursos “sempre ativos” que deveriam ser “sob demanda” ou “ativados por eventos.” Estamos em 2026, pessoal. Os dias da provisionamento de servidores sob demanda acabaram. Se sua fatura na nuvem ainda parece um catálogo telefônico, é hora de agir.
O Assassino Silencioso: Sempre Ativo 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ó por segurança.” Lançamos um banco de dados com IOPS provisionados que poderiam gerenciar toda a Internet, apenas para permanecerem em sua maioria inutilizados durante os horários de baixa movimentação. Esquecemos de configurar políticas de escalonamento apropriadas ou simplesmente deixamos as coisas funcionando 24/7 porque, bem, é mais fácil do que se preocupar com isso.
Eu vi tudo isso com meus próprios olhos há alguns meses com o novo painel de analytics interno de um cliente. A equipe, que Deus os abençoe, havia construído um sistema fantástico que fornecia aos agentes panoramas em tempo real das interações com os clientes. Foi uma grande 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 miríade de funções Lambda com alocações generosas de memória, todas operando sem interrupções. A cereja do bolo? O painel era utilizado principalmente pelos agentes durante o horário comercial, das 9:00 às 17:00, 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.
Identifique os Culpados: Para Onde Vai Realmente o Seu Dinheiro
Antes de poder consertar qualquer coisa, você precisa saber o que não está funcionando. A maioria dos provedores de nuvem oferece ferramentas para ajudá-lo 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 finanças. Eles são sua primeira linha de defesa.
Os Costumes Suspeitos
- Instância de Cálculo (EC2, VMs): Frequentemente são 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 ser superprovisionados para IOPS, CPU ou memória. Muitos agora oferecem opções serverless que caem 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, terminou-a, mas deixou o volume de armazenamento associado por aí? Isso acontece com mais frequência 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. Mesmo as NAT Gateways 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 alguns acessos por dia? Um cluster Kafka gerenciado para um fluxo de mensagens?
Meu cliente do relato sobre o painel de analytics começou observando seu AWS Cost Explorer. As maiores despesas eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS anexados a instâncias terminadas e uma NAT Gateway em uma VPC que não estava mais sendo utilizada para tráfego de produção. Coisas pequenas, mas que se acumulam.
Estratégias para Transformar Sempre Ativo em Sob Demanda (ou Fora de Pico)
Está bem, vocês identificaram as áreas onde estão gastando demais. Vamos para a parte divertida: corrigir isso. O objetivo não é só economizar dinheiro, mas construir um sistema mais resiliente e eficiente que consome recursos apenas quando realmente precisa.
1. Planejem 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 expediente, não há razão para que funcionem 24/7. A maioria dos fornecedores de nuvem oferece maneiras nativas de programar os ciclos de início das instâncias, ou vocês podem criar a sua solução com funções serverless.
Exemplo Prático: Scheduler EC2 AWS com Lambda
Vocês podem criar uma simples função Lambda 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 tag 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' configurada para '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 as instâncias em outro momento ---
# Vocês teriam 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ês deveriam 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. Adotem o Serverless e a Orquestração de Contêineres
Se a sua carga de trabalho é realmente esporádica ou ativada por eventos, o serverless é seu melhor aliado. AWS Lambda, Azure Functions, Google Cloud Functions – elas vão a zero quando não estão em uso, o que significa que você paga apenas pelo processamento 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 um escalonamento 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 utilizar Lambda para gerar alguns relatórios que eram solicitados apenas algumas vezes ao dia. Ao invés de uma instância EC2 dedicada executando um cron job, uma função Lambda era ativada por um evento S3 (novos arquivos carregados) ou por um pedido API Gateway. As economias foram imediatas e significativas.
3. Dimensionem Corretamente seus Bancos de Dados com o Serverless ou Auto-Scaling
Os bancos de dados geralmente são problemáticos, pois a persistência dos dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções serverless ou de auto-escalonamento que não estavam amplamente disponíveis há alguns anos.
- AWS Aurora Serverless v2 : É uma mudança significativa. Regula a capacidade com base no uso real, de frações de um ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que usa. Não é mais necessário provisionar para uma capacidade máxima quando, na maior parte do tempo, opera com carga normal.
- 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 on-demand do DynamoDB significa que você paga por cada solicitação, sem necessidade de provisionar unidades de capacidade de leitura/gravação. Perfeito para modelos de tráfego imprevisíveis.
O dashboard analítico utilizava inicialmente 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 diminuíram em quase 60%, simplesmente porque não funcionava mais em plena capacidade durante os horários de pico.
4. Limpe os Armazenamentos Não Conectados e os Snapshots
Pode parecer banal, mas é uma fonte constante de desperdício de dinheiro. Quando termina uma instância EC2, o volume EBS associado nem sempre é eliminado 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 Conectados (AWS CLI)
Você pode usar o AWS CLI para encontrar volumes não conectados e removê-los. É uma operação 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ê criar e remover ambientes com frequência. 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 é muito, mas cada pequeno gesto conta.
5. Otimize os Custos de Rede
As NAT Gateways são ótimas para permitir que instâncias em sub-redes privadas acessem a Internet, mas geram 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 sua arquitetura permitir, consolide para menos NAT Gateways.
- Endpoints VPC : Para acessar serviços AWS como S3 ou DynamoDB do seu VPC, use os Endpoints VPC. O tráfego circula privadamente dentro da rede AWS, evitando os custos das NAT Gateways e oferecendo maior segurança.
Notamos que o cliente tinha uma NAT Gateway em cada AZ, mesmo que sua aplicação principal funcionasse apenas em duas. Eles conseguiram consolidar e realizar economias dessa forma, e então implementaram os Endpoints VPC para acesso ao S3, reduzindo os custos de processamento de dados por meio da NAT Gateway.
Ações a Serem Tomadas para o Próximo Sprint
Não se trata apenas de reduzir os custos; trata-se de construir sistemas mais inteligentes e eficientes, intrinsecamente conscientes dos custos. Aqui está o que você pode começar a fazer imediatamente:
- Audite Regularmente sua Fatura Cloud: Faça disso um hábito. Utilize as ferramentas de gestão de custos do seu provedor de nuvem. Não deixe tudo para as finanças. Compreenda onde vai cada real.
- Rotule Tudo: Isso não é negociável. Rotule os recursos por projeto, proprietário, ambiente (desenvolvimento, staging, produção) e se podem ser programados para parar. Isso facilita enormemente a identificação e a automação.
- Dê Prioridade à Programação para Ambientes Não Produtivos: Os ambientes de staging, desenvolvimento e QA são candidatos ideais para paradas programadas fora do horário de trabalho. Esse geralmente é o caminho mais simples e rápido para economia.
- Considere o Serverless para Novas Cargas de Trabalho: Se você estiver construindo algo novo, especialmente microserviços baseados em eventos ou tarefas em segundo plano, sempre considere o serverless como a primeira opção.
- Reavalie suas Opções 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 autoescalonamento 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 conectados, snapshots obsoletos e outros recursos órfãos.
- 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. Já 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 de dinheiro para sua empresa, mas também construirá uma infraestrutura mais ágil, resiliente e preparada para o futuro. E, sinceramente, isso fará de você um ator melhor no campo tecnológico.
É tudo para mim desta vez. Continue construindo de maneira inteligente, e nos vemos na próxima!
🕒 Published: