AWS SAA-C03/08 - Serverless e Containers2 min
Step Functions
Responda com suas palavras antes de ler o resto da nota.
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off (custo, latência, operação)?
- Que sinal no enunciado aponta pra isso?
- Com o que isso é confundido na prova?
Conceito
Orquestra fluxos de trabalho como uma máquina de estados: sequência, paralelismo, condicional, retry e tratamento de erro — declarados em JSON (ASL), sem código de orquestração.
Tipos de estado
| Estado | Faz |
|---|---|
| Task | Executa trabalho (Lambda, ECS, SQS, DynamoDB, SageMaker, 200+ serviços) |
| Choice | Ramifica por condição |
| Parallel | Executa ramos simultâneos |
| Map | Itera sobre uma lista (Distributed Map processa milhões de itens do S3) |
| Wait | Pausa por tempo ou até uma data |
| Succeed / Fail | Encerra |
| Pass | Passa adiante, transformando |
Retry e Catch são declarados por estado — retry com backoff exponencial sem escrever uma linha.
Standard vs Express
| Standard | Express | |
|---|---|---|
| Duração máxima | 1 ano | 5 minutos |
| Execução | Exactly-once | At-least-once |
| Volume | Baixo/médio | Altíssimo (100k+/s) |
| Preço | Por transição de estado | Por execução + duração (bem mais barato) |
| Histórico | Visual completo no console | CloudWatch Logs |
Padrões de integração
- Request Response: chama e segue
- Run a Job (.sync): chama e espera terminar (ECS task, Glue job, EMR)
- Wait for Callback (.waitForTaskToken): pausa até alguém devolver o token — é assim que se modela aprovação humana
Trade-offs
Step Functions tira o controle de fluxo de dentro do código e coloca numa definição visual e auditável: cada execução mostra onde falhou. O custo é mais um serviço no caminho e cobrança por transição — um loop com milhares de passos em Standard fica caro rapidamente (daí o Express existir).
Comparado a encadear Lambdas manualmente, ele resolve retry, timeout, estado e visibilidade de graça. Comparado ao EventBridge, a diferença é intenção: EventBridge roteia eventos sem manter estado; Step Functions mantém o estado de um processo de várias etapas.
Sinais de prova
- "Workflow de várias etapas com retry e tratamento de erro" → Step Functions
- "Processo que espera aprovação humana" → .waitForTaskToken
- "Coordenar Lambdas sem escrever lógica de orquestração" → Step Functions
- "Alto volume de workflows curtos, menor custo" → Express
- "Workflow que dura dias, precisa de auditoria por execução" → Standard
- "Processar milhões de objetos do S3 em paralelo" → Distributed Map
- "Só rotear eventos, sem estado" → EventBridge
Relacionado
Parte de 08 - MOC Serverless e Containers · Documentação AWS