Orquestando pipelines de datos: Step Functions, EventBridge y Airflow

Un pipeline de datos que transforma correctamente pero que arranca tarde, se ejecuta dos veces, omite en silencio un paso fallido o no se puede reproducir también ha fallado. La ingesta y la transformación (lecciones 02 y 03) deciden qué se mueve y cómo se remodela; la orquestación decide cuándo se ejecuta, en qué orden, qué pasa cuando falla y cómo te recuperas, y el DEA-C01 evalúa exactamente ese juicio en el dominio 1, tarea 1.3 «Orquestar pipelines de datos», mediante cuatro habilidades: 1.3.1 servicios de orquestación (AWS Lambda, Amazon EventBridge, Amazon MWAA, AWS Step Functions, AWS Glue workflows), 1.3.2 pipelines resilientes y escalables, 1.3.3 workflows serverless y 1.3.4 alertas mediante SNS y SQS (guía del examen DEA-C01, consultada en octubre de 2026).

En esta lección vas a:

• distinguir los workflows Standard y Express por duración, garantía de entrega, facturación y patrones de integración soportados;
• leer y escribir Amazon States Language: los ocho tipos de estado, Retry, Catch, los nombres de error integrados y los estados de error terminales;
• elegir entre Map en línea y Distributed y dimensionar ItemReader, ItemBatcher y ResultWriter;
• construir reglas de EventBridge sobre schedules y patrones de eventos, entendiendo buses, targets, políticas de reintento y DLQ;
• usar EventBridge Pipes para fan-out de streams y colas sin código y EventBridge Scheduler para schedules conscientes de la zona horaria;
• describir un entorno Amazon MWAA, su almacenamiento de DAGs, los operators, las clases de worker y las versiones de Airflow;
• conectar AWS Glue Workflows y triggers (schedule, on-demand, EventBridge, condicional) en un solo grafo;
• aplicar la matriz de selección de orquestación: cron → EventBridge, reintentos en varios pasos → Step Functions, DAGs complejos → MWAA, flujos reactivos a eventos → Pipes;
• aplicar los patrones de reintento, DLQ, idempotencia y backfill que hacen resiliente a un pipeline;
• estudiar cuatro casos de clientes de AWS, leer el cuadro de actualizaciones de octubre de 2026 y practicar con 14 preguntas de estilo examen más comprobaciones interactivas.

---

1. La superficie de la orquestación: cinco primitivas, un trabajo

1.1 Lo que la tarea 1.3 pregunta de verdad

Toda pregunta de orquestación de este examen se reduce a cuatro cuestiones: ¿Qué inicia la ejecución? (schedule, evento, llamada a API, éxito aguas arriba) ¿En qué orden corren los pasos? (serial, paralelo, fan-out, condicional) ¿Qué pasa ante un fallo? (reintento, catch, alerta, estacionamiento en una DLQ) ¿Cómo lo vuelves a ejecutar sin corromper los datos? (backfill, redrive, idempotencia). Servicios distintos responden a esas cuatro cuestiones de maneras distintas, y los distractores del examen son siempre un servicio correcto usado para la pregunta equivocada.

La categoría Application Integration de la lista de servicios en alcance del DEA-C01 es exactamente esta familia: Amazon EventBridge, Amazon MWAA, Amazon SNS, Amazon SQS, AWS Step Functions, con AWS Lambda como la cómputo que la mayoría de ellas invoca (página de servicios en alcance del DEA-C01, consultada en octubre de 2026).

1.2 Resiliente y escalable es una lista de comprobación, no un adjetivo

La habilidad 1.3.2 espera que nombres los mecanismos, no que los admires:

