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 pós-mortem de projeto do que gostaria de admitir: a retirada invisível dos custos de infraestrutura não otimizados. Todos sabemos que precisamos construir rapidamente, escalar rápido e entregar funcionalidades ontem. Mas, muitas vezes, nessa correria, deixamos um rastro de recursos esquecidos, instâncias superdimensionadas e serviços que funcionam em modo automático, acumulando faturas nas quais mal olhamos antes que a revisão orçamentária trimestral chegue como uma pedra.
Assim, 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 evento”. Estamos em 2026, pessoal. Os dias de configuração 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
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ó para garantir.” Lançamos um banco de dados com IOPS provisionados que poderiam suportar toda a Internet, apenas para que fique em grande parte ocioso durante os horários de pico. Esquecemos de configurar políticas de escalonamento adequadas, ou simplesmente deixamos as coisas funcionando 24 horas por dia, 7 dias por semana, 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álise interna de um cliente. A equipe, que Deus os abençoe, tinha construído um sistema fantástico que fornecia aos agentes panorâmicas 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. Eles haviam provisionado um cluster EKS robusto, algumas instâncias RDS de alta gama e uma miríade de funções Lambda com alocações de memória generosas, todas funcionando ininterruptamente. O plot twist? O painel era utilizado principalmente pelos agentes durante o horário comercial, das 9h às 17h, de segunda a sexta. Fora isso, era uma cidade fantasma.
Pagavam por uma capacidade de nível enterprise 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 Realmente Vai Seu Dinheiro
Antes de poder consertar algo, é necessário saber o que está quebrado. A maioria dos fornecedores de nuvem oferece ferramentas para ajudá-lo a visualizar suas despesas, e você absolutamente deve usá-las. AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports – não servem apenas para finanças. Elas são sua primeira linha de defesa.
Os Costumes Suspeitos
- Instâncias de Cálculo (EC2, VMs): Muitas vezes são os maiores culpados. Estão superdimensionadas? Funcionam quando não deveriam? Você está utilizando a família de instâncias certa para sua carga de trabalho?
- Bancos de Dados (RDS, Azure SQL, Cloud SQL): Assim como para o cálculo, os bancos de dados podem ser sobreprovisionados para IOPS, CPU ou memória. Muitos agora oferecem opções sem servidor que reduzem a zero ou a um custo quase zero quando estão ociosos.
- Armazenamento (volumes EBS, discos não conectados): Você já lançou uma instância, a encerrou, mas deixou o volume de armazenamento associado vagando? Acontece mais frequentemente 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ê paga 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. Os maiores itens de despesa eram, previsivelmente, EC2 e RDS. Eles também encontraram alguns volumes EBS conectados a instâncias encerradas e uma NAT Gateway em uma VPC que não era mais utilizada para tráfego de produção. Pequenas coisas, 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 à parte divertida: resolvê-lo. O objetivo não é apenas 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 simples 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 funcionarem 24 horas por dia, 7 dias por semana. 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 função Lambda simples 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 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 pode por si só reduzir os custos de computação em mais de 70% para esses recursos específicos.
2. Adotem 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 – eles reduzem 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 ativo”.
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 um escalonamento inteligente são poderosas. Os Horizontal Pod Autoscalers (HPA) podem variar o tamanho de seus pods aplicacionais com base no uso da CPU ou em métricas personalizadas. Os Cluster Autoscalers podem até adicionar ou remover nós do seu cluster conforme a demanda muda.
Meu cliente reestruturou partes do seu painel de análise para usar Lambda para gerar alguns relatórios 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 por uma solicitação do API Gateway. As economias foram imediatas e significativas.
3. Dimensionem Corretamente seus Bancos de Dados com o Sem Servidor ou a Auto-Escala
Esses são frequentemente problemáticos, já que a persistência dos dados é crítica. No entanto, muitos bancos de dados modernos oferecem opções sem servidor ou de auto-escalonamento 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, desde frações de um ACU (Unidade de Capacidade Aurora) até centenas, e você paga apenas pelo que utiliza. Não é mais necessário provisionar para uma capacidade de pico quando a maior parte do tempo opera com carga reduzida.
- Azure SQL Database Serverless : Semelhante ao Aurora Serverless, adapta-se automaticamente à capacidade de computação e 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 precisar provisionar unidades de capacidade de leitura/escrita. Perfeito para padrões de tráfego imprevisíveis.
O painel analítico inicialmente utilizava uma instância RDS PostgreSQL de grandes dimensões com IOPS provisionadas. Após a migração para o Aurora Serverless v2, os custos de banco de dados diminuíram em quase 60%, simplesmente porque não operava mais em plena capacidade durante as horas 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 é eliminado por padrão, especialmente se era um volume não raiz. O mesmo se aplica aos 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 eliminar um volume específico (ATENÇÃO, É IRREVERSÍVEL)
# Substitua 'vol-xxxxxxxxxxxxxxxxx' pelo ID real do volume
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx
Automatize essa operação com uma função Lambda programada se você criar e remover ambientes com frequência. O cliente descobriu vários terabytes de volumes EBS antigos não conectados e centenas de snapshots obsoletos. Removê-los permitiu uma economia de algumas centenas de reais na fatura mensal – não é enorme, 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 acarretam custos horários e despesas de tratamento de dados. Se você tiver várias NAT Gateways em diferentes zonas de disponibilidade, mas apenas uma estiver sendo usada ativamente, você está pagando pela redundância.
- Consolide as NAT Gateways : Se a 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 os Endpoints VPC. O tráfego se move de forma privada dentro da rede AWS, evitando os custos das NAT Gateways e oferecendo maior segurança.
Constatamos 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, e em seguida implementaram os Endpoints VPC para acesso ao S3, o que reduziu os custos de tratamento de dados através da NAT Gateway.
Ações a Serem Realizadas 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:
“`
- Audite Regularmente Sua Fatura de Cloud: Torne isso um hábito. Utilize as ferramentas de gerenciamento de custos do seu provedor de cloud. Não deixe isso apenas para os financiadores. Entenda para onde vai cada real.
- Marque Tudo: Isso é inegociável. Marque os recursos por projeto, proprietário, ambiente (dev, staging, prod) e se podem ser programados para desligamento. Isso torna muito mais fácil a identificação e a automação.
- Priorize a Programação para Ambientes Não Produtivos: Os ambientes de staging, dev, QA são candidatos ideais para interrupções programadas fora do horário de trabalho. Este geralmente é o ganho mais fácil e rápido.
- Considere 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 como a primeira opção.
- Reavalie Suas Escolhas de Banco de Dados: Se você tem bancos de dados ativos 24/7 com cargas muito variáveis, examine as opções serverless ou de auto-scalabilidade para a 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 antigos e outros recursos órfãos.
- 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. Isso não é mais apenas um problema das operações.
Parar as perdas relacionadas a recursos “sempre ativos” não é uma solução única; é 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, francamente, isso o torna um jogador melhor no campo tecnológico.
É tudo por minha parte desta vez. Continue construindo de forma inteligente e nos vemos na próxima!
🕒 Published: