Orquestrando o Lakehouse: Step Functions, EventBridge e MWAA

Dez lições adentro, você consegue aterrissar arquivos, convertê-los, curá-los em Iceberg, consultá-los com Athena e entregar o resultado ao Redshift. Nada disso responde às quatro perguntas que decidem se o lakehouse é um produto ou um passivo: o que dá início à execução, em que ordem as etapas rodam, o que acontece quando uma etapa falha, e como rodar de novo sem gravar as mesmas linhas duas vezes? Isso é orquestração, e é a camada onde a maioria dos incidentes de lakehouse realmente vive: não no SQL.

A regra de ensino desta lição é curta: o orquestrador detém tempo, ordem, falha e reexecução; a computação detém os bytes. Mantenha esses dois trabalhos separados e toda decisão de design posterior fica mais fácil.

Em esta lição você vai:

• separar os fluxos Standard e Express por garantia de entrega, teto de duração, taxa, padrões suportados e custo por transição de estado;
• ler e escrever Amazon States Language: os oito tipos de estado, os três padrões de integração e recursos de Task para Glue, EMR, Lambda e a AWS SDK;
• escolher entre Map inline e Distributed Map, e dimensionar ItemReader, ItemBatcher e ResultWriter;
• usar Parallel, Retry, Catch, TimeoutSeconds e máquinas de estados aninhadas para isolar fases e rotear falhas;
• conectar buses da Amazon EventBridge, event patterns, schedules, Pipes com filtragem e enriquecimento, API Destinations e Archive/Replay;
• dimensionar um ambiente Amazon MWAA e reconhecer os padrões de DAG do Airflow que o justificam;
• encadear AWS Glue Workflows e triggers, incluindo triggers EVENT iniciadas a partir do EventBridge;
• tornar reexecuções seguras com nomes de execução determinísticos, dedup, checkpoints e transferência de watermark;
• rodar um backfill sobre partições por data com um Distributed Map;
• aplicar uma matriz de decisão de scheduler e roles de execução de menor privilégio;
• trabalhar uma máquina de estados de bronze a silver a gold com roteamento para quarentena, dez exemplos resolvidos, uma caixa de atualizações de outubro de 2026 com fontes, material de caso do Transport for NSW, três verificações interativas e catorze questões no estilo de exame.

---

1. A superfície de orquestração: cinco ferramentas, cinco trabalhos

1.1 As cinco primitivas

Toda pergunta de orquestração se reduz às mesmas cinco primitivas. Cada uma detém uma coisa diferente, e todo cheiro de design nesse espaço é uma primitiva usada para um trabalho que não lhe pertence.

Os quatro prompts que você sempre deve responder antes de escolher: O que inicia a execução? (schedule, evento, chamada de API, sucesso upstream) Em que ordem as etapas rodam? (serial, paralelo, fan-out, condicional) O que acontece em caso de falha? (retry, catch, quarentena, alerta) Como rodar de novo sem corromper os dados? (nome idempotente, checkpoint, watermark, redrive).

• 📚 Você sabia? As Step Functions alcançam "mais de 14,000 ações de API de mais de 220 serviços da AWS" segundo o AWS Compute Blog de 2025-11-04: um post anterior do AWS What's New de 2022-12-01 colocava a mesma cifra em "mais de 200 serviços da AWS". O número é uma meta em movimento, mas o fato examinável é que a integração da AWS SDK é o escape hatch para qualquer coisa sem uma integração otimizada (AWS Compute Blog, 2025-11-04; AWS What's New, 2022-12-01).

---

2. AWS Step Functions: Standard versus Express

2.1 Dois tipos de workflow, e nenhum terceiro

Existem exatamente dois tipos de máquina de estados: Standard (o default) e Express. O tipo é imutável: escolhido na criação e nunca alterado depois. A palavra "sync" nomeia duas coisas diferentes e é a confusão mais comum deste serviço:

1. o padrão de integração .sync ("Executar um job"), onde um workflow Standard chama um serviço e bloqueia até o job terminar; e
2. Express síncrono (StartSyncExecution), onde uma execução Express é invocada de forma síncrona a partir do API Gateway, Lambda ou CLI e devolve o resultado.

A AWS enuncia a regra sem meias-palavras: os Standard Workflows "seguem um modelo exactly-once… adequado para orquestrar ações não-idempotentes, como iniciar um cluster do Amazon EMR ou processar pagamentos", enquanto os Express Workflows "usam um modelo at-least-once… mais adequados para orquestrar ações idempotentes" (Guia do Desenvolvedor do Step Functions, acesso em 2026-10-11).

