Orquestrando Pipelines de Dados: Step Functions, EventBridge e Airflow

Um pipeline de dados que transforma corretamente mas começa atrasado, roda duas vezes, pula em silêncio um passo que falhou ou não pode ser reproduzido também falhou. Ingestão e transformação (Lições 02 e 03) decidem o que se move e como é remodelado; a orquestração decide quando roda, em que ordem, o que acontece quando falha e como você se recupera, e o DEA-C01 testa exatamente esse julgamento no Domínio 1, Tarefa 1.3 "Orquestrar pipelines de dados", por meio de quatro habilidades: 1.3.1 serviços de orquestração (AWS Lambda, Amazon EventBridge, Amazon MWAA, AWS Step Functions, AWS Glue workflows), 1.3.2 pipelines resilientes e escaláveis, 1.3.3 workflows serverless e 1.3.4 alertas via SNS e SQS (guia do exame DEA-C01, acesso em outubro de 2026).

Nesta lição você vai:

• separar workflows Standard e Express por duração, garantia de entrega, cobrança e padrões de integração suportados;
• ler e escrever Amazon States Language: os oito tipos de estado, Retry, Catch, nomes de erro embutidos e error states terminais;
• escolher entre Map inline e Distributed e dimensionar ItemReader, ItemBatcher e ResultWriter;
• construir rules do EventBridge sobre schedules e event patterns, entendendo buses, targets, políticas de retry e DLQs;
• usar EventBridge Pipes para fan-out de streams/filas sem código e EventBridge Scheduler para schedules conscientes de fuso horário;
• descrever um ambiente Amazon MWAA, seu armazenamento de DAGs, operators, classes de worker e versões do Airflow;
• ligar AWS Glue Workflows e triggers (schedule, on-demand, EventBridge, condicional) num único grafo;
• aplicar a matriz de seleção de orquestração: cron → EventBridge, retries em múltiplos passos → Step Functions, DAGs complexos → MWAA, fluxos reativos a eventos → Pipes;
• aplicar os padrões de retry, DLQ, idempotência e backfill que tornam um pipeline resiliente;
• estudar quatro casos reais de clientes da AWS, ler a caixa de atualizações de outubro de 2026 e treinar com 14 questões no estilo de exame mais verificações interativas.

---

1. A superfície de orquestração: cinco primitivas, um trabalho

1.1 O que a Tarefa 1.3 realmente pergunta

Toda questão de orquestração neste exame se reduz a quatro perguntas: O que dá início à execução? (schedule, evento, chamada de API, sucesso de uma etapa a montante) Em que ordem os passos rodam? (serial, paralelo, fan-out, condicional) O que acontece na falha? (retry, catch, alerta, estacionar numa DLQ) Como rodar de novo sem corromper os dados? (backfill, redrive, idempotência). Serviços diferentes respondem a essas quatro perguntas de maneiras diferentes, e os distratores do exame são sempre um serviço correto usado para a pergunta errada.

A categoria Application Integration na lista de serviços no escopo do DEA-C01 é exatamente esta família: Amazon EventBridge, Amazon MWAA, Amazon SNS, Amazon SQS, AWS Step Functions, com AWS Lambda como a computação que a maioria deles chama (página de serviços no escopo do DEA-C01, acesso em outubro de 2026).

1.2 Resiliente e escalável é uma checklist, não um adjetivo

A habilidade 1.3.2 espera que você nomeie os mecanismos, não que você os admire:

1. Retry com backoff e jitter: falhas transitórias são reexecutadas automaticamente antes que alguém seja acionado.
2. Catch / error state: falhas irreversíveis são roteadas para um lugar definido em vez de desaparecerem.
3. Dead-letter queue (DLQ): eventos ou mensagens que esgotaram os retries são preservados para inspeção e reprodução.
4. Idempotência: a mesma entrada processada duas vezes produz a mesma saída uma única vez (escritas condicionais, chaves de idempotência, job bookmarks).
5. Backfill e redrive: reexecutar deliberadamente uma janela de histórico ou um conjunto de execuções que falharam.
6. Alertas: SNS para humanos, SQS para máquinas, alarmes do CloudWatch nas métricas (ExecutionsFailed, ExecutionThrottled, FailedInvocations, InvocationThrottleCount).

