Meus gastos com nuvem estão muito altos: O que estou vendo agora

Olá a todos, Jules Martin aqui, de volta ao agntmax.com!

Hoje, quero falar sobre algo que tem me incomodado, e provavelmente a muitos de vocês, no último ano: o aumento crescente do custo da infraestrutura em nuvem, especialmente quando se trata de funções serverless. Todos nós fomos convencidos pelo sonho do “pague pelo que usa”, e por muito tempo, isso parecia uma realidade. Mas ultimamente, tenho visto as contas subirem, às vezes inexplicavelmente, mesmo quando os padrões de tráfego parecem estáveis. É como se estivéssemos sendo cobrados aos poucos pela flexibilidade que adotamos. Então, vamos explorar algo muito específico e oportuno: Domando o Monstro Serverless: Desmascarando e Cortando Custos Ocultos do AWS Lambda.

Minha própria jornada nisso começou há cerca de seis meses. Temos um microserviço central que lida com autenticação de usuários e gerenciamento de sessões. Ele é construído quase inteiramente no AWS Lambda, API Gateway, DynamoDB e Cognito. Por muito tempo, os custos eram perfeitamente previsíveis. Então, no último verão, nossa conta da AWS para esse serviço específico subiu cerca de 15%. Sem novas funcionalidades, sem picos de tráfego significativos. Inicialmente, atribuí isso a alguma flutuação sazonal ou um bug menor que ainda não havia encontrado. Mas quando a conta do mês seguinte veio ainda mais alta, eu sabia que precisava investigar. Não era apenas um pico; era uma tendência, e estava nos custando dinheiro de verdade.

A Ilusão dos Níveis “Grátis” e a Realidade das Invocações “Pequenas”

Um dos maiores pontos de venda do serverless, especialmente para startups ou equipes menores, é o generoso nível gratuito. E é generoso! Um milhão de invocações grátis por mês para o Lambda, além de uma quantidade significativa de tempo de computação. O problema é que, à medida que sua aplicação cresce, essas invocações “grátis” desaparecem mais rápido do que uma fatia de pizza em uma reunião de tecnologia. O que muitas vezes passa despercebido é o enorme volume de pequenas invocações, aparentemente insignificantes, que se acumulam. Pense em jobs cron, checagens internas de saúde ou mesmo mecanismos de repetição de outros serviços. Cada uma delas conta.

Minha investigação sobre nosso serviço de autenticação revelou exatamente isso. Tínhamos uma função Lambda, vamos chamá-la de auth-token-refresher, projetada para atualizar periodicamente os tokens de serviço internos. Ela estava configurada para rodar a cada cinco minutos. Parece inofensivo, certo? 288 invocações por dia. Multiplique isso por 30 dias, e você obtém 8.640 invocações por mês. Adicione nossos ambientes de desenvolvimento, teste e produção, e de repente isso passa de 25.000 invocações apenas para uma pequena tarefa de manutenção. Tínhamos uma dúzia de tais funções. De repente, nossas invocações “pequenas” não eram mais tão pequenas.

Encontrando os Culpados: Métricas do CloudWatch são Seus Melhores Amigos

O primeiro passo para domar essa fera é saber aonde seu dinheiro está indo. O AWS CloudWatch é indispensável aqui. Não olhe apenas para o painel de cobrança de alto nível; explore as métricas específicas para suas funções Lambda.

Veja o que eu foquei:

1. Invocações: Essa é a métrica mais simples. Contagens altas de invocações para funções que não lidam com tráfego direto de usuários são bandeiras vermelhas imediatas.
2. Duração: Quanto tempo cada invocação está rodando? Durações mais longas significam maiores custos de computação.
3. Uso de Memória: Você está alocando memória demais para suas funções? Você paga pelo que aloca, não pelo que usa.
4. Taxa de Erros: Altas taxas de erros podem levar a repetições, o que significa mais invocações e ciclos de computação desperdiçados.

Para nosso auth-token-refresher, olhei para sua métrica `Invocations`. E claro, ela estava rodando como um relógio, a cada cinco minutos. A duração era mínima, apenas cerca de 50ms. Mas o volume estava contribuindo para o nosso custo total de invocações.

Exemplo Prático 1: Consolidando e Agendando de Forma Mais Inteligente

A solução para auth-token-refresher e várias outras funções de manutenção semelhantes foi surpreendentemente simples: consolidação. Em vez de ter funções Lambda individuais acionadas por eventos do CloudWatch (ou EventBridge nos dias de hoje) em cronogramas separados, criei uma única função Lambda chamada “Manutenção Runner”.

Esse “Manutenção Runner” é acionado por uma única regra de evento do CloudWatch, digamos, uma vez por hora. Dentro desse runner, eu tenho um despachante simples que verifica a hora atual e executa as tarefas necessárias. Por exemplo:

import os
import datetime

