Fundamentos do AWS Lambda
AWS Lambda é um serviço de computação sem servidor (serverless) que executa código em resposta a eventos, sem necessidade de provisionar ou gerenciar servidores. Você paga apenas pelo tempo de execução, medido em milissegundos. Lambda suporta Node.js, Python, Java, Go, .NET e Ruby, permitindo integração perfeita com o ecossistema AWS.
O modelo de execução é stateless: cada invocação é independente e isolada. O container que executa sua função é criado quando necessário e pode ser reutilizado para invocações subsequentes (warm start). Entender o ciclo de vida — inicialização, execução e encerramento — é crítico para otimizar performance e custo.
import json
from datetime import datetime
def lambda_handler(event, context):
"""
Handler padrão de uma função Lambda em Python.
event: dados da invocação (JSON)
context: metadados da execução (função, memória, tempo restante)
"""
print(f"Função iniciada às {datetime.now()}")
print(f"Memória disponível: {context.memory_limit_in_mb}MB")
# Processar evento
nome = event.get('nome', 'Visitante')
return {
'statusCode': 200,
'body': json.dumps({
'mensagem': f'Olá, {nome}!',
'timestamp': str(datetime.now())
})
}
Triggers e Integração com Serviços AWS
Triggers são eventos que acionam execução de uma função Lambda. AWS oferece mais de 90 origem de eventos: S3, DynamoDB, API Gateway, SQS, EventBridge, SNS, CloudWatch, entre outros. Cada integração tem padrão diferente de invocação — síncrona ou assíncrona.
Invocações síncronas bloqueiam até receber resposta (API Gateway, invocação direta). Invocações assíncronas enfileiram a execução e retornam imediatamente (S3, SNS), permitindo tratamento de erros com Dead Letter Queues. Compreender essa distinção evita gargalos e timeouts em produção.
# Exemplo: Trigger de S3 para processar uploads de imagens
import boto3
import json
s3_client = boto3.client('s3')
def lambda_handler(event, context):
"""
Acionada automaticamente quando arquivo é enviado para S3.
event contém Records com informações do objeto.
"""
try:
# Extrair informações do bucket e objeto
for record in event['Records']:
bucket = record['s3']['bucket']['name']
key = record['s3']['object']['key']
# Validar tipo de arquivo
if not key.lower().endswith(('.jpg', '.png', '.gif')):
print(f"Arquivo ignorado: {key}")
continue
# Processar imagem (gerar thumbnail, extrair metadados, etc)
print(f"Processando imagem: s3://{bucket}/{key}")
# Simular processamento
metadata = {
'bucket': bucket,
'key': key,
'processado': True,
'timestamp': str(context.aws_request_id)
}
# Salvar resultado em outro bucket
s3_client.put_object(
Bucket=f"{bucket}-processed",
Key=f"processed-{key}.json",
Body=json.dumps(metadata)
)
return {'statusCode': 200, 'message': 'Processamento concluído'}
except Exception as e:
print(f"Erro: {str(e)}")
raise e # Propagar erro para retry automático ou DLQ
Execution Model e Otimização de Performance
O modelo de execução Lambda tem três fases: Cold Start (primeiro uso, ~100-1000ms), Warm Start (reutilização, <10ms) e Execução. A memória alocada (128MB a 10,240MB) determina CPU, rede e tempo de execução. Mais memória = mais CPU = execução mais rápida e, contraintuitivamente, custo total menor para tarefas CPU-bound.
Estratégias críticas: mantenha dependências leves, inicialize conexões fora do handler (aproveitando warm starts), use variáveis de ambiente para configuração, implemente retry com backoff exponencial e monitore com CloudWatch. Em produção, destine 256-512MB para APIs e 1024MB+ para processamento pesado.
# Exemplo: Otimização com inicialização fora do handler
import boto3
import os
from functools import lru_cache
# Conexões inicializadas uma única vez por warm start
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table(os.environ['USERS_TABLE'])
@lru_cache(maxsize=128)
def get_user_cache(user_id):
"""Cache em memória para consultas frequentes"""
return f"cached_{user_id}"
def lambda_handler(event, context):
"""Execução rápida aproveitando conexões preexistentes"""
try:
user_id = event.get('user_id')
# Consultar com cache
cached = get_user_cache(user_id)
# Consultar banco apenas se necessário
response = table.get_item(Key={'id': user_id})
user = response.get('Item')
return {
'statusCode': 200,
'body': json.dumps(user),
'cached': cached != f"cached_{user_id}"
}
except Exception as e:
print(f"Erro: {str(e)}")
return {'statusCode': 500, 'body': json.dumps({'erro': str(e)})}
Tratamento de Erros e Resiliência em Produção
Erros em Lambda não interrompem sozinhos a execução. Você deve capturar exceções explicitamente e decidir: relançar para retry automático, enviar para DLQ ou retornar erro tratado. Para integrações assíncronas, configure Maximum Age of Event (máximo de tentativas) e destino para mensagens com falha — filas SQS ou tópicos SNS.
Implementar idempotência é essencial: a mesma invocação não deve produzir efeitos colaterais duplicados. Use identificadores únicos (request IDs, tokens) armazenados em DynamoDB com TTL. Combine com logging estruturado (JSON) via CloudWatch para rastrear falhas e depurar problemas em produção.
# Exemplo: Tratamento robusto com retry e idempotência
import json
import boto3
from uuid import uuid4
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
dynamodb = boto3.resource('dynamodb')
processed_table = dynamodb.Table('processed-requests')
sqs = boto3.client('sqs')
def lambda_handler(event, context):
"""
Processa pagamento com idempotência.
Evita cobranças duplicadas em caso de retry.
"""
try:
# Extrair ID único da requisição
request_id = event.get('request_id', str(uuid4()))
# Verificar se já foi processado
response = processed_table.get_item(Key={'request_id': request_id})
if 'Item' in response:
logger.info(f"Requisição já processada: {request_id}")
return {
'statusCode': 200,
'body': json.dumps({'status': 'já processado'})
}
# Processar pagamento (chamada a API externa)
logger.info(f"Processando pagamento para {request_id}")
payment_id = str(uuid4())
# Registrar como processado (antes de confirmar para evitar perda)
processed_table.put_item(
Item={
'request_id': request_id,
'payment_id': payment_id,
'status': 'sucesso',
'timestamp': int(context.get_remaining_time_in_millis())
}
)
logger.info(f"Pagamento concluído: {payment_id}")
return {
'statusCode': 200,
'body': json.dumps({'payment_id': payment_id, 'status': 'sucesso'})
}
except Exception as e:
logger.error(f"Erro ao processar {request_id}: {str(e)}")
# Enviar para DLQ para análise posterior
sqs.send_message(
QueueUrl=os.environ['DLQ_URL'],
MessageBody=json.dumps({
'event': event,
'error': str(e),
'timestamp': str(context.get_remaining_time_in_millis())
})
)
# Relançar para retry automático
raise Exception(f"Falha no processamento: {str(e)}")
Conclusão
Dominar AWS Lambda requer compreensão profunda de três pilares: (1) Fundamentos — statelessness, ciclo de vida e modelo de invocação, críticos para arquitetura escalável; (2) Triggers — cada integração AWS tem semântica diferente, síncrona vs assíncrona, com impacto direto em confiabilidade; (3) Otimização — memória determina CPU, warm starts economizam 90% do tempo, e inicialização fora do handler é prática não-negociável em produção.
Implementação profissional demanda idempotência, retry inteligente, observabilidade robusta e tratamento de erros estratégico. Comece com arquiteturas simples, meça custos e latência reais, e escale incrementalmente. Lambda não é "escrever código e deployar" — é pensar em distribuição, falhas parciais e recuperação automática.