• 📚 Você sabia? Os quatro nomes de métrica do CloudWatch acima são o atalho de troubleshooting mais barato do exame: ExecutionsFailed e ExecutionThrottled pertencem ao Step Functions, enquanto FailedInvocations e InvocationThrottleCount pertencem aos targets e Pipes do EventBridge. Uma questão que associa a métrica errada ao serviço errado está testando se você sabe qual camada falhou: a máquina de estados ou a entrega do evento ao seu target (documentação do AWS CloudWatch, acesso em outubro de 2026).

---

2. AWS Step Functions: Standard versus Express

2.1 O eixo central do exame

A AWS oferece dois tipos de workflow, e a diferença não é velocidade: é duração, garantia de entrega, medidor e padrões de integração disponíveis (guia do desenvolvedor do AWS Step Functions, Standard vs Express, acesso em outubro de 2026):

A regra de uma linha: tudo que precisa esperar (.sync, .waitForTaskToken, uma aprovação humana de dias, uma execução de um ano) ou que precisa ser exactly-once é um workflow Standard; tudo que é curto, de alto volume e idempotente é um workflow Express.

2.2 Exemplo resolvido E1: precificando um pipeline Standard

Um pipeline noturno tem 9 transições de estado por execução; um estado faz retry 3 vezes antes de ter sucesso, acrescentando 3 transições por execução (retries são transições de estado cobráveis). Ele roda 10,000 vezes por dia num mês de 30 dias (preços do Step Functions, us-east-1, em outubro de 2026):

Duas lições saem daí: retries custam dinheiro (são transições), e um estado Wait em loop é um medidor que você liga de propósito.

2.3 Exemplo resolvido E2: mesmo pipeline, dois tipos de workflow

O mesmo job de 6 estados, 4 segundos, menos de 64 MB, rodado 1,000 vezes:

Mais de 20x mais barato para o Express nesse formato, e a diferença cresce conforme a duração aumenta, porque o Express cobra pela duração enquanto o Standard cobra apenas transições. O próprio post de otimização de custos da AWS de 2022 ilustra a mesma assimetria com uma comparação de $0.42 no Standard versus $0.01 no Express (AWS News Blog, 2022-08-30). A questão de exame corolária é a inversa: um workflow que espera 12 horas num estado Wait queimaria transições se você fizesse polling, enquanto um token de callback espera de graça (veja E9).

• 📚 Você sabia? Os workflows Express são o único tipo de workflow que você pode iniciar com StartSyncExecution pelo console, e esse resultado síncrono do console expira após 60 segundos, então qualquer coisa mais longe pertence a uma chamada de SDK/CLI. Aninhar também é oficialmente recomendado: um pai Standard pode iniciar um filho Express aninhado, e iniciar um workflow aninhado custa exatamente uma transição de estado (páginas de preços e de boas práticas do AWS Step Functions, acesso em outubro de 2026).

---

3. Amazon States Language: os oito tipos de estado

3.1 O vocabulário

Máquinas de estados são definidas em Amazon States Language (ASL): uma linguagem declarativa baseada em JSON (especificação states-language.net, acesso em outubro de 2026):

Cada estado declara Type e ou Next xor End, além dos filtros de entrada/saída InputPath, ResultPath, OutputPath, um TimeoutSeconds opcional e os arrays opcionais Retry e Catch. A linguagem de consulta é JSONPath (caminhos escritos com sufixo .$, por exemplo "Bucket.$": "$.bucket") ou JSONata (blocos {% … %}). Caminhos de contexto alcançam a própria execução: $$.Execution.Id, $$.State.Name, $$.Task.Token e $$.Map.Item.*.

3.2 Exemplo resolvido E3: um fragmento real de ASL

Leia como uma história: o job do Glue roda de forma síncrona (.sync espera o job terminar), timeouts nunca são reexecutados enquanto todo o resto tenta de novo até 5 vezes com backoff exponencial e jitter completo, erros irreversíveis são capturados em $.error e roteados para um alerta do SNS, um Choice impõe um contrato de dados, e o estado terminal é um Fail explícito: a definição de error state do exame.

3.3 Mecânica do retry: os arrays são varridos de cima para baixo