1. Reintento con backoff y jitter: los fallos transitorios se vuelven a ejecutar automáticamente antes de que alguien reciba una alerta.
2. Catch / estado de error: los fallos irrecoverables se enrutan a un lugar definido en lugar de desaparecer.
3. Dead-letter queue (DLQ): los eventos o mensajes que agotaron sus reintentos se conservan para inspección y reprocesamiento.
4. Idempotencia: la misma entrada procesada dos veces produce la misma salida una sola vez (escrituras condicionales, claves de idempotencia, job bookmarks).
5. Backfill y redrive: volver a ejecutar deliberadamente una ventana del historial o un conjunto de ejecuciones fallidas.
6. Alertas: SNS para humanos, SQS para máquinas, alarmas de CloudWatch sobre las métricas (ExecutionsFailed, ExecutionThrottled, FailedInvocations, InvocationThrottleCount).

• 📚 ¿Sabías que…? Los cuatro nombres de métricas de CloudWatch anteriores son el atajo de diagnóstico más barato del examen: ExecutionsFailed y ExecutionThrottled pertenecen a Step Functions, mientras que FailedInvocations y InvocationThrottleCount pertenecen a los targets y Pipes de EventBridge. Una pregunta que empareja la métrica equivocada con el servicio equivocado está comprobando si sabes qué capa falló: la máquina de estados, o la entrega del evento a su destino (documentación de AWS CloudWatch, consultada en octubre de 2026).

---

2. AWS Step Functions: Standard frente a Express

2.1 El eje central del examen

AWS ofrece dos tipos de workflow, y la diferencia no es la velocidad: es la duración, la garantía de entrega, el medidor y los patrones de integración disponibles (guía para desarrolladores de Step Functions, Standard vs Express, consultada en octubre de 2026):

La regla de una línea: todo lo que deba esperar (.sync, .waitForTaskToken, una aprobación humana de días, una ejecución de un año) o deba ser exactamente una vez es un workflow Standard; todo lo que sea corto, de alto volumen e idempotente es un workflow Express.

2.2 Ejemplo resuelto E1: precificar un pipeline Standard

Un pipeline nocturno tiene 9 transiciones de estado por ejecución; un estado reintenta 3 veces antes de tener éxito, añadiendo 3 transiciones por ejecución (los reintentos son transiciones de estado facturables). Se ejecuta 10.000 veces al día durante un mes de 30 días (precios de Step Functions, us-east-1, en octubre de 2026):

De ahí salen dos lecciones: los reintentos cuestan dinero (son transiciones), y un estado Wait en bucle es un medidor que activas a propósito.

2.3 Ejemplo resuelto E2: mismo pipeline, dos tipos de workflow

El mismo job de 6 estados, 4 segundos, menos de 64 MB, ejecutado 1.000 veces:

Más de 20 veces más barato para Express con esta forma, y la brecha se ensancha a medida que crece la duración, porque Express factura la duración mientras que Standard factura solo transiciones. La propia publicación de optimización de costes de 2022 de AWS ilustra la misma asimetría con una comparación de $0.42 de Standard frente a $0.01 de Express (AWS News Blog, 2022-08-30). La pregunta de examen consecuente es la contraria: un workflow que espera 12 horas en un estado Wait quemaría transiciones si lo sondearas, mientras que un token de callback espera gratis (véase E9).

• 📚 ¿Sabías que…? Los workflows Express son el único tipo de workflow que puedes iniciar con StartSyncExecution desde la consola, y ese resultado síncrono de consola caduca a los 60 segundos, así que todo lo que dure más pertenece a una llamada SDK/CLI. El anidamiento también está oficialmente avalado: un padre Standard puede iniciar un hijo Express anidado, e iniciar un workflow anidado cuesta exactamente una transición de estado (páginas de precios y buenas prácticas de Step Functions, consultadas en octubre de 2026).

---

3. Amazon States Language: los ocho tipos de estado

3.1 El vocabulario

Las máquinas de estados se definen en Amazon States Language (ASL): un lenguaje declarativo basado en JSON (especificación states-language.net, consultada en octubre de 2026):

