Le minhas faturas Cloud estão muito altas: o que vejo agora

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

Hoje quero falar sobre algo que me preocupa, e provavelmente preocupa muitos de vocês, há cerca de um ano: o aumento constante dos custos da infraestrutura em nuvem, especialmente no que diz respeito às funções sem servidor. Todos nós fomos atraídos pelo sonho do “pague pelo que usar”, e por muito tempo, pareceu ser uma realidade. Mas ultimamente, tenho visto as faturas subirem, às vezes de maneira incompreensível, mesmo quando os modelos de tráfego pareciam estáveis. É como se fôssemos erodidos pela mesma flexibilidade que adotamos. Então, vamos explorar algo muito específico e atual: Dominar o Monstro Sem Servidor: Descobrir e Reduzir os Custos Ocultos do AWS Lambda.

Meu caminho nesse campo começou há cerca de seis meses. Temos um microserviço central que gerencia a autenticação de usuários e o gerenciamento de sessões. Está quase totalmente construído sobre AWS Lambda, API Gateway, DynamoDB e Cognito. Por um longo tempo, os custos eram perfeitamente previsíveis. Então, no verão passado, nossa fatura AWS para esse serviço específico aumentou cerca de 15%. Sem novos recursos, sem picos de tráfego significativos. No início, atribuí isso a uma flutuação sazonal ou a um pequeno bug que eu ainda não havia descoberto. Mas quando a fatura do mês seguinte chegou ainda mais alta, percebi que precisava investigar. Não era apenas um incidente isolado; era uma tendência, e estava realmente nos custando dinheiro.

A Ilusão dos Níveis “Gratuitos” e a Realidade das Invocações “Mínimas”

Um dos principais atrativos das soluções sem servidor, especialmente para startups ou pequenas equipes, é o generoso nível gratuito. E é generoso! Um milhão de invocações gratuitas por mês para Lambda, além de uma quantidade significativa de tempo de computação. O problema é que, à medida que sua aplicação cresce, essas invocações “gratuitas” desaparecem mais rápido do que uma fatia de pizza em um meetup de tecnologia. O que muitas vezes é negligenciado são o volume considerável de invocações mínimas, aparentemente insignificantes, que se acumulam. Pense nas tarefas cron, nas verificações de saúde internas ou até mesmo nos mecanismos de repetição de outros serviços. Cada uma dessas invocações 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 programada para ser executada a cada cinco minutos. Parece inofensiva, certo? 288 invocações por dia. Multiplique por 30 dias e você obtém 8.640 invocações por mês. Adicione nossos ambientes de desenvolvimento, staging e produção, e de repente se tornam mais de 25.000 invocações apenas para uma pequena tarefa de manutenção. Tínhamos uma dúzia dessas funções. De repente, nossas invocações “mínimas” não eram mais tão mínimas.

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

O primeiro passo para domar essa besta é saber para onde vai seu dinheiro. AWS CloudWatch é essencial aqui. Não se limite a olhar o painel de faturamento em um nível alto; explore as métricas específicas para suas funções Lambda.

Aqui está em que me concentrei:

1. Invoações: Esta é a métrica mais simples. Contadores de invocação elevados para funções que não gerenciam tráfego de usuários diretos são sinais de alerta imediatos.
2. Duração: Quanto tempo leva cada invocação? Durações mais longas significam custos de computação mais elevados.
3. Uso de Memória: Você superprovisionou memória para suas funções? Você paga pelo que aloca, não pelo que usa.
4. Taxa de Erro: Taxas de erro elevadas podem levar a repetições, o que significa mais invocações e ciclos de computação desperdiçados.

Para nosso auth-token-refresher, examinei sua métrica `Invocações`. De fato, funcionava como um relógio, a cada cinco minutos. A duração era mínima, apenas cerca de 50 ms. Mas o volume considerável contribuía para nosso custo total de invocação.

Exemplo Prático 1: Consolidar e Planejar de Maneira mais Inteligente

