Serverless Avançado: Lambda, API GW e Step Functions
- ⬜🎓 SAA-C03: Da Teoria à Arquitetura Real(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Serverless é tema central do SAA-C03. Lambda isolado é fácil — a prova testa quando usar Lambda vs Fargate vs ECS, como combinar com API Gateway, quando orquestrar com Step Functions, e como lidar com cold start, concurrency, VPC, event sources.
Onde isso entra no exame
Serverless aparece como alternativa a quase qualquer arquitetura baseada em EC2. Espere questões de “menor esforço operacional” — a resposta geralmente envolve Lambda + API GW + DynamoDB.
Lambda — limites e fundamentos
| Limite / Config | Valor |
|---|---|
| Memory | 128 MB a 10.240 MB (10 GB), em steps de 1 MB |
| vCPU | Proporcional à memória (10 GB = 6 vCPUs) |
| Timeout | 1s a 900s (15 min) |
| Deployment package | 50 MB zipped (direto) / 250 MB unzipped / 10 GB (container image) |
| /tmp storage | 512 MB default, até 10 GB configurável |
| Environment variables | 4 KB total |
| Concurrent executions | 1.000 default (soft limit, pode aumentar) |
| Burst concurrency | 500 a 3000 (depende da região) por minuto |
| Payload sync | 6 MB request/response |
| Payload async | 256 KB |
Event Sources — como Lambda é disparada
| Tipo | Modelo | Exemplos |
|---|---|---|
| Synchronous (push) | Caller espera resposta | API GW, ALB, Cognito, SDK invoke |
| Asynchronous (push) | Lambda recebe evento, AWS retry com DLQ/OnFailure | S3, SNS, EventBridge, CloudWatch Events |
| Poll-based (event source mapping) | Lambda faz polling do stream/queue | SQS, Kinesis, DynamoDB Streams, MSK |
Retry behavior por modelo: sync → caller decide (sem retry automático). Async → Lambda retry 2x com exponential backoff; depois DLQ/OnFailure. Event source mapping → depende do source (SQS reenfileira, Kinesis retry até expirar).
Cold Start e Concurrency
| Estratégia | Efeito |
|---|---|
| Provisioned Concurrency | Mantém N envs warm, cold start = 0, custa extra |
| SnapStart (Java) | Snapshot do env, cold start 10x mais rápido, grátis |
| Aumentar memory | Mais vCPU, init mais rápido, custa mais |
| Dep size menor | Menos código = cold start menor |
| Compiled runtime (Go/Rust) | Inicializa mais rápido que JVM/Python |
Lambda em VPC
Por padrão Lambda roda fora da sua VPC (internet via NAT AWS). Quando precisa acessar RDS/ElastiCache em subnet privada, configura VPC em Lambda → VPC settings. Lambda cria Hyperplane ENI compartilhada por várias Lambdas da mesma VPC.
Armadilhas VPC: Lambda em VPC PRECISA de NAT Gateway para acessar serviços AWS fora da VPC (S3, DynamoDB) — a menos que você configure VPC Endpoints. Sem isso, chamadas a S3 pendem indefinidamente.
Lambda Layers, Versions, Aliases
- • Layers — código compartilhado entre Lambdas (libs, binários). Até 5 layers por Lambda.
- • Version — snapshot imutável da Lambda (código + config). Referência por ARN com :N.
- • Alias — ponteiro mutável para version (ex: prod → v5, staging → v6). Permite routing por %.
- • Canary deploy — alias com weight split: 90% v5 / 10% v6, ajusta gradualmente.
Lambda Destinations e DLQ
Para Lambdas async, você define o que acontece pós-execução:
- • OnSuccess destination — envia resultado para SNS/SQS/Lambda/EventBridge
- • OnFailure destination — mesmo para falhas (após retries)
- • DLQ (legacy) — só falhas, envia evento original para SQS/SNS
API Gateway — REST API vs HTTP API vs WebSocket API
| Feature | REST API | HTTP API | WebSocket API |
|---|---|---|---|
| Preço | $3,50/M requests | $1,00/M requests | $1,00/M requests + $0,25/M minutes |
| Lançamento | 2015 | 2019 | 2018 |
| Latência | Alta | Baixa | Média |
| Cognito/JWT | Cognito | Cognito + JWT genérico | Cognito |
| API Keys / Usage Plans | ✅ | ❌ | ❌ |
| Request/Response transformation | ✅ | ❌ | ❌ |
| Caching | ✅ | ❌ | ❌ |
| WAF | ✅ | ❌ (precisa CloudFront) | ❌ |
| Edge endpoint | ✅ | ❌ (regional only) | Regional |
| Private endpoint | ✅ | ❌ | ❌ |
| Uso | Enterprise APIs com features avançadas | APIs modernas simples/rápidas | Chat, real-time |
Uma API precisa de autorização por token JWT, limite de taxa por cliente e cache de resposta de 60 segundos. Qual configuração de API Gateway?
API Gateway — integrações e features
- • Integration types — Lambda Proxy, Lambda non-proxy, HTTP (VPC Link), AWS service (ex: Step Functions), Mock
- • Stages — dev, staging, prod (cada uma deploy separado)
- • Custom authorizers — Lambda que valida token (JWT, custom)
- • Usage Plans + API Keys — quotas por cliente (só REST API)
- • Throttling — account-level e per-method rate limiting
- • CORS — configurável por stage/resource
- • Canary deployment — % do tráfego em nova version (REST)
Step Functions — orquestração
State machine serverless. Define workflow em Amazon States Language (ASL, JSON). Cada state é uma etapa: Task (invoca serviço), Choice (branch), Wait, Parallel, Map (iterar sobre array), Pass, Succeed, Fail.
- → HTTPS
- → valida token
- → invoca
- → lê e grava
- → busca credencial
- → fluxo longo ou multi-passo
- → esgotou retry
- → log e trace
- Fora da AWS
- Rede e entrega
- Segurança e identidade
- Compute
- Integração de apps
- Banco de dados
- Gestão e governança
Este é o desenho que uma questão de serverless do SAA-C03 descreve em prosa. As duas decisões que ela costuma testar: onde a autenticação acontece (no gateway, não na função) e quem orquestra fluxo longo (Step Functions, não Lambda chamando Lambda).
- O API Gateway protege a Lambda. Throttling, validação de requisição e authorizer acontecem antes de a função rodar — o que economiza invocação e barra ataque. Lambda exposta direto por URL não tem nada disso.
- Cognito valida, o API Gateway aplica. O authorizer do API Gateway verifica o token do Cognito e rejeita antes de chegar na função. Autenticação dentro da Lambda significa pagar invocação para depois negar.
- Fluxo longo não é trabalho de Lambda sozinha. Lambda tem teto de tempo de execução. Processo de vários passos, com espera, retry por passo e compensação, é Step Functions — que mantém o estado e sobrevive à falha de um passo. Encadear Lambda que chama Lambda para simular fluxo é o antipadrão que a prova pune.
- Segredo não vive em variável de ambiente. Secrets Manager com rotação, buscado em runtime e cacheado na memória da função entre invocações. Variável de ambiente aparece no console e no template de deploy.
- Toda invocação assíncrona precisa de destino de falha. Sem DLQ ou Lambda Destinations, evento que esgotou o retro desaparece em silêncio. É a diferença entre "perdemos 3 pedidos" e "temos 3 pedidos na fila de erro para reprocessar".
| Tipo | Uso | Execução |
|---|---|---|
| Standard Workflow | Workflows longos (até 1 ano), com histórico | Paga por state transition ($0,025/1k) |
| Express Workflow | Alta volume, <5 min, sem histórico detalhado | Paga por request + duração (muito mais barato) |
EventBridge (CloudWatch Events v2)
Event bus serverless que roteia eventos por pattern matching. Schema registry, custom buses, SaaS partners (Shopify, PagerDuty), scheduled rules (cron).
| Tipo | Uso |
|---|---|
| Default bus | Eventos AWS automáticos (EC2 state change, etc.) |
| Custom bus | Suas apps publicam eventos customizados |
| Partner bus | SaaS 3rd party (Zendesk, MongoDB Atlas) |
| Pipes | Conecta source (SQS/Kinesis) → filter → enrich → target (Lambda/Step Functions) |
| Scheduler | Cron centralizado (substitui CloudWatch Events rules para schedules) |
SAM e CDK — deploy serverless
- • AWS SAM — extensão de CloudFormation para serverless (YAML com shortcuts)
- • AWS CDK — infra em Python/TypeScript/Java/.NET/Go (gera CloudFormation)
- • Serverless Framework — 3rd party multi-cloud (YAML)
Cenários de decisão
📋 API REST simples com 10k req/dia, backend lógica de negócio
HTTP API ($1/M) + Lambda + DynamoDB on-demand. Custo ~$0 em Free Tier. Escala automaticamente. Sem gestão de server.
📋 App enterprise com 50 parceiros que precisam de API keys, throttling diferente por tier, request validation
REST API tem API keys, usage plans, request validation, caching — HTTP API não. Custo maior ($3,50/M) é justificado pelas features.
📋 Processo de onboarding com múltiplos steps (validate → create account → send email → notify CRM), com retry customizado
State machine com Retry/Catch em cada Task. Visual flow. Histórico de execuções. Lambda sozinho exigiria orquestração em código (frágil).
📋 Lambda crítica com p99 latency spike de 3s por cold start
PC mantém N envs warm. Extra cost mas latência consistente. Alternativa: Lambda SnapStart (Java only, grátis).
📋 Worker que processa 1M mensagens SQS/dia, lógica média
Lambda polling SQS automaticamente. Escala com backlog. Batch size configurável. Free tier + spot pricing torna extremamente barato vs EC2 worker.
Pegadinhas serverless no SAA:
Perguntas típicas (Q&A)
❓ Como permitir que API Gateway invoque Lambda?
❓ Minha Lambda precisa acessar RDS Aurora em VPC. O que fazer?
❓ Como fazer deploy canário em API Gateway REST?
❓ SQS + Lambda — o que acontece se Lambda falha?
Perguntas frequentes
❓ O que causa partida a frio e como reduzir?
❓ Concorrência reservada ou provisionada?
❓ Por que minha função dá tempo esgotado só em produção?
Fixando
Uma Lambda dentro de uma VPC precisa acessar o DynamoDB. Qual é a configuração correta e mais econômica?
Um fluxo de pedido tem 6 passos, alguns podendo levar minutos, com retry por passo e compensação em caso de falha. Qual arquitetura?
Take-aways: Lambda: 128 MB-10 GB, 15 min max, sync (6 MB) / async (256 KB) / poll-based. Cold start mitigável com Provisioned Concurrency / SnapStart / memory. Lambda em VPC precisa NAT/VPC Endpoint para AWS services. API GW: REST (features completas) vs HTTP (barato e rápido) vs WebSocket. Step Functions orquestram workflows (Standard longo, Express curto). EventBridge roteia eventos por pattern. SAM/CDK para deploy. Serverless resolve "menor esforço operacional" — frase-chave no exame.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…