• Retriers (Retry[]) são varridos na ordem do array; a primeira entrada cujo ErrorEquals casa é a que manda. É por isso que ["States.Timeout"] com MaxAttempts: 0 precisa vir antes de ["States.ALL"]: essa é a configuração canônica de "repetir tudo exceto timeouts".
• Padrões (quando você omite um campo): IntervalSeconds 1, MaxAttempts 3 (ou seja, 4 tentativas no total), BackoffRate 2.0 (precisa ser ≥ 1.0), JitterStrategy NONE a menos que você defina FULL.
• Catchers (Catch[]) rodam apenas quando não há entrada de Retry correspondente ou os retries se esgotaram; cada um carrega ErrorEquals, Next e normalmente um ResultPath como $.error, para que o payload da falha não sobrescreva seus dados.

3.4 Nomes de erro embutidos que você não deve misturar

3.5 Exemplo resolvido E4: aritmética do tempo de retry

Com os padrões (IntervalSeconds: 1, BackoffRate: 2.0, MaxAttempts: 3):

Defina IntervalSeconds: 30, MaxAttempts: 5, BackoffRate: 2.0 e as esperas passam a ser 30 + 60 + 120 + 240 + 480 = 930 segundos (15.5 minutos) antes de a task ser declarada falha: a configuração do E3. JitterStrategy: "FULL" randomiza cada atraso dentro da sua janela, para que uma frota de execuções não faça retry em uníssono (documentação de tratamento de erros do AWS Step Functions, acesso em outubro de 2026).

3.6 Task tokens: esperar sem custar nada

Para trabalho que nenhum padrão .sync cobre, uma aprovação humana, uma API de terceiros, um worker externo, a máquina de estados injeta o token e espera:

Mais tarde, o worker externo chama SendTaskSuccess, SendTaskFailure ou SendTaskHeartbeat. A espera é ilimitada (até o limite de 1 ano do Standard), não é cobrável e existe só no Standard, então defina sempre HeartbeatSeconds, caso contrária um callback perdido fica pendurado até o timeout do estado em vez de falhar rápido com States.Timeout.

• 📚 Você sabia? Um estado de aprovação humana que fica aberto três dias custa zero transições de estado por hora: as transições foram gastas entrando e saindo do estado, não esperando dentro dele. Essa assimetria é a razão pela qual os designs de longa duração mais baratos colocam um .waitForTaskToken onde um loop de Wait com polling viveria: 1,000 polls por hora custam $3.00 por mês, um callback com token custa uma única transição (exemplo resolvido E9; preços do Step Functions, em outubro de 2026).

3.7 Integrações de serviço: qual padrão cada serviço suporta