Todo estado declara Type y ya sea Next xor End, más los filtros de entrada/salida InputPath, ResultPath, OutputPath, un TimeoutSeconds opcional, y los arrays opcionales Retry y Catch. El lenguaje de consultas es JSONPath (rutas escritas con el sufijo .$, por ejemplo "Bucket.$": "$.bucket") o JSONata (bloques {% … %}). Las rutas de contexto alcanzan la propia ejecución: $$.Execution.Id, $$.State.Name, $$.Task.Token y $$.Map.Item.*.

3.2 Ejemplo resuelto E3: un fragmento real de ASL

Léelo como una historia: el job de Glue se ejecuta de forma síncrona (.sync espera a que termine el job), los tiempos de espera nunca se reintenta mientras que todo lo demás reintenta hasta 5 veces con backoff exponencial y jitter completo, los errores irrecoverables se capturan en $.error y se enrutan a una alerta SNS, un Choice hace cumplir un contrato de datos, y el estado terminal es un Fail explícito: la definición de estado de error del examen.

3.3 Mecánica del reintento: los arrays se recorren de arriba abajo

• Retriers (Retry[]) se recorren en orden de array; manda la primera entrada cuyo ErrorEquals coincida. Por eso ["States.Timeout"] con MaxAttempts: 0 debe ir antes que ["States.ALL"]; esta es la configuración canónica de «reintentar todo salvo los tiempos de espera».
• Valores por defecto (cuando omites un campo): IntervalSeconds 1, MaxAttempts 3 (o sea 4 intentos en total), BackoffRate 2.0 (debe ser ≥ 1.0), JitterStrategy NONE a menos que fijes FULL.
• Catchers (Catch[]) se ejecutan solo cuando no hay una entrada de Retry coincidente o los reintentos se agotaron; cada uno lleva ErrorEquals, Next y normalmente un ResultPath como $.error, de modo que la carga útil del fallo no sobrescriba tus datos.

3.4 Nombres de error integrados que no debes confundir

3.5 Ejemplo resuelto E4: aritmética del tiempo de reintento

Con los valores por defecto (IntervalSeconds: 1, BackoffRate: 2.0, MaxAttempts: 3):

Fija IntervalSeconds: 30, MaxAttempts: 5, BackoffRate: 2.0 y las esperas pasan a ser 30 + 60 + 120 + 240 + 480 = 930 segundos (15,5 minutos) antes de que la tarea se declare fallida: la configuración de E3. JitterStrategy: "FULL" aleatoriza cada retardo dentro de su ventana para que una flota de ejecuciones no reintente al unísono (documentación de manejo de errores de Step Functions, consultada en octubre de 2026).

3.6 Tokens de tarea: esperar sin costar nada

Para trabajos que ningún patrón .sync cubre, una aprobación humana, una API de terceros, un worker externo, la máquina de estados inyecta el token y espera:

Más adelante, el worker externo llama a SendTaskSuccess, SendTaskFailure o SendTaskHeartbeat. La espera es ilimitada (hasta el límite de 1 año de Standard), no es facturable y existe solo en Standard: así que siempre define HeartbeatSeconds; de lo contrario, un callback perdido se queda colgado hasta el tiempo de espera del estado en lugar de fallar rápido con States.Timeout.

• 📚 ¿Sabías que…? Un estado de aprobación humana que permanece abierto tres días cuesta cero transiciones de estado por hora: las transiciones se gastaron entrando y saliendo del estado, no esperando dentro. Esa asimetría es la razón por la que los diseños de larga duración más baratos colocan un .waitForTaskToken donde de otro modo viviría un bucle de Wait con sondeo: 1.000 sondeos por hora cuestan $3.00 al mes, y un callback con token cuesta una sola transición (ejemplo resuelto E9; precios de Step Functions, en octubre de 2026).

3.7 Integraciones de servicio: qué patrón admite cada servicio