A solução para auth-token-refresher e várias outras funções de manutenção semelhantes era surpreendentemente simples: a consolidação. Em vez de ter funções Lambda individuais ativadas por eventos do CloudWatch (ou EventBridge hoje em dia) em horários separados, criei uma única função Lambda chamada “Maintenance Runner”.

“`html

Este “Maintenance Runner” é ativado por uma única regra de evento CloudWatch, digamos, uma vez por hora. Dentro deste runner, tenho um simples dispatch 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 o token de autenticação (executado a cada 5 minutos)
 if current_minute % 10 == 0: # Executar agora a cada 10 minutos
 print("Executando a atualização do token de autenticação...")
 # Chamar a lógica real para atualizar o token ou outra função interna
 refresh_auth_token()

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

 # Tarefa 3: Verificar o estado do serviço externo (executado a cada 30 minutos)
 if current_minute == 0 or current_minute == 30:
 print("Verificando o estado do serviço externo...")
 check_external_service()

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

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

def cleanup_old_logs():
 # ... lógica real para a limpeza dos logs ...
 pass

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

Essa mudança simples reduziu imediatamente o número de invocações para essas tarefas de manutenção de centenas de milhares por mês para alguns milhares. As economias foram tangíveis, não apenas em termos de invocações Lambda, mas também em relação à ingestão dos logs do CloudWatch e às chamadas ao API Gateway (se uma dessas chamadas estivesse exposta através do API Gateway).

O Truque do Superdimensionamento da Memória

Isso representa outro fator de custo sutil que geralmente é negligenciado. Ao criar 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 utiliza. Além disso, o poder da CPU aumenta proporcionalmente à alocação de memória. Portanto, se você alocar 1GB de memória para um simples script Python que precisa apenas 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 são necessários.

Aprendi essa lição por experiência própria com uma função Lambda de processamento de dados que estava inicialmente configurada com 1GB de memória “apenas por segurança”. Quando eu verifiquei suas métricas do CloudWatch para uso da memória, ela permanecia constantemente abaixo de 200MB, mesmo durante picos de carga. Fundamentalmente, estávamos pagando por 800MB de RAM não utilizada e o correspondente aumento da CPU.

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

Determinar manualmente a configuração de memória ideal pode ser tedioso. Você precisa distribuir, testar, monitorar, modificar e repetir. Felizmente, existe uma ótima ferramenta de código aberto chamada AWS Lambda Power Tuning (desenvolvida por Alex Casalboni na AWS) que facilita esse processo.

Trata-se de uma aplicação sem servidor que ajuda você a visualizar e identificar a configuração de memória ideal para suas funções Lambda com base em custos e desempenho. Você a distribui em sua conta AWS e pode usá-la para testar suas funções.

Segue como funciona geralmente:

1. Distribua a ferramenta Power Tuning através do Serverless Application Repository ou SAM.
2. 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 sua Lambda várias vezes com diferentes configurações de memória (por exemplo, 128MB, 256MB, 512MB, 1024MB, etc.).
4. Em seguida, analisa os logs de execução e fornece uma visualização que mostra os compromissos entre custos e velocidade para cada configuração de memória.

Para minha função Lambda de processamento de dados, o teste com o Power Tuner mostrou que 256 MB era um compromisso ideal para o custo, com uma degradação de desempenho insignificante em relação a 1 GB. Imediatamente reduzimos a alocação de memória para 256 MB, o que resultou em uma redução de 75% nos custos de computação para esta função específica. Não foi uma solução única; desde então, garanti que se tornasse uma prática padrão passar novas funções ou aquelas reavaliadas através dessa ferramenta.

Para utilizá-la, após o deployment, normalmente você iniciaria a máquina de estados com algo similar (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 }'

O output fornece um gráfico claro, mostrando exatamente onde seus custos e sua velocidade se cruzam para um desempenho ideal. É uma mudança significativa para a otimização de custos.

A Verbosidade dos Logs e os Démarrages a Froid

Duass áreas adicionais que muitas vezes surpreendem são a verbosidade dos logs e os démarrages a froid. Os logs do CloudWatch não são gratuitos. Cada linha impressa pela sua função Lambda é registrada e armazenada, e você paga por isso. Embora um bom log seja crucial para a depuração, um registro excessivamente verboso (por exemplo, imprimir objetos inteiros ou repetir desnecessariamente mensagens de estado) pode rapidamente inflar sua fatura pelos logs do CloudWatch.

Eu encontrei algumas funções que registravam o corpo completo da requisição HTTP a cada invocação. Embora isso fosse útil para o desenvolvimento inicial, em produção se revelava apenas barulho e custo. Um rápido ajuste para registrar apenas os metadados essenciais (ID da requisição, código de status, endpoint) reduziu consideravelmente nosso registro dos logs.

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

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

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

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("Este é uma mensagem de debug, visível apenas se LOG_LEVEL for DEBUG")
 logger.info("Processando o evento: %s", event.get('request_id'))
 try:
 # ... lógica da função ...
 logger.debug("Terminou de processar 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'
 }

Ajustando LOG_LEVEL para INFO em produção e DEBUG em desenvolvimento/staging, você pode reduzir consideravelmente sua fatura pelos logs do CloudWatch sem sacrificar a observabilidade quando você precisa.

Outro conselho é prestar atenção ao que está sendo inicializado fora do handler. Qualquer código diretamente no escopo global da sua função Lambda será executado durante o démarrage a froid. Se você tem operações custosas como pooling de conexões ao banco de dados ou importações de grandes bibliotecas, considere adiá-las até que sejam realmente necessárias no handler, ou certifique-se de que elas sejam armazenadas em cache de forma eficiente para as invocações quentes subsequentes.

Ações Concretas para a Sua Cruzada de Custos Serverless

Ok, cobrimos muitas coisas. Aqui está um resumo das ações práticas que você pode tomar imediatamente para começar a reduzir esses insidiosos custos Lambda:

“`html