O Step Functions entrega integrações otimizadas (o serviço interpreta a chamada) mais uma integração genérica de AWS SDK que cobre mais de 220 serviços da AWS (AWS What's New, 2026-03-26: +28 serviços / 1,100+ APIs):

Otimizado ≠ SDK: a integração otimizada do Lambda faz o parse do payload de resposta automaticamente, a integração otimizada do Glue devolve JobName + JobRunID, e o EMR renomeia JobFlowId para ClusterId. Chamadas de callback e .sync também precisam de permissões extras de IAM (glue:GetJobRun, ecs:RunTask mais iam:PassRole): um favorito do exame quando um pipeline "funciona no console e falha em produção".

---

4. O estado Map: inline versus Distributed

4.1 Quando acontece a troca

Map itera um array de entrada. Inline (o padrão) executa cada iteração dentro do próprio histórico de execução do pai; o modo Distributed executa cada iteração como uma execução de workflow filho com seu próprio histórico (guia do desenvolvedor do AWS Step Functions, Map state, acesso em outubro de 2026):

A configuração fica em ProcessorConfig: { "Mode": "DISTRIBUTED", "ExecutionType": "EXPRESS" | "STANDARD" } mais os campos abaixo:

• ItemReader (+ ReaderConfig.InputType): de onde vêm os itens; MaxItems ≤ 100,000,000, e MaxItems XOR MaxItemsPath.
• ItemsPath / ItemSelector: quais itens, e como cada um é remodelado antes de o filho rodar.
• ItemBatcher: MaxItemsPerBatch, MaxItemsPerBatchBytes (≤ 256 KiB).
• MaxConcurrency / MaxConcurrencyPath: nunca defina acima da capacidade a jusante.
• ResultWriter: os resultados caem no S3, não no histórico do pai.

4.2 Exemplo resolvido E5: aritmética do ItemBatcher

Um Map Distributed faz fan-out de 1,130 objetos com MaxItemsPerBatch: 100:

$$\text{batches} = \left\lceil \frac{1{,}130}{100} \right\rceil = \lceil 11.3 \rceil = \mathbf{12 \ batches}$$

Lotes importam porque cada lote vira uma execução filha, e cada execução filha custa pelo menos uma transição de estado (ou, para filhos Express, uma requisição). 1,130 filhos é 1,130 execuções; 12 filhos é 12: mesmo trabalho, uma fração do overhead. Para um backfill de S3 com 1,000,000 de objetos a aritmética é diferente em natureza: o Map inline esgotaria o histórico de 25,000 eventos muito antes do último objeto, então você precisa de ItemReader sobre s3:listObjectsV2, ItemBatcher, MaxConcurrency dimensionado para a capacidade a jusante (por exemplo 1,000), filhos com ExecutionType: "EXPRESS", ToleratedFailurePercentage: 1 e ResultWriter para o S3.

---

5. Amazon EventBridge: rules, buses, retries e DLQs

5.1 Três tipos de bus, uma rule por bus

Uma rule observa exatamente um bus. Schedules nunca são permitidos em partner event buses; a referência da API documenta expressões de schedule nos buses default e custom (API do AWS EventBridge PutRule, acesso em outubro de 2026), então trate "schedule num bus partner" como sempre errado.

5.2 Duas formas de rule, e um schedule

Uma rule casa com um event pattern (filtragem baseada em conteúdo sobre campos JSON, até 2,048 caracteres) ou com uma expressão de schedule, ou ambos:

5.3 Exemplo resolvido E6: escrevendo a rule do cron

Requisição: "iniciar o load do warehouse às 20:00 UTC todo dia, e também sempre que um arquivo aterrissar no prefixo raw." Uma rule não faz as duas coisas limpas numa única expressão do jeito que o exame espera: você cria duas rules no mesmo bus:

Repare nos detalhes que o exame cobra: a precisão do schedule é de 1 minuto em UTC+0, então cron(0 20 * * ? *) é 20:00 UTC e não horário local; os targets do Step Functions são invocados de forma assíncrona; e uma rule carrega no máximo 5 targets.

5.4 Política de retry e dead-letter queue

Por target você pode sobrescrever a política de retry de entrega e anexar uma DLQ (AWS EventBridge, Retry policy and DLQ, acesso em outubro de 2026):

5.5 Exemplo resolvido E7: de retries de 24 horas para uma DLQ de 10 minutos

Uma equipe quer que as falhas apareçam em 10 minutos, não em um dia:

A DLQ precisa ser uma fila padrão do SQS na mesma região: uma fila FIFO não pode ser usada como DLQ do EventBridge. As mensagens que chegam carregam atributos como ERROR_CODE, EXHAUSTED_RETRY_CONDITION e RETRY_ATTEMPTS, e uma fila criptografada com KMS precisa de kms:Decrypt para events.amazonaws.com.

• 📚 Você sabia? Algumas falhas nunca são reexecutadas: uma permissão ausente, um recurso deletado ou DNS ruim vai direto para a DLQ com zero retries, e é por isso que "nenhum retry aconteceu" num ticket de suporte geralmente significa um problema de IAM ou de recurso, e não um bug na política de retry. E as DLQs do EventBridge são filas padrão do SQS comuns: você não pode usar uma fila FIFO, então uma questão que oferece "SQS FIFO como DLQ do EventBridge" é um distrator embutido (documentação de DLQ do AWS EventBridge, acesso em outubro de 2026).

5.6 Quotas que valem a pena decorar (em outubro de 2026)

• 📚 Você sabia? O EventBridge também orquestra pipelines de segurança, não só de dados: o Amazon Macie emite seus findings para o bus default, e uma rule pode roteá-los para uma Lambda ou para um fluxo de remediação do Step Functions com a mesma política de retry e a mesma DLQ padrão do SQS que você usa para um load de warehouse: a conexão por trás da 95% de precisão na descoberta de dados sensíveis e da redução de 80% no tempo necessário para descobrir dados sensíveis reportadas pela Oportun. A habilidade de orquestração não muda (casar em source / detail-type, limitar os retries, tornar a remediação idempotente); só o produtor muda (material de cliente do AWS Macie e o deck da sessão SEC215 do re:Invent, acesso em outubro de 2026).

---

6. EventBridge Pipes e EventBridge Scheduler

6.1 Pipes: origem → filtro → enriquecimento → destino, sem código

Pipes são ponto a ponto (não pub/sub): uma origem, um filtro opcional (só os eventos que casam são cobrados), uma etapa de enriquecimento opcional (Lambda ou Step Functions) e um destino (documentação do AWS EventBridge Pipes, acesso em outubro de 2026).

6.2 Exemplo resolvido E8: cobrança dos Pipes com um filtro

Um pipe consome 10,000,000 de mensagens SQS, um filtro deixa passar 25%, e o batching é de 5 mensagens por requisição (exemplo da página de preços do Step Functions, em outubro de 2026):

$0.20 para dez milhões de mensagens: porque o filtro roda antes da cobrança. O princípio examinável: filtre cedo, faça batching até o máximo do destino e lembre-se do teto de 5 minutos do pipe.

6.3 Scheduler: schedules sem rule

A AWS recomenda o EventBridge Scheduler para invocar targets por schedule, e o console rotula as rules agendadas como "(legacy)" (documentação do AWS EventBridge Scheduler, acesso em outubro de 2026).

A janela de tempo flexível é o recurso em que as questões de exame se apoiam: MaximumWindowInMinutes: 60 significa que um job noturno agendado para 01:00 pode disparar em qualquer momento entre 01:00 e 02:00: perfeito para janelas de batch que precisam absorver picos de carga, errado para um job que precisa começar exatamente às 01:00:00.

6.4 Quatro coisas que "rodam por schedule" (não misture)

---

7. Amazon MWAA: Apache Airflow gerenciado

7.1 O que um ambiente realmente é

Um ambiente Amazon MWAA é um pacote de componentes gerenciados (documentação do AWS MWAA, acesso em outubro de 2026):

Você abre mão de SSH, imagens customizadas, filas SQS customizadas e escolha de executor, somente Celery, em troca de a AWS rodar o plano de controle, o Aurora, o Fargate, o logging e a sua fiação de VPC. Atualizações em DAGs existentes são percebidas em cerca de 30 segundos.

7.2 Classes de worker e autoscaling (em outubro de 2026)

Workers são adicionados conforme (RunningTasks + QueuedTasks) / tasks-por-worker, até max-workers. O padrão de celery.worker_autoscale por classe (3 / 5 / 10 / 20 / 40 / 80) é o que manda, e celery.worker_concurrency é sobrescrito: definir não faz nada.

7.3 Operators e dependências

Os DAGs ficam no S3, as dependências em requirements.txt (pip3) e plugins.zip; um novo requirements.txt exige uma atualização do ambiente. Os operators que importam para este exame:

Versões disponíveis em outubro de 2026: Airflow 3.2.x (anunciado em 2026-04-01), 3.0.x e 2.11.0 (lançado em 2026-01-07, Python 3.12), além das linhas mais antigas 2.9.x/2.7.x/2.4.x. O Airflow 3 adiciona agendamento consciente de assets e partições, histórico de auditoria com humano no loop e PythonOperator assíncrono.

7.4 Exemplo resolvido E9: precificando um ambiente MWAA

O próprio exemplo worked da AWS para um ambiente mw1.small num mês de 31 dias: 1 ambiente, 49 workers rodando 1 hora por dia, 10 GB de armazenamento do banco de metadados (preços do MWAA, us-east-1, em outubro de 2026):

Para comparação, mw1.large custa $0.99/h para o ambiente, com workers e schedulers extras a $0.22/h e um web server extra a $0.11/h, e o MWAA Serverless cobra as AWS Managed Tasks a $0.080 por hora de tempo de task (mínimo de 1 minuto, cobrança de 1 segundo). Outras quotas: 10 ambientes por região (5 de mw1.xlarge/mw1.2xlarge), 25 workers por ambiente (50 após aumento de quota), 5 webservers, 20 GB de armazenamento de task.

• 📚 Você sabia? A fila Celery do MWAA é uma fila Amazon SQS gerenciada pela AWS que você não pode criar, substituir ou configurar, e é por isso que questões que oferecem "trazer sua própria fila SQS para o MWAA" ou "ajustar celery.worker_concurrency" estão erradas. O que você ajusta de verdade é a classe de worker, e essa única escolha move tanto a capacidade de DAGs quanto a concorrência padrão de tasks: mw1.small → mw1.medium muda o padrão de 5 para 10 tasks por worker (documentação do AWS MWAA, acesso em outubro de 2026).

7.5 MWAA Serverless

O MWAA Serverless elimina o ambiente sempre ligado: DAGs em YAML mais um pacote de código no S3, agendamento por task com pay-per-use apoiado no EventBridge Scheduler, uma role de execução por workflow e computação isolada. É a resposta serverless dentro da família Airflow, mas os conceitos do Airflow, o arquivo de DAG e os operators são os mesmos. (Documentação do AWS MWAA Serverless, acesso em outubro de 2026; a disponibilidade por região não é repetida aqui porque a lista de lançamento não pôde ser verificada em outubro de 2026.)

---

8. AWS Glue Workflows e triggers

8.1 Uma entidade, dois grafos

Um workflow do Glue rastreia jobs + crawlers + triggers como uma única entidade com uma visão de grafo: um grafo estático (design) e um grafo dinâmico (status de runtime por nó) (AWS Glue, Workflows e Triggers, acesso em outubro de 2026).

8.2 Os três triggers de início

Dentro do grafo, os triggers condicionais expressam dependências: o job J3 começa depois de J1 AND J2 SUCCEEDED; o job J4 começa depois de J1 OR J2 FAILED; um crawler começa depois que os jobs terminam. As workflow run properties são pares nome/valor compartilhados que os jobs leem e alteram durante a execução: passagem de estado sem XCom do Airflow.

8.3 A regra dura

Todos os jobs ou crawlers numa cadeia de dependência precisam ser descendentes de um único trigger agendado ou on-demand. Dependentes disparam apenas se um trigger os iniciou: um crawler que você inicia na mão não vai disparar o próximo job do grafo. Cada trigger suporta ≤ 50 jobs e ≤ 2 crawlers, e um Glue workflow é um target de primeira classe do EventBridge, então uma rule do EventBridge ou um schedule do Scheduler pode iniciar o grafo inteiro.

8.4 Escolhendo entre Glue Workflows e Step Functions para o mesmo ETL

---

9. A matriz de seleção de orquestração

9.1 O diagrama do dinheiro

9.2 A matriz em palavras

---

10. Padrões de retry, DLQ, idempotência e backfill

10.1 A escada de confiabilidade

10.2 Idempotência: a pré-condição de toda reprodução

A entrega é at-least-once quase em todo lugar (execuções Express, targets do EventBridge, SQS, Pipes), então a reprodução só é segura se o processamento for idempotente:

• Escrita condicional no DynamoDB: ConditionExpression: attribute_not_exists(pk) falha com DynamoDB.ConditionalCheckFailedException, que um Catch pode absorver; ramos paralelos competindo por um lock usam exatamente esse truque.
• @idempotent do Lambda Powertools com TTL: a segunda invocação do mesmo evento devolve o resultado em cache.
• Cabeçalho Idempotency-Key a montante para pipelines dirigidos por API.
• Job bookmarks do Glue, o equivalente do lado da transformação: o estado rastreado entre job.init e job.commit evita reprocessamento (Lição 03).

10.3 Redrive, retry e replay são três coisas diferentes

O Step Functions também emite eventos de mudança de status de execução para o bus default do EventBridge, então uma rule pode observar ExecutionFailed e invocar uma Lambda que chama RedriveExecution: orquestração se curando sozinha.

10.4 Exemplo resolvido E10: projetando o caminho de recuperação

10.5 Padrões de backfill

Atualizações de 2026 (em outubro de 2026)

• 📚 Você sabia? A formulação exactly-once / at-least-once está estável desde o lançamento do Express em 2019-12-05, enquanto tudo ao redor mudou: a cobertura de integrações mais que dobrou para 220+ serviços, o Distributed Map ganhou fontes do S3 e do Athena, e o MWAA passou pelo Airflow 2.4 → 2.11 → 3.0 → 3.2. Para o exame, isso significa que a tabela de garantias da Seção 2 é material antigo e durável, enquanto nomes de integrações e números de versão são a parte que você precisa rechecar a cada ciclo de estudos (anúncio do AWS Step Functions, 2019-12-05; recent launches do Step Functions, acesso em outubro de 2026).

---

Casos Reais

A AWS publica como essas abstrações aparecem em produção. Todo número abaixo é afirmação do cliente ou da AWS e não auditado, com a fonte nomeada para que você possa conferir, o ponto examinável é o padrão (qual problema de orquestração foi resolvido, qual serviço fez o trabalho, qual número se moveu), não o marketing.

Caso A, Edmunds.com: um batch em fan-out serverless (700 milhões de derivativos em 8 dias)

Leia isto como a forma de orquestração por trás do fan-out: um driver enumera os itens de trabalho (a lista de objetos do S3), cada unidade roda como uma invocação independente, idempotente e curta, e o agregado completa sem um cluster. É a mesma forma de um Distributed Map com ItemReader sobre um prefixo do S3 ou de um EventBridge Pipe de um stream para uma Lambda: a ideia examinável é itens independentes + concorrência limitada + uma condição de conclusão definida.

Caso B, EOS Group: um pipeline de migração em estágios com zero perda de dados

O ponto examinável é a disciplina de estágio: full load, CDC, validação e load são passos separados, ordenados e reexecutáveis com um gate de validação entre eles: a mesma topologia que você construiu na Seção 3 (Task → Choice → Task → Fail), só que implementada com ferramentas de migração. "Zero perda de dados" é o que um estado Choice sobre um contrato de contagem de linhas e um target idempotente compram para você; "downtime mínimo" é o que rodar os estágios como um grafo reexecutável em vez de um script monolítico compra.

Caso C, Nasdaq: um batch noturno dirigido por prazo em todo o lake house

Leia isto como um problema de prazo, não de ferramenta: como o caminho de escrita (S3) e o caminho de leitura (Redshift/Spectrum) estão desacoplados, carregar e consultar nunca disputam a mesma capacidade, então o orquestrador pode reiniciar um estágio que falhou sem pausar os analistas, e uma execução atrasada degrada um estágio em vez da noite inteira. É o mesmo raciocínio que torna um grafo reexecutável com um gate de validação (Caso B, Seção 3) a resposta padrão quando uma questão descreve um batch que simplesmente não pode se atrasar.

Caso D, AGCO: um pipeline de streaming que uma pessoa só consegue operar

Aqui o gatilho é o stream, não um cron: um pipeline em execução contínua é orquestrado por back-pressure e buffering em vez de por um schedule, então a checklist de resiliência da Seção 1.2 se move para dentro dos consumidores: retries com backoff na etapa de enriquecimento da Lambda, uma zona de aterrissagem durável (S3) para que uma falha a jusante reproduza a partir do buffer, e alarmes do CloudWatch em vez de um humano olhando um painel. "Uma pessoa em vez de três a cinco" é o dividendo operacional sobre o qual o exame realmente pergunta quando testa a habilidade 1.3.2.

• 📚 Você sabia? O salto publicado pela Nasdaq de 30 bilhões para 70 bilhões de registros por dia equivale a cerca de 810,000 registros por segundo sustentados (70,000,000,000 ÷ 86,400 s, aritmética derivada, não um número publicado pela AWS) com uma parada rígida na abertura do mercado, enquanto o pipeline de streaming equivalente da AGCO é operado por um engenheiro em vez de três a cinco. Colocados lado a lado, eles fazem a distinção real do exame: um orquestrador de batch é julgado por terminar antes do seu prazo, um pipeline de streaming por uma pessoa conseguir mantê-lo saudável, as mesmas duas perguntas, feitas a dois modos de falha diferentes (estudo de caso da Nasdaq da AWS; AWS Architecture Monthly, dezembro de 2021, acesso em outubro de 2026).

• 📚 Você sabia? Nenhum dos estudos de caso da AWS nomeia um orquestrador: a AWS publica os resultados e deixa a conexão para você. Isso é design deliberado de exame: o DEA-C01 nunca pede que você recorde a escolha de ferramenta de um cliente, ele pede que você reconheça que 700 milhões de itens independentes implica fan-out com um limite de concorrência (Distributed Map ou Lambda), e que zero perda de dados numa troca implica estágios ordenados com validação e escritas idempotentes (estudos de caso da AWS, acesso em outubro de 2026).

---

Perguntas de Prática (Practice Questions)