2.2 Exemplo resolvido E1: um pipeline diário com nove transições

A aritmética do próprio exemplo de preços da AWS, reproduzida com as taxas publicadas (us-east-1, acesso em 2026-10-11):

O free tier é 4,000 transições de estado por mês, sem prazo. Duas lições se escondem nesse número: um pipeline diário quase nunca gera uma conta de Step Functions que valha a pena considerar, e um de alta frequência gera.

2.3 Exemplo resolvido E2, o mesmo pipeline, duas métricas

Catorze estados, 30,000 execuções por mês, sem retries (derivado das taxas publicadas, em out de 2026):

O Express cobra a duração arredondada para cima para os 100 ms seguintes, em blocos de 64 MB, e a pegada de memória é calculada como 50 MB + tamanho da definição da máquina de estados + tamanho dos dados de execução x número de passos Parallel ou Map. Os três níveis de duração que a AWS imprime no próprio Exemplo 4 são $0.0600 por GB-hour para os primeiros 1,000 GB-hours, $0.0300 para os próximos 4,000 e $0.01642 depois (Preços do Step Functions, acesso em 2026-10-11).

---

3. Amazon States Language e a camada de Task

3.1 Os oito tipos de estado

A Amazon States Language (ASL) é um documento baseado em JSON. Os tipos de estado que a AWS lista são Task, Choice, Wait, Pass, Succeed, Fail, Parallel e Map: oito deles, e a máquina de estados inteira são esses estados ligados por campos Next e End (Guia do Desenvolvedor do Step Functions, acesso em 2026-10-11).

• Task faz trabalho (chama Lambda, inicia um job do Glue, grava um item no DynamoDB).
• Choice ramifica conforme a entrada; Wait dorme; Pass remodela dados.
• Succeed e Fail encerram a execução deliberadamente.
• Parallel distribui sobre ramos escritos na definição.
• Map distribui sobre um dataset: inline ou Distributed (Seção 4).

Três cotas limitam a própria definição: o tamanho máximo da definição da máquina de estados é 1 MB (duro), o tamanho máximo de entrada ou saída de uma tarefa, estado ou execução é 256 KiB de dados codificados em UTF-8, e o tamanho máximo do histórico de execução é 25,000 eventos para um workflow Standard.

3.2 Três padrões de integração, e quais serviços levam qual

Toda integração otimizada pode ser invocada de uma de três formas:

A matriz de integrações otimizadas da AWS separa os serviços de lakehouse com clareza:

• .sync suportado: athena, batch, emr, emr-serverless, glue, glue:databrew, sagemaker, states (as próprias Step Functions aninhadas).
• Request Response mais callback (.waitForTaskToken), sem .sync: lambda, sns, sqs, dynamodb, EventBridge.
• Integração da AWS SDK: Request Response em todos os serviços suportados; .waitForTaskToken somente em Standard; nunca .sync.

Então os recursos de Task concretos que você de fato vai escrever numa máquina de estados de lakehouse são:

• 📚 Você sabia? startExecution.sync e startExecution.sync:2 não são intercambiáveis: .sync devolve a saída do filho como string, .sync:2 devolve como JSON. Analisar o errado corrompe silenciosamente toda referência Payload.$ a jusante, e a falha aparece muito depois como um campo ausente em vez de um erro de deploy (Guia do Desenvolvedor do Step Functions, acesso em 2026-10-11).

3.3 Exemplo resolvido E3, o orçamento de retry que você esqueceu de precificar

Retries não são grátis: "Retries são tratados como transições de estado", e "Se você incluir tratamento de erro com retry em qualquer etapa do seu workflow, cada retry será cobrado como uma transição de estado adicional" (Preços do Step Functions, acesso em 2026-10-11).

MaxAttempts: 0 significa nunca tentar de novo: uma escolha válida e deliberada para uma etapa que falha permanentemente e deve ir direto para um Catch.

3.4 Retry, Catch, Timeout e Heartbeat: os defaults exatos

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

• States.ALL: deve aparecer sozinho num Catcher e não pode capturar States.DataLimitExceeded nem States.Runtime.
• States.TaskFailed: um curinga para qualquer erro conhecido exceto States.Timeout.
• States.Timeout, States.HeartbeatTimeout, States.Permissions, States.ItemReaderFailed, States.ResultWriterFailed, States.ExceedToleratedFailureThreshold.
• States.DataLimitExceeded é terminal: uma tarefa que emite um payload acima de 256 KiB morre e nenhum catcher anexado aquele estado pode salvá-la.

