Serverless não significa ausência de servidores — significa que você não precisa gerenciá-los. A AWS oferece um ecossistema maduro de serviços serverless que permite construir aplicações escaláveis, resilientes e com custo proporcional ao uso real. Neste artigo, exploramos os principais serviços, casos de uso reais e as armadilhas mais comuns.

O que é Serverless?

No modelo serverless, você escreve código e a nuvem cuida de toda a infraestrutura: provisionamento, escalabilidade, disponibilidade e manutenção dos servidores. Você paga apenas pelo tempo de execução e pelos recursos consumidos — sem instâncias ociosas, sem custo fixo de infraestrutura.

Na AWS, o serverless vai muito além do AWS Lambda. É um conjunto de serviços gerenciados que cobrem computação, banco de dados, mensageria, API, armazenamento e orquestração.

Os principais serviços serverless da AWS

AWS Lambda — Computação sob demanda

O Lambda é o coração do serverless na AWS. Você sobe uma função em Node.js, Python, Java, Go, .NET ou qualquer runtime customizado, define o gatilho e a AWS executa o código em resposta a eventos. Escala de zero a milhares de execuções simultâneas em segundos.

• Timeout máximo: 15 minutos por execução
• Memória: 128 MB a 10 GB configurável
• Cobrança: por número de invocações + duração em GB-segundo
• Free tier: 1 milhão de invocações/mês + 400.000 GB-segundos

Amazon API Gateway — APIs sem servidor de aplicação

Crie, publique e gerencie APIs REST, HTTP e WebSocket sem provisionar nenhum servidor. Integra nativamente com Lambda, e suporta autenticação via Cognito, IAM ou Lambda Authorizer. O modo HTTP API é até 70% mais barato que o REST API para casos simples.

Amazon DynamoDB — Banco de dados NoSQL serverless

DynamoDB oferece latência de milissegundos em qualquer escala, com modo on-demand que cobra por leitura e escrita realizada — sem capacidade provisionada. Ideal para workloads imprevisíveis ou com picos de acesso.

Amazon SQS e SNS — Mensageria serverless

SQS (filas) e SNS (pub/sub) são totalmente gerenciados e escalam automaticamente. Combinados com Lambda, formam a base de arquiteturas orientadas a eventos: o Lambda consome mensagens da fila, processa e escala conforme o volume de mensagens.

AWS Step Functions — Orquestração de workflows

Orquestre múltiplas funções Lambda e serviços AWS em workflows visuais com controle de estado, retry automático, tratamento de erros e execuções paralelas. Essencial para processos de negócio complexos que envolvem múltiplas etapas.

Amazon EventBridge — Barramento de eventos

Roteie eventos entre serviços AWS, aplicações SaaS e seus próprios sistemas com regras baseadas em conteúdo. É o backbone de arquiteturas event-driven modernas na AWS.

Casos de uso ideais para Serverless

1. APIs e backends de aplicações

A combinação API Gateway + Lambda + DynamoDB é o stack serverless mais popular. Ideal para APIs com tráfego variável, MVPs, microsserviços e backends de aplicações mobile.

# Exemplo: Lambda handler para API REST
import json
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Pedidos')

def handler(event, context):
    pedido_id = event['pathParameters']['id']
    
    response = table.get_item(Key={'id': pedido_id})
    pedido = response.get('Item')
    
    if not pedido:
        return {'statusCode': 404, 'body': json.dumps({'error': 'Pedido não encontrado'})}
    
    return {
        'statusCode': 200,
        'body': json.dumps(pedido)
    }

2. Processamento de eventos e filas

Lambda + SQS é perfeito para processamento assíncrono: envio de emails, geração de relatórios, processamento de imagens, integração com sistemas legados. O Lambda escala automaticamente conforme o volume de mensagens na fila.

3. Automações e agendamentos

EventBridge Scheduler substitui cron jobs em servidores. Agende funções Lambda para executar em horários específicos: limpeza de dados, geração de relatórios noturnos, sincronização de sistemas.

4. Processamento de arquivos

Trigger Lambda no upload de arquivos no S3 para processamento automático: redimensionamento de imagens, extração de texto com Textract, transcrição de áudio com Transcribe, análise de documentos.

5. Chatbots e assistentes com IA

Lambda integra nativamente com Amazon Bedrock para criar chatbots e assistentes de IA serverless. Cada conversa é uma invocação independente, sem servidor ocioso entre as interações.