def lambda_handler(event, context):
 current_hour = datetime.datetime.now().hour
 current_minute = datetime.datetime.now().minute

 # Tarefa 1: Atualizar token de autenticação (estava rodando a cada 5 mins)
 if current_minute % 10 == 0: # Agora roda a cada 10 minutos
 print("Executando atualização de token de autenticação...")
 # Chama a lógica real de atualização de token ou outra função interna
 refresh_auth_token()

 # Tarefa 2: Limpar logs antigos (estava rodando a cada hora)
 if current_hour % 1 == 0 and current_minute == 0: # Roda no início da hora
 print("Executando limpeza de logs...")
 cleanup_old_logs()

 # Tarefa 3: Verificar status de serviço externo (estava rodando a cada 30 mins)
 if current_minute == 0 ou current_minute == 30:
 print("Verificando status de serviço externo...")
 check_external_service()

 return {
 'statusCode': 200,
 'body': 'Tarefas de manutenção executadas.'
 }

def refresh_auth_token():
 # ... lógica real de atualização de token ...
 pass

def cleanup_old_logs():
 # ... lógica real de limpeza de logs ...
 pass

def check_external_service():
 # ... lógica real de verificação de serviço externo ...
 pass

Essa simples mudança imediatamente reduziu a contagem de invocações para essas tarefas de manutenção de centenas de milhares por mês para algumas milhares. As economias foram tangíveis, não apenas em invocações do Lambda, mas também na ingestão de logs do CloudWatch e chamadas do API Gateway (se alguma dessas funções foi exposta via API Gateway).

A Armadilha da Sobrealocação de Memória

Este é outro fator de custo sutil que muitas vezes é ignorado. Quando você cria uma função Lambda, você aloca uma certa quantidade de memória (por exemplo, 128MB, 256MB, 512MB). Você paga por essa memória alocada, independentemente de quanto sua função realmente usa. Além disso, o poder da CPU escala proporcionalmente com a alocação de memória. Portanto, se você alocar 1GB de memória para um simples script Python que só precisa de 128MB, você não está apenas pagando demais pela memória; você também está pagando demais pelos ciclos de CPU que não precisa.

Aprendi isso da maneira mais difícil com um Lambda de processamento de dados que foi inicialmente configurado com 1GB de memória “apenas por precaução.” Quando olhei suas métricas do CloudWatch para uso de memória, ele consistentemente ficou abaixo de 200MB, mesmo durante cargas máximas. Estávamos essencialmente pagando por 800MB de RAM não utilizada e o aumento correspondente de CPU.

Exemplo Prático 2: Otimizando Alocação de Memória com Lambda Power Tuning

Descobrir manualmente a configuração de memória ideal pode ser tedioso. Você precisa implantar, testar, monitorar, ajustar e repetir. Felizmente, existe uma ferramenta open-source fantástica chamada AWS Lambda Power Tuning (desenvolvida por Alex Casalboni na AWS) que torna esse processo muito mais fácil.

É uma aplicação serverless que ajuda você a visualizar e identificar a configuração de memória ideal para suas funções Lambda com base em custo e desempenho. Você a implanta em sua conta AWS e depois pode usá-la para testar suas funções.

Veja como funciona de maneira geral:

1. Você implanta a ferramenta Power Tuning via Serverless Application Repository ou SAM.
2. Você invoca uma máquina de estados (criada pela ferramenta) com o ARN da sua função Lambda e um payload.
3. A máquina de estados invoca seu Lambda várias vezes com diferentes configurações de memória (por exemplo, 128MB, 256MB, 512MB, 1024MB, etc.).
4. Então, ela analisa os logs de execução e fornece uma visualização mostrando as trocas entre custo e velocidade para cada configuração de memória.

Para meu Lambda de processamento de dados, rodá-lo através do Power Tuner mostrou que 256MB era o ponto ideal para custo, com degradação de desempenho insignificante em comparação com 1GB. Imediatamente reduzi a alocação de memória para 256MB, resultando em uma redução de 75% no custo de computação para essa função específica. Isso não foi uma exceção; desde então, transformei isso em uma prática padrão rodar novas funções ou funções reavaliadas através dessa ferramenta.

Para usá-la, após a implantação, você normalmente começaria a máquina de estados com algo assim (ajustando o ARN e o payload):

aws stepfunctions start-execution \
 --state-machine-arn "arn:aws:states:REGION:ACCOUNT_ID:stateMachine:powerTuningStateMachine" \
 --input '{ "lambdaARN": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_FUNCTION_NAME", "num": 100, "payload": {}, "parallel": 5 }'

A saída fornece um gráfico claro, mostrando exatamente onde seu custo e velocidade se cruzam para desempenho ótimo. É uma mudança significativa para a otimização de custos.

Verborragia de Logs e Inícios Frios

DuAs outras áreas que muitas vezes surgem sem aviso são a verborragia de logs e inícios frios. Os logs do CloudWatch não são gratuitos. Cada linha que sua função Lambda imprime é ingerida e armazenada, e você paga por isso. Embora um bom registro seja crucial para depuração, uma logação excessiva (por exemplo, imprimir objetos inteiros ou repetir mensagens de status desnecessariamente) pode rapidamente inflacionar sua conta de logs do CloudWatch.