Três regras estruturais que pegam engenheiros experientes:

1. Catchers existem em Task, Parallel e Map apenas: "não para falhas de execução de máquina de estados de nível superior". Uma falha de execução inteira precisa ser tratada pelo chamador, por um workflow aninhado ou por uma rule do EventBridge sobre o status da execução (FAILED / TIMED_OUT).
2. Se uma máquina de estados aninhada lança um States.Timeout, o pai recebe States.TaskFailed no lugar.
3. Nos runtimes mais novos do Lambda, timeouts aparecem como Sandbox.Timedout: cashe com Lambda.Unknown, Sandbox.Timedout e States.TaskFailed juntos.

3.5 Activities: a faixa de callback que espera até um ano

Activities são uma construção somente para Standard: um worker de activity faz polling com GetActivityTask, mantém a tarefa viva enviando um heartbeat com SendTaskHeartbeat dentro do TimeoutSeconds configurado, e responde com SendTaskSuccess ou SendTaskFailure. Com heartbeats, "uma activity no Step Functions pode esperar até um ano por uma execução terminar". Depois que a tarefa estoura o tempo, as Step Functions invalidam o task token e chamadas posteriores levantam TaskTimedOut.

3.6 Workflows aninhados: fases com histórico e retries próprios

Quatro recursos controlam o aninhamento: states:startExecution (dispara e esquece), .sync (espera, saída string), .sync:2 (espera, saída JSON), .waitForTaskToken (callback). Aninhar compra isolamento de histórico por fase, retries por fase e reuso, mas o pai precisa poder descobrir que o filho terminou, e essa detecção tem dois caminhos com dois conjuntos de permissões diferentes:

• polling: precisa de states:DescribeExecution;
• eventos do EventBridge: precisa de events:PutTargets, events:PutRule e events:DescribeRule.

Omita o segundo conjunto e o pai trava em vez de falhar barulhento, que é o sintoma clássico.

3.7 Exemplo resolvido F1: preenchendo um fragmento real de ASL

---

4. Map, Distributed Map, Parallel e ItemBatcher

4.1 Quando o Map inline deixa de bastar

Parallel itera sobre ramos fixos na definição; Map itera sobre um dataset. O Map inline (default) roda suas iterações dentro do histórico de execução do pai, e isso cria três tetos duros:

As condições próprias da AWS para mudar: use o modo Distributed quando "o tamanho do seu dataset exceder 256 KiB", "o histórico de eventos de execução do workflow exceder 25,000 entradas", ou "você precisar de uma concorrência acima de 40 iterações simultâneas" (Guia do Desenvolvedor do Step Functions, acesso em 2026-10-11).

Específicos do Distributed Map que valem a pena decorar:

• Fontes do ItemReader: objetos do S3 (CSV, JSON, JSONL, Parquet), ou um manifest de dados do Athena, o Compute Blog de 2025-11-04 confirma que o Distributed Map pode "processar arquivos de manifest de dados do AWS Athena e Parquet diretamente, eliminando a necessidade de pré-processamento customizado".
• ExecutionType nos filhos: STANDARD ou EXPRESS: use filhos EXPRESS para unidades de fan-out curtas e idempotentes.
• MaxConcurrency / MaxConcurrencyPath: se não definidos ou zerados, as Step Functions "não limitam a concorrência e executam 10,000 execuções filhas de workflow paralelas", e a AWS recomenda não exceder a capacidade de um serviço downstream como o Lambda.
• ToleratedFailureCount / ToleratedFailurePercentage e suas variantes ...Path: o default de porcentagem é zero, o que significa que "o workflow falha se qualquer uma de suas execuções filhas falhar ou estourar o tempo". Exceder o limiar levanta States.ExceedToleratedFailureThreshold, que precisa do seu próprio Catch.
• Cotas: 1,000 Map Runs abertos por conta/Região, 1,000 redrives por Map Run, 10,000 execuções filhas paralelas por Map Run (duro), e as Step Functions despacham filhos express a até 1,000 TPS e filhos standard a até 100 TPS.

4.2 ItemBatcher: a alavanca mais barata que você tem

O ItemBatcher agrupa itens para que cada filho receba {"Items": [...]} mais um BatchInput estático opcional. Dois pares de knobs: MaxItemsPerBatch / MaxItemsPerBatchPath, e MaxInputBytesPerBatch / MaxInputBytesPerBatchPath, o teto de bytes é 256 KiB, o próprio limite de payload do Step Functions.