Step Functions incluye integraciones optimizadas (el servicio interpreta la llamada) más una integración genérica del AWS SDK que cubre más de 220 servicios de AWS (AWS What's New, 2026-03-26: +28 servicios / 1.100+ APIs):

Optimizado ≠ SDK: la integración optimizada de Lambda analiza automáticamente la carga útil de la respuesta, la integración optimizada de Glue devuelve JobName + JobRunID, y EMR renombra JobFlowId a ClusterId. Las llamadas de callback y .sync también necesitan permisos IAM adicionales (glue:GetJobRun, ecs:RunTask más iam:PassRole): un favorito del examen cuando un pipeline «funciona en la consola y falla en producción».

---

4. El estado Map: en línea frente a Distributed

4.1 Cuándo ocurre el cambio

Map itera un array de entrada. En línea (el valor por defecto) ejecuta cada iteración dentro del propio historial de ejecución del padre; el modo Distributed ejecuta cada iteración como una ejecución de workflow hija con su propio historial (guía para desarrolladores de Step Functions, Map state, consultada en octubre de 2026):

La configuración vive en ProcessorConfig: { "Mode": "DISTRIBUTED", "ExecutionType": "EXPRESS" | "STANDARD" } más los campos siguientes:

• ItemReader (+ ReaderConfig.InputType): de dónde salen los elementos; MaxItems ≤ 100.000.000, y MaxItems XOR MaxItemsPath.
• ItemsPath / ItemSelector: qué elementos, y cómo se remodela cada uno antes de que corra el hijo.
• ItemBatcher: MaxItemsPerBatch, MaxItemsPerBatchBytes (≤ 256 KiB).
• MaxConcurrency / MaxConcurrencyPath: nunca lo pongas por encima de la capacidad aguas abajo.
• ResultWriter: los resultados aterrizan en S3, no en el historial del padre.

4.2 Ejemplo resuelto E5: aritmética de ItemBatcher

Un Distributed Map hace fan-out de 1.130 objetos con MaxItemsPerBatch: 100:

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

El batching importa porque cada lote se convierte en una ejecución hija, y cada ejecución hija cuesta al menos una transición de estado (o, para hijos Express, una petición). 1.130 hijos son 1.130 ejecuciones; 12 hijos son 12: mismo trabajo, una fracción de la sobrecarga. Para un backfill de S3 de 1.000.000 de objetos la aritmética es de otra clase: el Map en línea agotaría el historial de 25.000 eventos mucho antes del último objeto, así que necesitas ItemReader sobre s3:listObjectsV2, ItemBatcher, MaxConcurrency dimensionado a la capacidad aguas abajo (por ejemplo 1.000), hijos con ExecutionType: "EXPRESS", ToleratedFailurePercentage: 1, y ResultWriter hacia S3.

---

5. Amazon EventBridge: reglas, buses, reintentos y DLQ

5.1 Tres tipos de bus, una regla por bus

Una regla observa exactamente un bus. Los schedules nunca están permitidos en los buses de eventos partner; la referencia de la API documenta expresiones de schedule en los buses predeterminado y personalizado (API de EventBridge PutRule, consultada en octubre de 2026): así que trata «schedule en un bus partner» como siempre erróneo.

5.2 Dos formas de regla, y un schedule

Una regla coincide con un patrón de eventos (filtrado sobre campos JSON, hasta 2.048 caracteres) o con una expresión de schedule, o con ambas:

5.3 Ejemplo resuelto E6: escribir la regla cron

Requisito: «lanzar la carga del almacén a las 20:00 UTC cada día, y también cada vez que un archivo aterriza en el prefijo raw.» Una sola regla no puede hacer ambas cosas limpiamente en una sola expresión como exige el examen: creas dos reglas en el mismo bus:

Observa los detalles que el examen verifica: la precisión del schedule es de 1 minuto en UTC+0, así que cron(0 20 * * ? *) son las 20:00 UTC y no la hora local; los targets de Step Functions se invocan de forma asíncrona; y una regla lleva un máximo de 5 targets.

5.4 Política de reintento y dead-letter queue

Por target puedes anular la política de reintento de entrega y adjuntar una DLQ (EventBridge, Retry policy and DLQ, consultada en octubre de 2026):

5.5 Ejemplo resuelto E7: de reintentos de 24 horas a una DLQ de 10 minutos

Un equipo quiere que los fallos salgan a la luz en 10 minutos, no al día siguiente:

La DLQ debe ser una cola estándar de SQS en la misma región: una cola FIFO no puede usarse como DLQ de EventBridge. Los mensajes que llegan llevan atributos como ERROR_CODE, EXHAUSTED_RETRY_CONDITION y RETRY_ATTEMPTS, y una cola cifrada con KMS necesita kms:Decrypt para events.amazonaws.com.

• 📚 ¿Sabías que…? Algunos fallos no se reintenta nunca: un permiso ausente, un recurso borrado o un DNS defectuoso va directo a la DLQ con cero reintentos, y por eso «no hubo reintentos» en un ticket de soporte suele significar un problema de IAM o de recursos, y no un error de la política de reintento. Y las DLQ de EventBridge son colas estándar de SQS a secas: no puedes usar una cola FIFO, así que una pregunta que ofrece «SQS FIFO como DLQ de EventBridge» es un distractor incorporado (documentación de DLQ de EventBridge, consultada en octubre de 2026).

5.6 Cuotas que vale la pena memorizar (en octubre de 2026)

• 📚 ¿Sabías que…? EventBridge también orquesta pipelines de seguridad, no solo de datos: Amazon Macie emite sus hallazgos al bus predeterminado, y una regla puede enrutarlos hacia un Lambda o un flujo de remediación de Step Functions con la misma política de reintento y la misma DLQ de SQS estándar que usas para una carga de almacén: la conexión que hay detrás del 95% de precisión en el descubrimiento de datos sensibles y la reducción del 80% en el tiempo necesario para descubrir datos sensibles comunicados por Oportun. La habilidad de orquestación no cambia (coincidir en source / detail-type, acotar los reintentos, hacer idempotente la remediación); solo cambia el productor (material de cliente de AWS Macie y presentación de la sesión SEC215 de re:Invent, consultada en octubre de 2026).

---

6. EventBridge Pipes y EventBridge Scheduler

6.1 Pipes: origen → filtro → enriquecer → destino, sin código

Los Pipes son de punto a punto (no pub/sub): un origen, un filtro opcional (solo se facturan los eventos coincidentes), un paso de enriquecimiento opcional (Lambda o Step Functions) y un destino (documentación de AWS EventBridge Pipes, consultada en octubre de 2026).

6.2 Ejemplo resuelto E8: facturación de Pipes con un filtro

Un pipe consume 10.000.000 de mensajes de SQS, un filtro deja pasar el 25%, y el batching es de 5 mensajes por petición (ejemplo de la página de precios de Step Functions, en octubre de 2026):

$0.20 por diez millones de mensajes: porque el filtro se ejecuta antes de la facturación. El principio evaluable: filtra pronto, agrupa hasta el máximo del destino y recuerda el techo de 5 minutos del pipe.

6.3 Scheduler: schedules sin regla

AWS recomienda EventBridge Scheduler para invocar destinos según un schedule, y la consola etiqueta las reglas programadas como «(legacy)» (documentación de EventBridge Scheduler, consultada en octubre de 2026).

La ventana de tiempo flexible es la característica sobre la que giran las preguntas de examen: MaximumWindowInMinutes: 60 significa que un job nocturno programado a las 01:00 puede dispararse en cualquier momento entre las 01:00 y las 02:00: perfecto para ventanas de lote que deben absorber picos de carga, erróneo para un job que debe arrancar exactamente a las 01:00:00.

6.4 Cuatro cosas que «se ejecutan según un schedule» (no las mezcles)

---

7. Amazon MWAA: Apache Airflow gestionado

7.1 Qué es en realidad un entorno

Un entorno de Amazon MWAA es un manojo de componentes gestionados (documentación de AWS MWAA, consultada en octubre de 2026):

Renuncias a SSH, a imágenes personalizadas, a colas SQS propias y a la elección de executor, solo Celery, a cambio de que AWS ejecute el plano de control, Aurora, Fargate, el registro y tu cableado de VPC. Las actualizaciones de DAGs existentes se recogen en unos 30 segundos.

7.2 Clases de worker y autoescalado (en octubre de 2026)

Los workers se añaden según (RunningTasks + QueuedTasks) / tareas-por-worker, hasta max-workers. El valor por defecto de celery.worker_autoscale por clase (3 / 5 / 10 / 20 / 40 / 80) es el que manda, y celery.worker_concurrency se ignora: definirlo no hace nada.

7.3 Operators y dependencias

Los DAGs viven en S3, las dependencias en requirements.txt (pip3) y plugins.zip; un requirements.txt nuevo exige una actualización del entorno. Los operators que importan para este examen:

Versiones disponibles en octubre de 2026: Airflow 3.2.x (anunciado 2026-04-01), 3.0.x y 2.11.0 (publicado 2026-01-07, Python 3.12), más las líneas antiguas 2.9.x/2.7.x/2.4.x. Airflow 3 añade programación consciente de assets y particiones, historial de auditoría con humanos en el bucle y un PythonOperator asíncrono.

7.4 Ejemplo resuelto E9: precificar un entorno de MWAA

El propio ejemplo resuelto de AWS para un entorno mw1.small durante un mes de 31 días: 1 entorno, 49 workers funcionando 1 hora al día, 10 GB de almacenamiento de la base de metadatos (precios de MWAA, us-east-1, en octubre de 2026):

Para comparar, mw1.large cuesta $0.99/h para el entorno, con workers y schedulers extra a $0.22/h y un servidor web adicional a $0.11/h, y MWAA Serverless factura AWS Managed Tasks a $0.080 por hora de tarea (mínimo de 1 minuto, facturación por segundo). Otras cuotas: 10 entornos por región (5 de mw1.xlarge/mw1.2xlarge), 25 workers por entorno (50 tras aumentar la cuota), 5 webservers, 20 GB de almacenamiento por tarea.

• 📚 ¿Sabías que…? La cola de Celery de MWAA es una cola de Amazon SQS gestionada por AWS que no puedes crear, reemplazar ni configurar, y por eso las preguntas que ofrecen «trae tu propia cola SQS a MWAA» o «ajusta celery.worker_concurrency» son erróneas. Lo que sí ajustas es la clase de worker, y esa sola elección mueve a la vez la capacidad de DAGs y la concurrencia de tareas por defecto: mw1.small → mw1.medium cambia el valor por defecto de 5 a 10 tareas por worker (documentación de AWS MWAA, consultada en octubre de 2026).

7.5 MWAA Serverless

MWAA Serverless elimina el entorno siempre activo: DAGs en YAML más un paquete de código en S3, programación de pago por uso por tarea respaldada por EventBridge Scheduler, un rol de ejecución por workflow y cómputo aislado. Es la respuesta serverless dentro de la familia Airflow, pero los conceptos de Airflow, el archivo del DAG y los operators son los mismos. (Documentación de AWS MWAA Serverless, consultada en octubre de 2026; la disponibilidad por regiones no se repite aquí porque la lista de lanzamientos no pudo verificarse en octubre de 2026.)

---

8. AWS Glue Workflows y triggers

8.1 Una entidad, dos grafos

Un workflow de Glue rastrea jobs + crawlers + triggers como una única entidad con una vista de grafo: un grafo estático (diseño) y un grafo dinámico (estado en tiempo de ejecución por nodo) (AWS Glue, Workflows y Triggers, consultado en octubre de 2026).

8.2 Los tres triggers de inicio

Dentro del grafo, los triggers condicionales expresan dependencias: el job J3 empieza después de J1 Y J2 SUCCEEDED; el job J4 empieza después de J1 O J2 FAILED; un crawler empieza tras terminar los jobs. Las propiedades de ejecución del workflow son pares nombre/valor compartidos que los jobs leen y modifican durante la ejecución: paso de estado sin XCom de Airflow.

8.3 La regla dura

Todos los jobs o crawlers de una cadena de dependencia deben ser descendientes de un único trigger programado o on-demand. Los dependientes solo se disparan si un trigger los inició: un crawler que inicies a mano no disparará el siguiente job del grafo. Cada trigger admite ≤ 50 jobs y ≤ 2 crawlers, y un workflow de Glue es un target de EventBridge de primera clase, así que una regla de EventBridge o un schedule de Scheduler puede arrancar el grafo entero.

8.4 Elegir entre Glue Workflows y Step Functions para el mismo ETL

---

9. La matriz de selección de orquestación

9.1 El diagrama del dinero

9.2 La matriz en palabras

---

10. Patrones de reintento, DLQ, idempotencia y backfill

10.1 La escalera de fiabilidad

10.2 Idempotencia: la precondición de toda reproducción

La entrega es al menos una vez casi en todas partes (ejecuciones Express, targets de EventBridge, SQS, Pipes), así que reproducir solo es seguro si el procesamiento es idempotente:

• Escritura condicional en DynamoDB: ConditionExpression: attribute_not_exists(pk) falla con DynamoDB.ConditionalCheckFailedException, que un Catch puede absorber; las ramas paralelas que compiten por un lock usan exactamente este truco.
• Lambda Powertools @idempotent con TTL: la segunda invocación del mismo evento devuelve el resultado cacheado.
• Cabecera Idempotency-Key aguas arriba para pipelines dirigidos por API.
• Job bookmarks de Glue: el equivalente del lado de la transformación: el estado rastreado entre job.init y job.commit evita el reprocesamiento (lección 03).

10.3 Redrive, reintento y replay son tres cosas distintas

Step Functions además emite eventos de cambio de estado de ejecución al bus predeterminado de EventBridge, de modo que una regla puede vigilar ExecutionFailed e invocar un Lambda que llame a RedriveExecution: la orquestación que se cura a sí misma.

10.4 Ejemplo resuelto E10: diseñar la ruta de recuperación

10.5 Patrones de backfill

Actualizaciones de 2026 (en octubre de 2026)

• 📚 ¿Sabías que…? La redacción de exactamente una vez / al menos una vez ha sido estable desde que Express se lanzó el 2019-12-05, mientras que todo lo que rodea a eso cambió: la cobertura de integraciones se duplicó hasta 220+ servicios, Distributed Map añadió fuentes de S3 y Athena, y MWAA pasó por Airflow 2.4 → 2.11 → 3.0 → 3.2. Para el examen esto significa que la tabla de garantías de la sección 2 es material viejo y duradero, mientras que los nombres de integraciones y los números de versión son la parte que debes revisar en cada ciclo de estudio (anuncio de AWS Step Functions, 2019-12-05; recent launches de Step Functions, consultado en octubre de 2026).

---

Casos Reales

AWS publica cómo se ven estas abstracciones en producción. Cada cifra siguiente está afirmada por el cliente o por AWS y no auditada, con la fuente indicada para que puedas verificarla: el punto evaluable es el patrón (qué problema de orquestación se resolvió, qué servicio hizo el trabajo, qué cifra se movió), no el marketing.

Caso A, Edmunds.com: un job de lote serverless en fan-out (700 millones de derivativos en 8 días)

Léelo como la forma de orquestación que hay detrás del fan-out: un director enumera los elementos de trabajo (la lista de objetos de S3), cada unidad corre como una invocación independiente, idempotente y corta, y el agregado completa sin clúster. Es la misma forma que un Distributed Map con ItemReader sobre un prefijo de S3 o un EventBridge Pipe desde un stream hacia Lambda: la idea evaluable es elementos independientes + concurrencia acotada + una condición de terminación definida.

Caso B, EOS Group: un pipeline de migración por etapas sin pérdida de datos

El punto evaluable es la disciplina de etapas: la carga completa, el CDC, la validación y la carga son pasos separados, ordenados y reintentables con una compuerta de validación entre ellos: la misma topología que construiste en la sección 3 (Task → Choice → Task → Fail), solo que implementada con herramientas de migración. «Cero pérdida de datos» es lo que compra un estado Choice sobre un contrato de recuento de filas y un destino idempotente; «tiempo de inactividad mínimo» es lo que compra ejecutar las etapas como un grafo reintentable en lugar de un script monolítico.

Caso C, Nasdaq: un lote nocturno con fecha límite en todo un lake house

Léelo como un problema de fecha límite, no de herramientas: como la ruta de escritura (S3) y la ruta de lectura (Redshift/Spectrum) están desacopladas, cargar y consultar nunca compiten por la misma capacidad, de modo que el orquestador puede reiniciar una etapa fallida sin detener a los analistas, y una ejecución tardía degrada una etapa en lugar de la noche entera. Es el mismo razonamiento que hace que un grafo reintentable con una compuerta de validación (caso B, sección 3) sea la respuesta por defecto cuando una pregunta describe un lote que simplemente no puede llegar tarde.

Caso D, AGCO: un pipeline de streaming que opera una sola persona

Aquí el disparador es el stream, no un cron: un pipeline en ejecución continua se orquesta mediante contra presión y buffero en lugar de mediante un schedule, así que la lista de comprobación de resiliencia de la sección 1.2 se traslada a los consumidores: reintentos con backoff en el paso de enriquecimiento con Lambda, una zona de aterrizaje duradera (S3) para que un fallo aguas abajo reprocese desde el buffer, y alarmas de CloudWatch en lugar de una persona mirando un panel. «Una persona en lugar de tres a cinco» es el dividendo operativo del que el examen pregunta realmente cuando evalúa la habilidad 1.3.2.

• 📚 ¿Sabías que…? El salto publicado por Nasdaq de 30.000 millones a 70.000 millones de registros al día equivale a unos 810.000 registros por segundo sostenidos (70.000.000.000 ÷ 86.400 s, aritmética derivada, no una cifra publicada por AWS) con un freno duro en la apertura del mercado, mientras que el pipeline de streaming equivalente de AGCO lo opera un ingeniero en lugar de tres a cinco. Puestos uno al lado del otro hacen la distinción real del examen: a un orquestador de lote se le juzga por si termina antes de su fecha límite, y a un pipeline de streaming por si una sola persona puede mantenerlo sano, las dos mismas preguntas, formuladas a dos modos de fallo distintos (caso de estudio de AWS Nasdaq; AWS Architecture Monthly, diciembre de 2021, consultado en octubre de 2026).

• 📚 ¿Sabías que…? Ningún caso de estudio de AWS nombra siquiera a un orquestador: AWS publica los resultados y te deja la conexión a ti. Eso es diseño de examen deliberado: el DEA-C01 nunca te pide recordar la elección de herramientas de un cliente, te pide reconocer que 700 millones de elementos independientes implica fan-out con una concurrencia acotada (Distributed Map o Lambda), y que cero pérdida de datos a través de un corte implica etapas ordenadas con validación y escrituras idempotentes (casos de estudio de AWS, consultados en octubre de 2026).

---

Preguntas de Práctica (Practice Questions)