Encontrei algumas funções que estavam registrando o corpo completo da requisição HTTP em cada invocação. Embora útil para o desenvolvimento inicial, em produção, isso era apenas ruído e custo. Um ajuste rápido para registrar apenas os metadados essenciais (ID da requisição, código de status, endpoint) reduziu drasticamente nossa ingestão de logs.

Os cold starts, embora não sejam um “custo” direto da mesma forma, impactam a experiência do usuário e podem levar indiretamente a mais tentativas ou durações de cobrança mais longas se sua função tiver que esperar por recursos. Embora a AWS tenha feito avanços significativos na redução dos tempos de cold start, otimizar o tamanho do pacote da sua função e evitar lógica de inicialização complexa fora do manipulador ainda pode fazer a diferença. Para funções críticas e sensíveis à latência, a concorrência provisionada é uma opção, mas esteja ciente de que você paga por essa concorrência alocada mesmo quando está ociosa.

Exemplo Prático 3: Registro Inteligente e Variáveis de Ambiente

Para registro, a solução mais simples é muitas vezes a melhor. Use variáveis de ambiente para controlar os níveis de log. Em Python, por exemplo, você pode fazer o seguinte:

import os
import logging

LOG_LEVEL = os.environ.get('LOG_LEVEL', 'INFO').upper()
logging.basicConfig(level=LOG_LEVEL)
logger = logging.getLogger()

def lambda_handler(event, context):
 logger.debug("Esta é uma mensagem de debug, visível apenas se LOG_LEVEL for DEBUG")
 logger.info("Processando evento: %s", event.get('request_id'))
 try:
 # ... lógica da função ...
 logger.debug("Terminado o processamento para request_id: %s", event.get('request_id'))
 return {
 'statusCode': 200,
 'body': 'Sucesso'
 }
 except Exception as e:
 logger.error("Erro ao processar request_id %s: %s", event.get('request_id'), str(e), exc_info=True)
 return {
 'statusCode': 500,
 'body': 'Erro'
 }

Ao definir LOG_LEVEL como INFO em produção e DEBUG em desenvolvimento/teste, você pode reduzir significativamente sua fatura do CloudWatch Logs sem sacrificar a observabilidade quando precisar.

Outro truque é estar atento ao que é inicializado fora do manipulador. Qualquer código diretamente no escopo global da sua função Lambda será executado durante o cold start. Se você tiver operações caras, como conexão em pool com o banco de dados ou grandes importações de bibliotecas, considere adiá essas operações até que elas sejam realmente necessárias dentro do manipulador, ou certifique-se de que estão sendo eficientemente armazenadas em cache para invocações quentes subsequentes.

Principais Aprendizados para sua Cruzada de Redução de Custos Serverless

Certo, então cobrimos bastante coisa. Aqui está um resumo de passos práticos que você pode tomar agora para começar a diminuir aqueles custos traiçoeiros do Lambda:

• Monitore incessantemente: Não basta apenas dar uma olhada na sua fatura geral da AWS. Explore as métricas do CloudWatch para Invocations, Duration e Memory Usage de todas as funções Lambda. Configure alarmes para picos inesperados.
• Consolide tarefas agendadas: Se você tem muitas pequenas funções Lambda agendadas, considere combiná-las em um único “Maintenance Runner” que despacha tarefas com uma programação menos frequente. Isso reduz drasticamente as contagens de invocação.
• Otimize a alocação de memória: Use ferramentas como AWS Lambda Power Tuning para encontrar a configuração de memória ideal para suas funções. Não apenas adivinhe e superprovisione. Lembre-se, mais memória significa mais CPU, e você paga por ambas.
• Controle a verbosidade dos logs: Implemente níveis de log acionados por variáveis de ambiente (por exemplo, INFO para produção, DEBUG para desenvolvimento). Evite registrar corpos de solicitação inteiros ou estados internos excessivos em produção. Sua fatura do CloudWatch Logs agradecerá.
• Revise funções não utilizadas: Audite suas funções Lambda periodicamente. Existem funções antigas, experimentais ou depreciadas ainda ativas e gerando custos? Delete-as!
• Fique de olho no tamanho dos pacotes: Pacotes de implantação menores significam cold starts mais rápidos e menor custo de armazenamento. Inclua apenas as dependências necessárias.
• Entenda seu modelo de preços: Leia novamente a página de preços do Lambda. Entenda como as invocações, GB-segundos e transferência de dados são cobrados. Conhecimento é poder, especialmente quando se trata da sua carteira.

Dominar o monstro serverless não é evitar o serverless; é ser inteligente e intencional sobre como o usamos. A flexibilidade e escalabilidade são inestimáveis, mas sem a devida vigilância, aqueles “custos pequenos” podem somar uma parte significativa do seu orçamento. Vá em frente, monitore, otimize e economize!

Isso é tudo por hoje. Me avise nos comentários se você tiver outras dicas ou truques para otimização de custos do Lambda!

🕒 Published: April 1, 2026