O número trabalhado da própria AWS: "imagine que você executa um arquivo JSON de entrada que contém 1130 nodes. Se você especificar um valor máximo de itens de 100 para cada batch, o Step Functions cria 12 batches" (Guia do Desenvolvedor do Step Functions, acesso em 2026-10-11). Use batching "ao processar arquivos CSV grandes ou arrays JSON, ou grandes conjuntos de objetos do Amazon S3."

4.3 Exemplo resolvido E4: aritmética de batch e seu efeito na fatura

• 📚 Você sabia? As métricas de observabilidade do Distributed Map anunciadas em 2025-09-18, ApproximateOpenMapRunsCount, OpenMapRunLimit e ApproximateMapRunsBacklogSize, existem porque a profundidade do fan-out fica invisível até você bater na cota de 1,000 Map Runs abertos. Coloque alarme na métrica de backlog antes do limite, não depois (AWS What's New, 2025-09-18; AWS Compute Blog, 2025-11-04).

4.4 Projetos de exemplo que valem a pena ler antes de você construir um

Dois projetos de exemplo da AWS são bons materiais didáticos: um pipeline de dados de clima onde "os dados de clima são registrados em mais de 12,000 arquivos CSV" com MaxConcurrency em 3,000, copiando, depois analisando e depois reduzindo no DynamoDB; e um pipeline de CSV de pedidos de envio com "10,000 linhas de um arquivo CSV" processado em lotes de 10 com MaxConcurrency 1,000, gravando resultados no S3 por meio do ResultWriter (projetos de exemplo do Step Functions, acesso em 2026-10-11).

---

5. Uma máquina de estados de lakehouse trabalhada: bronze a silver a gold

Esta é a forma que você deve conseguir desenhar de memória. Um pai Standard hospeda um Distributed Map (o Express não poderia), os filhos rodam como execuções EXPRESS com MaxConcurrency: 100 para que a concorrência de jobs do Glue em nível de conta nunca fique esgotada, e a falha parcial vai para a quarentena em vez de falhar em silêncio.

Notas de ensino, todas estruturais:

1. SilverMap precisa ser Distributed, o teto de 40 iterações de um Map inline e o histórico dividido de 25,000 eventos matariam uma execução com milhares de partições.
2. ItemBatcher.MaxItemsPerBatch: 20 transforma milhares de arquivos em dezenas de filhos. Filhos são a unidade tanto de paralelismo quanto de cobrança.
3. Retry no Map cria um novo Map Run: limite MaxAttempts e use redrive (janela de 14 dias, somente Standard) para reexecuções de Map inteiro.
4. Catch em States.ExceedToleratedFailureThreshold leva a falha parcial para a quarentena. Sem ele, estourar o limiar é uma falha de execução não tratada.
5. O watermark é gravado por último. Registre s3://lake/_checkpoints/silver/dt=2026-10-11.json somente depois que PublishCatalog tiver sucesso: é isso que torna idempotente o retrigger do mesmo dia.
6. A quarentena é um destino, não um estado. Aterrisse as chaves de partição que falham em algum lugar que um humano ou um sistema de tickets possa ver.
7. ValidateInput é um estado Choice, e o ramo FailFast termina num estado Fail: uma saída barata e antecipada vence descobrir um intervalo de data ruim três horas dentro de um fan-out.

5.1 Exemplo resolvido E5: precificando esta máquina exata

Esta é a lição de custo mais importante desta lição: o Step Functions é um erro de arredondamento ao lado da computação que ele agenda. Otimize para roteamento de falha e segurança de reexecução, não para contagem de transições: com a única exceção de políticas de retry ilimitadas (Seção 3.3).

---

6. Amazon EventBridge para o lakehouse

6.1 Buses, rules, cotas

A AWS dá a toda conta um event bus default que recebe eventos de mudança de estado dos serviços da AWS (eventos de management entram grátis; data events opcionais como os do S3 precisam ser habilitados). A página de preços descreve quatro tipos de event bus: o bus default; dois buses custom, Custom event bus: Classic (julho de 2019) e um Custom event bus aprimorado lançado em setembro de 2026, e um partner event bus para eventos de fornecedores de SaaS (Preços do Amazon EventBridge, acesso em 2026-10-11).

6.2 Event patterns

Os patterns casam com source, detail-type, account, region e detail, com o conjunto de operadores And, anything-but (incluindo formas prefix, suffix, ignore-case e wildcard), prefix, suffix, empty, equals-ignore-case, exists, null, intervalos numeric, $or, wildcard e cidr. Duas arestas afiadas: "Atualmente, o caractere curinga é suportado apenas em regras de event bus", e qualquer pattern onde $or se expanda para mais de 1,000 combinações de regra faz PutRule, CreateArchive, UpdateArchive e TestEventPattern lançarem InvalidEventPatternException (Guia do Usuário do EventBridge, acesso em 2026-10-11).

6.3 Schedules: rules legadas versus EventBridge Scheduler

As rules agendadas são explicitamente "um recurso legado do EventBridge" e a AWS "recomenda que você use o Scheduler para invocar targets em um cronograma". O cron legado tem seis campos obrigatórios (minutos, horas, dia do mês, mês, dia da semana, ano) e "expressões cron que levam a taxas mais rápidas que 1 minuto não são suportadas"; tudo roda em UTC.

O EventBridge Scheduler é a resposta atual: três tipos de schedule, rate-based, cron-based e one-time, com "precisão de 60 segundos", tratamento automático de horário de verão (numa lacuna de avanço a invocação é pulada), janelas de tempo flexíveis de 1 a 1,440 minutos, políticas de retry e de idade de evento, e targets com template em centenas de serviços da AWS. Cotas: 10,000,000 schedules por Região, 5,000 TPS de CreateSchedule, 1,000 TPS de invocações.

Preços: $1.00 por milhão de invocações após 14,000,000 invocações grátis por mês (Preços do EventBridge, acesso em 2026-10-11).

6.4 Pipes: origem para filtro para enriquecimento para target

Um pipe é "escolha a origem, adicione filtragem opcional, defina enriquecimento opcional e escolha o target": com ordenação preservada quando a origem a impõe, batching, relatório de falha parcial e seu próprio papel IAM sob pipes.amazonaws.com.

• Origens: DynamoDB Streams, streams do Kinesis, Amazon MQ, MSK, SQS e Apache Kafka (auto-gerenciado, Confluent Cloud, CloudKarafka, Redpanda). Não trate nenhuma lista publicada como exaustiva: a página da documentação da AWS é a autoridade.
• Targets: API destination, API Gateway, fila de jobs do Batch, grupo de logs do CloudWatch, task do ECS, event bus da mesma conta e mesma Região, delivery stream do Firehose, stream do Kinesis, Lambda (SYNC ou ASYNC), consultas do Redshift Data API, pipelines do SageMaker AI, tópico SNS (FIFO não suportado), fila SQS, Step Functions (Express SYNC ou ASYNC; Standard precisa ser ASYNC), Timestream.
• Tetos de payload: os Pipes aceitam 6 MB, mas o target limita você: um target de event bus é 1 MB e um target de máquina de estados do Step Functions é 256 KB. Saída de enriquecimento acima do limite do target falha a invocação.
• Tamanhos de batch são o mínimo entre origem e target: Kinesis permite lotes de 10,000 registros, targets SQS só 10, Firehose e Kinesis 500, CloudWatch Logs 10,000, event bus 10, SNS 10, então o pipe trava no menor número.
• Teto de execução do pipe: 5 minutos incluindo enriquecimento e processamento do target: "Este limite atualmente não pode ser aumentado."
• Defaults de concorrência: SQS 1,250; Kafka até a contagem de partições (máx. 1,000); Amazon MQ 5; Kinesis e DynamoDB = ParallelizationFactor multiplicado pelo número de shards.
• Falha parcial de batch usa o formato de payload {"batchItemFailures": [{"itemIdentifier": "id2"}]}.
• Cobrança: "Você é cobrado apenas pelos eventos que correspondem ao filtro": $0.40 por milhão de requisições, medido em blocos de 64 KB, após o filtro.

6.5 API Destinations, Archive e Replay

As API Destinations permitem que uma rule chame um endpoint HTTP externo por meio de uma conexão gerenciada pela AWS: $0.20 por milhão de eventos, com 3,000 destinations e 3,000 conexões por conta/Região e 300 invocações por segundo por destination.

Archive e Replay é a caixa preta de eventos do lake. "Por padrão, o EventBridge armazena eventos no archive indefinidamente"; "Reproduzir eventos não os remove do archive… o EventBridge só remove eventos quando eles excedem o período de retenção do archive, ou quando você deleta o próprio archive"; replays são deletados após 90 dias; você pode ter no máximo 10 replays ativos simultâneos por conta por Região; e "você só pode reproduzir eventos para o mesmo event bus que emitiu os eventos."

6.6 O caminho de eventos do lakehouse: S3 direto no EventBridge

Com o EventBridge habilitado, o S3 entrega todo evento em nível de objeto sem configuração por tipo: uma rule filtra source: aws.s3, detail-type: Object Created, o nome do bucket, um prefix de bronze/orders/ e um suffix de _SUCCESS, e aponta para uma máquina de estados, um Pipe, uma função Lambda ou uma fila SQS. Isso substitui as notificações de eventos S3 por tipo mais um fan-out por Lambda quando você precisa de muitos consumidores, filtragem por conteúdo, archives e roteamento entre contas.

6.7 Exemplo resolvido E6: a conta do lake orientado a eventos

• 📚 Você sabia? O S3 não faz você enumerar tipos de evento. Com o EventBridge habilitado na conta, "você não precisa selecionar quais tipos de evento deseja entregar": todos fluem, incluindo Object Created, Object Deleted, Restore Initiated / Completed / Expired, Storage Class Changed, Object Tags Added/Deleted, Retention Updated e Annotation Created/Removed. O filtro pertence à rule, não a uma configuração de notificação por tipo (Guia do Usuário do Amazon S3, acesso em 2026-10-11).

---

7. Orquestração idempotente: sobrevivendo à segunda execução

7.1 Quatro mecanismos, na ordem em que você os constrói

Os nomes são únicos por conta e Região, limitados a 80 caracteres, e o histórico de execução é retido por 90 dias (reduzível para 30 por requisição de cota). Um padrão diário prático:

7.2 Checkpoints e transferência de watermark

As Step Functions não rastreiam watermarks de dados; este é um padrão de engenharia construído sobre primitivas verificadas, não um recurso gerenciado. Persista o watermark depois da confirmação, em um destes: um item do DynamoDB, um objeto marcador no S3 como _checkpoints/silver/dt=2026-10-11.json, um snapshot id do Iceberg, ou um bookmark do job do Glue. O leitor deve então tirar seu limite inicial desse watermark, o que faz a releitura de uma janela fechada ser um no-op em vez de uma gravação duplicada.

Três regras baratas de determinismo completam o quadro: derive chaves de objeto e identificadores de contexto de (layer, partition_date, source); mantenha todo campo Payload downstream referenciado por caminhos .$ em vez de assumido; e faça do marcador de sucesso a única coisa em que uma rule downstream filtra, de modo que uma gravação parcial nunca possa se passar por conclusão.

7.3 Exemplo resolvido E7: desenhando a reexecução segura

7.4 Ordenando o pipeline idempotente

---

8. Backfill com um Distributed Map sobre partições por data

Backfill é onde o Distributed Map deixa de ser uma curiosidade e vira a ferramenta mais barata que você tem: uma execução pai, centenas de filhos por partição de data, concorrência limitada pelo que o Glue de fato absorve.

8.1 Exemplo resolvido E8: um backfill de 90 dias

Três regras para backfills de produção:

1. Limite MaxConcurrency ao serviço downstream. A própria orientação da AWS: "recomendamos que você não exceda a capacidade de um serviço AWS downstream, como o AWS Lambda", e 10,000 filhos de uma vez estourariam a cota de jobs da conta no Glue na hora.
2. Defina ToleratedFailurePercentage deliberadamente. O default é zero, então uma única partição corrompida derruba o Map Run inteiro.
3. Prefira redrive a Retry num Map. Tentar de novo um estado Map "cria um novo Map Run"; redrive reusa o existente dentro da janela de 14 dias.

• 📚 Você sabia? Um backfill também é o jeito mais barato de testar seu design de idempotência: reexecute uma janela que já foi confirmada e observe se o writer converge ou anexa. Se a segunda execução mudar as contagens de linhas, sua transferência de watermark está quebrada antes que um encontro a encontre por você.

---

9. Amazon MWAA: Airflow gerenciado para o lakehouse

9.1 O que um ambiente realmente é

A Amazon MWAA roda o Apache Airflow no AWS Fargate, workers, schedulers e um web server, apoiada por um banco de metadados Aurora PostgreSQL de tenant único na sua própria VPC, com DAGs e plugins armazenados num bucket S3. Os tamanhos vão de mw1.micro, mw1.small, mw1.medium, mw1.large, mw1.xlarge a mw1.2xlarge. Auto-scaling: workers 10 default / 1 mínimo / 25 máximo, voltando ao mínimo quando tarefas enfileiradas mais em execução ficam em zero por mais de dois minutos; schedulers 2 default / 2 mínimo / 5 máximo.

A orientação de dimensionamento da AWS é direta: "Recomendamos escolher o menor tamanho necessário para suportar sua carga de trabalho."

Armazenamento do banco de metadados: $0.10 por GB-mês. Todas as taxas dos EUA Leste (Virgínia) a partir do arquivo de oferta da Lista de Preços da AWS publicado em 2026-09-11, acesso em 2026-10-11. O mw1.xlarge entrega 8 vCPU / 24 GB para scheduler e worker com default de 40 tarefas e até 2,000 DAGs; o mw1.2xlarge entrega 16 vCPU / 48 GB, 80 tarefas, 4,000 DAGs; um upgrade de tamanho de ambiente leva 20 a 30 minutos para concluir.

Você paga "pelo tempo em que seu Airflow Environment roda mais qualquer auto-scaling adicional", cobrado em resolução de um segundo: é por isso que a taxa do ambiente, não a do worker, domina a conta.

9.2 Higiene de versões

Em outubro de 2026 a MWAA oferece Airflow 3.3.1 (disponível desde 2026-09-01, Python 3.12), 3.2.1 (2026-05-19), 2.11.2 (2026-07-23), 2.11.0 (2026-01-07) e 3.0.6 (2025-10-01). Em 30 de dezembro de 2025, a Amazon MWAA encerrou o suporte às versões v2.4.3, v2.5.1 e v2.6.3 do Apache Airflow. A AWS se compromete a suportar pelo menos três versões menores em qualquer momento, pelo menos 12 meses por versão, com 180 dias de anúncio de fim de suporte.

Duas restrições que mordem: a MWAA suporta upgrades de versão menor in place, "mas não para uma nova versão principal", então de Airflow 2 para 3 é migração, não upgrade, e a partir do Airflow v2.7.2 seu arquivo de requirements precisa incluir uma declaração --constraint. A AWS também documenta que "a Amazon MWAA atualmente não suporta o modo multi-team."

9.3 Quais padrões de DAG de lakehouse a MWAA paga

O Airflow paga seu custo sempre ligado em exatamente quatro situações:

1. Retomada por checkpoint em janelas longas. O próprio blog da MWAA versus Step Functions da AWS de 2026-06-10 enquadra a MWAA em torno de "retomar do último checkpoint bem-sucedido" para "processos de longa duração que se estendem por 2-12 horas" sobre "5-10 TB de dados de transações financeiras diariamente", contra a "lógica de retry embutida com backoff exponencial" e a "execução paralela" do Step Functions.
2. DAGs legíveis entre equipes com semântica catchup, sensors e uma UI para backfills.
3. Backfills sazonais ou parametrizados onde um analista escolhe um intervalo de datas e espera uma visão de progresso.
4. Tipos de tarefa heterogêneos, ECS, Bash, Python, APIs externas, sob um único grafo de dependências.

9.4 Exemplo resolvido E9: MWAA versus Step Functions por mês

O exemplo de ambiente grande da própria AWS chega a $1,047.46 por mês, dos quais o ambiente ($736.56) mais os schedulers ($163.68) é algo como 86% de custo fixo: que é exatamente a lacuna que o MWAA Serverless endereça. Um pipeline de uma vez por dia num ambiente medium custa 744 x $0.74 = $550.56 por mês antes de qualquer worker rodar.

• 📚 Você sabia? O MWAA Serverless (GA 2025-11-17, disponível em 15 regiões da AWS no lançamento) é uma opção de deployment separada, não um nível de tamanho: os workflows são definidos em YAML (um DAG Python convertido para YAML), iniciados com start-workflow-run, escopados por IAM por workflow, e cobrados "por tarefa, pela sua duração, com mínimo de 1 minuto" a $0.08 por hora para a tarefa gerenciada pela AWS: com "escala automática baseada na demanda do workflow" e nenhum ambiente para dimensionar (Guia do Usuário do Amazon MWAA Serverless; AWS Big Data Blog, 2025-11-17).

---

10. AWS Glue Workflows e triggers de eventos

O Glue pode orquestrar a si mesmo sem Step Functions. "Um trigger dispara sob demanda, com base em um cronograma, ou com base em uma combinação de eventos", com valores de Type SCHEDULED, CONDITIONAL, ON_DEMAND e EVENT.

Quatro armadilhas que valem a pena memorizar:

1. Triggers condicionais só veem execuções iniciadas por um trigger. Se um job foi iniciado de outra forma, sua conclusão nunca dispara o trigger condicional.
2. Uma execução de workflow iniciada pelo EventBridge que falha consome seu evento: "aquele evento ou lote de eventos não é mais considerado para iniciar uma execução de workflow", e não há reentrega.
3. O Glue não tenta de novo execuções de workflow que falham por limites de concorrência excedidos.
4. Crawlers e jobs não são intercambiáveis dentro de um trigger, o teto de dois crawlers é uma regra dura, e exceder 100 componentes pode quebrar as operações de retomada e parada.

10.1 Exemplo resolvido E10: cadeia só de Glue versus Step Functions

---

11. Segurança: roles de execução de menor privilégio

As roles de orquestração são uma superfície de escalada de privilégio, porque uma máquina de estados pode iniciar jobs que gravam no seu lake. O exemplo de menor privilégio do Distributed Map da própria AWS concede exatamente duas coisas:

A forma desse segundo statement é o ponto: StartExecution recebe um ARN de máquina de estados; DescribeExecution e StopExecution recebem um ARN de execução. Conceder DescribeExecution contra stateMachine:... não concede nada.

Um checklist completo de menor privilégio para um orquestrador de lakehouse:

---

12. A matriz de decisão do scheduler

12.1 A matriz

Duas entradas que pertencem ao quadro mas raramente são ensinadas:

• cron numa instância EC2: auto-operado, sempre ligado, sem histórico de execução, sem primitivas de retry, sem trilha de auditoria além dos seus próprios logs. É a linha de base da qual todo mundo começa, e é o que toda opção gerenciada está argumentando contra. Escolha-o apenas quando você já roda essa frota por outras razões e o cronograma é trivial.
• Orquestradores de terceiros (Airflow de código aberto que você opera você mesmo, ou um orquestrador comercial): você compra portabilidade de engine e o skill set que a equipe já tem, e assume o scheduler, o banco de metadados, upgrades e a plantão. A ZS publicou exatamente essa avaliação, comparando "Amazon MWAA, Azkaban on Amazon EMR, e AWS Step Functions" antes de escolher a MWAA com contas AWS por cliente para isolamento de tenant (AWS Big Data Blog, 2022-09-16).

12.2 Verificação de correspondência: padrão para ferramenta

---

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

• 📚 Você sabia? O padrão de roteamento S3 para EventBridge para Glue/Firehose não mudou em 2026, o que mudou é onde o resultado transformado pode aterrissar: Firehose for S3 Tables foi para GA em 2025-03-14, então a mesma cadeia orientada a eventos agora pode terminar numa tabela Iceberg gerenciada em vez de um prefixo cru (AWS Big Data Blog, 2025-03-14). A forma da orquestração está estável; os destinos se alargaram.

---

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, não o marketing.

Caso A, Transport for NSW: mais de 400 workflows fora de uma ferramenta de ETL licenciada

"A equipe também usou o AWS Step Functions, para melhorar a orquestração e o monitoramento de workflows… Para armazenamento escalável, a equipe adotou o Amazon Simple Storage Service (Amazon S3) como fundação do seu data lake.": estudo de caso da AWS (acesso em 2026-10-11)

A lição de orquestração é a que a própria AWS coloca na faixa de benefícios: remover a conta da licença foi a vitória financeira, mas o Step Functions foi o mecanismo que transformou orquestração e monitoramento numa competência compartilhada em vez de uma especialidade. "Mais membros de equipe capazes de gerenciar workflows de dados em ferramentas nativas de nuvem, removendo a dependência de expertise em plataforma legada" é um desfecho de orquestração, não de ETL.

Caso B, TrueCar: remover o cronograma, não tuning no motor

O ponto de orquestração: os 48x da TrueCar vieram de remover o cronograma de batch, não de um motor de consulta mais rápido. Quando o gatilho muda de um cron noturno para um evento, a camada de orquestração muda junto: que é o argumento da Seção 6 num único número de cliente. As barras do TfNSW são conversões em índice da redução de custo de "80%" publicada pela AWS e do prazo que caiu de "vários meses" para "Menos de 3 semanas", mostradas contra uma linha de base legada de 100.

Caso C, Cisco Webex: roteamento orientado a eventos a 147 TB por dia

A leitura de orquestração: o volume de eventos da Cisco (100+ bilhões de mensagens por dia) é precisamente o regime onde um cron de polling não pode competir com um event bus com filtro por conteúdo, e onde o modelo origem, filtro, enriquecimento, target dos Pipes vence uma frota de consumidores sob medida. Decisões de roteamento nessa taxa pertencem a patterns, não a código.

• 📚 Você sabia? Todo número desta seção é a medição de um cliente sobre uma carga de trabalho, e as páginas do TfNSW e do Cisco estão sem data: a AWS publica apenas "acesso em outubro de 2026" para elas. Nunca os restate como especificações atuais da AWS; são instantâneos datados de migrações específicas (digest 18, fontes S3, S8, S12).

---

Perguntas de Prática (Practice Questions)