• Monitora incessantemente: Não se limite a dar uma olhada na sua fatura global da AWS. Explore as métricas do CloudWatch para as Invocações, a Duração e o Uso de Memória para todas as funções Lambda. Configure alarmes para picos inesperados.
• Consolide os trabalhos cron: Se você tem muitas pequenas funções Lambda agendadas, considere agrupá-las em um único “Mantenedor” que distribui as tarefas em um horário menos frequente. Isso reduz significativamente o número de invocações.
• Otimize a alocação de memória: Utilize ferramentas como AWS Lambda Power Tuning para encontrar a configuração de memória ideal para suas funções. Não se limite a adivinhar e superdimensionar. Lembre-se de que mais memória significa mais CPU, e você paga por ambas.
• Verifique a verbosidade dos logs: Implemente níveis de registro guiados por variáveis de ambiente (por exemplo, INFO para produção, DEBUG para desenvolvimento). Evite registrar o corpo inteiro das solicitações ou um estado interno excessivo em produção. Sua fatura dos logs do CloudWatch agradecerá.
• Revise as funções não utilizadas: Audite periodicamente suas funções Lambda. Existem funções antigas, experimentais ou obsoletas ativas que geram custos? Remova-as!
• Monitore o tamanho dos pacotes: Pacotes de implantação menores significam partidas a frio mais rápidas e menos custos de armazenamento. Inclua apenas as dependências necessárias.
• Compreenda seu modelo de preços: Leia novamente a página de preços do Lambda. Entenda como as invocações, os GB-segundo e a transferência de dados são cobrados. O conhecimento é poder, especialmente quando se trata do seu portfólio.

Dominar o monstro serverless não significa evitar o serverless; trata-se de ser inteligente e intencional no nosso uso. A flexibilidade e a escalabilidade são inestimáveis, mas sem a vigilância adequada, esses “pequenos” custos podem se acumular e representar uma parte significativa do seu orçamento. Vá, monitore, otimize e economize!

É tudo da minha parte por hoje. Deixe-me saber nos comentários se você tem mais dicas ou truques para otimização de custos Lambda!

“`

🕒 Published: April 5, 2026