Boas práticas essenciais

Funções pequenas e com responsabilidade única

Cada função Lambda deve fazer uma coisa bem feita. Funções grandes e com múltiplas responsabilidades são difíceis de testar, depurar e escalar independentemente. Siga o princípio da responsabilidade única.

Gerencie o cold start

O cold start ocorre quando o Lambda precisa inicializar um novo container para executar sua função. Para minimizar:

• Use Provisioned Concurrency para funções críticas de latência
• Prefira runtimes mais rápidos (Node.js, Python) para funções sensíveis a latência
• Mantenha o pacote de deployment enxuto — menos dependências = inicialização mais rápida
• Inicialize conexões e clientes fora do handler (no escopo global da função)

# Bom: cliente inicializado fora do handler (reutilizado entre invocações)
import boto3

dynamodb = boto3.resource('dynamodb')  # inicializado uma vez
table = dynamodb.Table('MinhaTabela')

def handler(event, context):
    # table já está pronto, sem overhead de inicialização
    return table.get_item(Key={'id': event['id']})

Configure timeouts e memória adequadamente

O timeout padrão do Lambda é 3 segundos — muito baixo para a maioria dos casos reais. Configure timeouts realistas com margem de segurança. Quanto à memória: mais memória = mais CPU alocado = execução mais rápida. Às vezes aumentar memória reduz o custo total por diminuir o tempo de execução.

Use variáveis de ambiente para configuração

Nunca hardcode ARNs, nomes de tabelas ou endpoints no código. Use variáveis de ambiente e, para segredos, o AWS Secrets Manager ou Parameter Store.

Implemente idempotência

Em arquiteturas event-driven, a mesma mensagem pode ser entregue mais de uma vez (at-least-once delivery). Suas funções devem ser idempotentes: processar a mesma mensagem múltiplas vezes deve produzir o mesmo resultado sem efeitos colaterais.

Armadilhas comuns e como evitá-las

Conexões de banco de dados relacionais

Lambda escala para centenas de instâncias simultâneas, cada uma abrindo uma conexão com o banco. Um RDS PostgreSQL suporta ~100 conexões simultâneas — você vai estourar rapidamente. A solução é o RDS Proxy, que faz pool de conexões entre o Lambda e o banco, ou migrar para DynamoDB quando possível.

Funções com estado

Lambda é stateless por design. Não armazene estado em variáveis globais esperando que persista entre invocações — o container pode ser destruído a qualquer momento. Use DynamoDB, ElastiCache ou S3 para estado persistente.

Loops infinitos e recursão acidental

Uma função Lambda que escreve no S3 e é triggerada por eventos do S3 pode criar um loop infinito. Configure os triggers com cuidado e use prefixos/sufixos nos eventos S3 para evitar recursão.

Monitoramento insuficiente

Sem observabilidade, você não sabe o que está acontecendo. Configure obrigatoriamente:

• CloudWatch Logs com structured logging (JSON)
• CloudWatch Alarms para erros, throttles e duração
• AWS X-Ray para rastreamento distribuído entre serviços
• Dead Letter Queue (DLQ) para capturar invocações com falha

Comparativo de custo: Serverless vs EC2

Serverless é mais econômico para workloads com tráfego variável ou baixo. Para workloads com tráfego constante e alto volume, EC2 ou containers podem ser mais baratos.

Quando NÃO usar Serverless

Serverless não é bala de prata. Evite para:

• Processamentos longos: tarefas que excedem 15 minutos (use ECS Fargate ou AWS Batch)
• Workloads com estado complexo: aplicações que precisam de memória compartilhada entre requisições
• Latência ultra-baixa: aplicações que não toleram cold starts (use Provisioned Concurrency ou containers)
• Tráfego constante e previsível alto: EC2 Reserved Instances ou Savings Plans podem ser mais baratos
• Aplicações legadas monolíticas: migrar um monolito diretamente para Lambda raramente faz sentido

Por onde começar

Se você está começando com serverless na AWS, o caminho mais direto é:

• Use o AWS SAM (Serverless Application Model) ou Serverless Framework para infraestrutura como código
• Comece com um caso de uso simples: uma API REST com Lambda + API Gateway + DynamoDB
• Configure CloudWatch Logs e X-Ray desde o início — observabilidade não é opcional
• Escreva testes unitários para suas funções Lambda — elas são código como qualquer outro
• Use o AWS Lambda Power Tuning para encontrar a configuração ideal de memória/custo