Orquestar el lakehouse: Step Functions, EventBridge y MWAA

A diez lecciones, ya puedes aterrizar archivos, convertirlos, curarlos en Iceberg, consultarlos con Athena y entregar el resultado a Redshift. Nada de eso responde a las cuatro preguntas que deciden si el lakehouse es un producto o una responsabilidad: qué inicia la ejecución, en qué orden corren los pasos, qué pasa cuando un paso falla, y cómo lo vuelves a ejecutar sin escribir las mismas filas dos veces. Eso es orquestación, y es la capa donde viven realmente la mayoría de los incidentes de lakehouse: no en el SQL.

La regla didáctica de esta lección es corta: el orquestador es dueño del tiempo, el orden, el fallo y la reproducción; el cómputo es dueño de los bytes. Mantén separados esos dos trabajos y cada decisión de diseño posterior se vuelve más fácil.

En esta lección:

• separarás Standard y Express por la garantía de entrega, el techo de duración, la velocidad, los patrones soportados y el coste por transición de estado;
• leerás y escribirás Amazon States Language: los ocho tipos de estado, los tres patrones de integración, y los recursos de Task para Glue, EMR, Lambda y el AWS SDK;
• elegirás entre Map en línea y Distributed Map, y dimensionarás ItemReader, ItemBatcher y ResultWriter;
• usarás Parallel, Retry, Catch, TimeoutSeconds y máquinas de estados anidadas para aislar fases y enrutar fallos;
• conectarás buses de Amazon EventBridge, patrones de eventos, horarios, Pipes con filtrado y enriquecimiento, API Destinations y Archive/Replay;
• dimensionarás un entorno de Amazon MWAA y reconocerás los patrones de DAG de Airflow que lo justifican;
• encadenarás AWS Glue Workflows y triggers, incluidos los triggers EVENT iniciados desde EventBridge;
• harás seguras las reejecuciones con nombres de ejecución deterministas, dedup, checkpoints y traspaso de watermarks;
• ejecutarás un backfill sobre particiones por fecha con un Distributed Map;
• aplicarás una matriz de decisión de planificadores y roles de ejecución de mínimo privilegio;
• trabajarás una máquina de estados de bronce a plata a oro con enrutado de cuarentena, diez ejemplos resueltos, un cuadro de actualizaciones de octubre de 2026 con fuentes, material de caso de Transport for NSW, tres comprobaciones interactivas y catorce preguntas de estilo examen.

---

1. La superficie de orquestación: cinco herramientas, cinco trabajos

1.1 Las cinco primitivas

Toda pregunta de orquestación se reduce a las mismas cinco primitivas. Cada una es dueña de una cosa distinta, y todo olor a diseño en este espacio es una primitiva usada para un trabajo del que no es dueña.

Las cuatro preguntas que siempre debes responder antes de elegir: ¿Qué inicia la ejecución? (horario, 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, cuarentena, alerta) ¿Cómo lo vuelves a ejecutar sin corromper los datos? (nombre idempotente, checkpoint, watermark, redrive).

• 📚 ¿Sabías que…? Step Functions puede llegar a «más de 14.000 acciones de API de más de 220 servicios de AWS» según el AWS Compute Blog de 2025-11-04: una publicación anterior de AWS What's New de 2022-12-01 cifraba la misma cifra en «más de 200 servicios de AWS». La cifra es un objetivo móvil, pero el hecho examinable es que la integración del AWS SDK es la válvula de escape para todo aquello sin una integración optimizada (AWS Compute Blog, 2025-11-04; AWS What's New, 2022-12-01).

---

2. AWS Step Functions: Standard frente a Express

2.1 Dos tipos de workflow, y ninguno tercero

Hay exactamente dos tipos de máquina de estados: Standard (el por defecto) y Express. El tipo es inmutable: se elige en la creación y nunca cambia después. La palabra «sync» nombra dos cosas distintas y es la confusión más común de todo el servicio:

1. el patrón de integración .sync («Ejecutar un trabajo»), donde un workflow Standard llama a un servicio y se bloquea hasta que el trabajo termina; y
2. Express síncrono (StartSyncExecution), donde una ejecución Express se invoca de forma síncrona desde API Gateway, Lambda o la CLI y devuelve el resultado.

AWS enuncia la regla sin rodeos: los workflows Standard «siguen un modelo exactamente una vez… adecuado para orquestar acciones no idempotentes, como iniciar un clúster de Amazon EMR o procesar pagos», mientras que los workflows Express «usan un modelo de al menos una vez… mejor adecuado para orquestar acciones idempotentes» (Guía de desarrollador de Step Functions, consultada 2026-10-11).

2.2 Ejemplo resuelto E1: un pipeline diario de nueve transiciones

La aritmética del propio ejemplo de precios de AWS, reproducida con las tarifas publicadas (us-east-1, consultado 2026-10-11):

El nivel gratuito es de 4.000 transiciones de estado al mes, indefinidamente. En esa cifra se esconden dos lecciones: un pipeline diario casi nunca genera una factura de Step Functions que merezca la pena considerar, y uno de alta frecuencia sí.

2.3 Ejemplo resuelto E2: el mismo pipeline, dos medidores

Catorce estados, 30.000 ejecuciones al mes, sin reintentos (derivado de las tarifas publicadas, en oct 2026):

Express factura la duración redondeada hacia arriba al 100 ms más cercano, en fragmentos de 64 MB, y la huella de memoria se calcula como 50 MB + tamaño de la definición de la máquina de estados + tamaño de los datos de ejecución x número de pasos Parallel o Map. Los tres niveles de duración que AWS imprime en su propio Ejemplo 4 son $0.0600 por GB-hora para los primeros 1.000 GB-horas, $0.0300 para los siguientes 4.000, y $0.01642 a partir de ahí (precios de Step Functions, consultados 2026-10-11).

---

3. Amazon States Language y la capa de Task

3.1 Los ocho tipos de estado

Amazon States Language (ASL) es un documento basado en JSON. Los tipos de estado que lista AWS son Task, Choice, Wait, Pass, Succeed, Fail, Parallel y Map: ocho en total, y toda una máquina de estados es estos estados conectados con los campos Next y End (Guía de desarrollador de Step Functions, consultada 2026-10-11).

• Task hace trabajo (llama a Lambda, inicia un trabajo de Glue, pone un elemento en DynamoDB).
• Choice ramifica según la entrada; Wait duerme; Pass remodela datos.
• Succeed y Fail terminan la ejecución deliberadamente.
• Parallel hace fan-out sobre ramas escritas en la definición.
• Map hace fan-out sobre un conjunto de datos: en línea o Distributed (sección 4).

Tres cuotas acotan la propia definición: el tamaño máximo de definición de la máquina de estados es de 1 MB (duro), el tamaño máximo de entrada o salida de una tarea, estado o ejecución es de 256 KiB de datos codificados en UTF-8, y el tamaño máximo del historial de ejecución es de 25.000 eventos para un workflow Standard.

3.2 Tres patrones de integración, y qué servicios reciben cuál

Cada integración optimizada puede invocarse de una de tres formas:

La matriz de integraciones optimizadas de AWS separa limpiamente los servicios de lakehouse:

• .sync soportado: athena, batch, emr, emr-serverless, glue, glue:databrew, sagemaker, states (el propio Step Functions anidado).
• Request Response más callback (.waitForTaskToken), sin .sync: lambda, sns, sqs, dynamodb, EventBridge.
• Integración del AWS SDK: Request Response en todos los servicios soportados; .waitForTaskToken solo en Standard; nunca .sync.

Así que los recursos de Task concretos que realmente escribirás en una máquina de estados de lakehouse son:

• 📚 ¿Sabías que…? startExecution.sync y startExecution.sync:2 no son intercambiables: .sync devuelve la salida del hijo como cadena, .sync:2 la devuelve como JSON. Analizar el incorrecto corrompe silenciosamente cada referencia Payload.$ aguas abajo, y el fallo aparece mucho después como un campo ausente en lugar de un error de despliegue (Guía de desarrollador de Step Functions, consultada 2026-10-11).

3.3 Ejemplo resuelto E3: el presupuesto de reintentos que olvidaste precificar

Los reintentos no son gratis: «los reintentos se tratan como transiciones de estado», y «si incluyes manejo de errores por reintento en cualquier paso de tu workflow, cada reintento se cobrará como una transición de estado adicional» (precios de Step Functions, consultados 2026-10-11).

MaxAttempts: 0 significa nunca reintentar: una elección válida y deliberada para un paso que falla de forma permanente y debe enrutarse directamente a un Catch.

3.4 Retry, Catch, Timeout y Heartbeat: los valores por defecto exactos

Nombres de error integrados que no debes confundir:

• States.ALL: debe aparecer solo en un Catcher y no puede capturar States.DataLimitExceeded ni States.Runtime.
• States.TaskFailed: un comodín para cualquier error conocido excepto States.Timeout.
• States.Timeout, States.HeartbeatTimeout, States.Permissions, States.ItemReaderFailed, States.ResultWriterFailed, States.ExceedToleratedFailureThreshold.
• States.DataLimitExceeded es terminal: una tarea que emite un payload de más de 256 KiB muere y ningún catcher adjunto a ese estado puede salvarla.

Tres reglas estructurales que atrapan a ingenieros con experiencia:

1. Los catchers existen solo en Task, Parallel y Map: «no para fallos de ejecución de la máquina de estados de primer nivel». Un fallo de ejecución completa debe manejarlo el llamante, un workflow anidado, o una regla de EventBridge sobre el estado de la ejecución (FAILED / TIMED_OUT).
2. Si una máquina de estados anidada lanza un States.Timeout, el padre recibe States.TaskFailed en su lugar.
3. En los runtimes más nuevos de Lambda, los timeouts aparecen como Sandbox.Timedout: casa con Lambda.Unknown, Sandbox.Timedout y States.TaskFailed a la vez.

3.5 Activities: el carril de devolución que espera hasta un año

Las Activities son una construcción solo de Standard: un worker de actividad sondea con GetActivityTask, mantiene la tarea viva enviando un latido con SendTaskHeartbeat dentro del TimeoutSeconds configurado, y responde con SendTaskSuccess o SendTaskFailure. Con latidos, «una actividad en Step Functions puede esperar hasta un año a que se complete una ejecución». Una vez que la tarea supera el timeout, Step Functions invalida el token de tarea y las llamadas posteriores lanzan TaskTimedOut.

3.6 Workflows anidados: fases con su propio historial y sus propios reintentos

Cuatro recursos controlan el anidamiento: states:startExecution (dispara y olvida), .sync (espera, salida string), .sync:2 (espera, salida JSON), .waitForTaskToken (devolución). El anidamiento compra aislamiento de historial por fase, reintentos por fase y reutilización, pero el padre debe poder enterarse de que el hijo terminó, y esa detección tiene dos rutas con dos conjuntos de permisos distintos:

• sondeo: necesita states:DescribeExecution;
• eventos de EventBridge: necesita events:PutTargets, events:PutRule y events:DescribeRule.

Omite el segundo conjunto y el padre se cuelga en lugar de fallar de forma ruidosa, que es el síntoma clásico.

3.7 Ejemplo resuelto F1: rellenar un fragmento real de ASL

---

4. Map, Distributed Map, Parallel e ItemBatcher

4.1 Cuándo el Map en línea deja de bastar

Parallel itera sobre ramas fijadas en la definición; Map itera sobre un conjunto de datos. El Map en línea (por defecto) ejecuta sus iteraciones dentro del historial de ejecución del padre, y eso crea tres techos duros:

Las propias condiciones que AWS enuncia para cambiar: usa el modo Distributed cuando «el tamaño de tu conjunto de datos supere los 256 KiB», «el historial de eventos de ejecución del workflow superaría las 25.000 entradas», o «necesites una concurrencia de más de 40 iteraciones concurrentes» (Guía de desarrollador de Step Functions, consultada 2026-10-11).

Detalles del Distributed Map que vale la pena memorizar:

• Fuentes de ItemReader: objetos de S3 (CSV, JSON, JSONL, Parquet), o un manifiesto de datos de Athena: el Compute Blog de 2025-11-04 confirma que Distributed Map puede «procesar manifiestos de datos de AWS Athena y archivos Parquet directamente, eliminando la necesidad de preprocesamiento personalizado».
• ExecutionType en los hijos: STANDARD o EXPRESS: usa hijos EXPRESS para unidades de fan-out cortas e idempotentes.
• MaxConcurrency / MaxConcurrencyPath: si no se fija o es cero, Step Functions «no limita la concurrencia y ejecuta 10.000 ejecuciones de workflows hijas paralelas», y AWS recomienda no superar la capacidad de un servicio aguas abajo como Lambda.
• ToleratedFailureCount / ToleratedFailurePercentage y sus variantes ...Path: el porcentaje por defecto es cero, lo que significa que «el workflow falla si cualquiera de sus ejecuciones de workflows hijas falla o supera el timeout». Superar el umbral lanza States.ExceedToleratedFailureThreshold, que necesita su propio Catch.
• Cuotas: 1.000 Map Runs abiertos por cuenta/Región, 1.000 redrives por Map Run, 10.000 ejecuciones hijas paralelas por Map Run (duro), y Step Functions despacha hijos express a hasta 1.000 TPS e hijos standard a hasta 100 TPS.

4.2 ItemBatcher: la palanca más barata que tienes

ItemBatcher agrupa elementos para que cada hija reciba {"Items": [...]} más un BatchInput estático opcional. Dos pares de mandos: MaxItemsPerBatch / MaxItemsPerBatchPath, y MaxInputBytesPerBatch / MaxInputBytesPerBatchPath: el techo de bytes es de 256 KiB, el propio límite de payload de Step Functions.

La cifra resuelta del propio AWS: «imagina que ejecutas una ejecución con un archivo de entrada JSON que contiene 1130 nodos. Si especificas un valor máximo de elementos de 100 para cada lote, Step Functions crea 12 lotes» (Guía de desarrollador de Step Functions, consultada 2026-10-11). Usa el agrupamiento «al procesar archivos CSV grandes o matrices JSON, o conjuntos grandes de objetos de Amazon S3.»

4.3 Ejemplo resuelto E4: aritmética de agrupamiento y su efecto en la factura

• 📚 ¿Sabías que…? Las métricas de observabilidad de Distributed Map anunciadas el 2025-09-18, ApproximateOpenMapRunsCount, OpenMapRunLimit y ApproximateMapRunsBacklogSize, existen porque la profundidad del fan-out es invisible hasta que chocas con la cuota de 1.000 Map Runs abiertos. Alarma sobre la métrica de backlog antes del límite, no después (AWS What's New, 2025-09-18; AWS Compute Blog, 2025-11-04).

4.4 Proyectos de ejemplo que vale la pena leer antes de construir uno

Dos proyectos de ejemplo de AWS son buenos elementos didácticos: un pipeline de datos meteorológicos donde «los datos meteorológicos se registran en más de 12.000 archivos CSV» con MaxConcurrency fijado en 3.000, que copia, luego analiza y luego reduce en DynamoDB; y un pipeline de pedidos de envío en CSV de «10.000 filas de un archivo CSV» procesadas en lotes de 10 con MaxConcurrency 1.000, con resultados escritos en S3 a través de ResultWriter (proyectos de ejemplo de Step Functions, consultados 2026-10-11).

---

5. Una máquina de estados de lakehouse resuelta: de bronce a plata a oro

Esta es la forma que deberías poder dibujar de memoria. Un padre Standard aloja un Distributed Map (Express no podría), las hijas corren como ejecuciones EXPRESS con MaxConcurrency: 100 para que la concurrencia de trabajos a nivel de cuenta de Glue nunca quede ahogada, y el fallo parcial se enruta a la cuarentena en lugar de fallar en silencio.

Notas didácticas, todas sostienen la estructura:

1. SilverMap debe ser Distributed: el tope de 40 iteraciones de un Map en línea y su historial compartido de 25.000 eventos matarán una ejecución de miles de particiones.
2. ItemBatcher.MaxItemsPerBatch: 20 convierte miles de archivos en decenas de hijas. Las hijas son la unidad tanto del paralelismo como de la facturación.
3. Retry en el Map crea un nuevo Map Run: limita MaxAttempts y usa redrive (ventana de 14 días, solo Standard) para reproducciones del Map completo.
4. Catch sobre States.ExceedToleratedFailureThreshold enruta el fallo parcial a la cuarentena. Sin él, un incumplimiento del umbral es un fallo de ejecución sin manejar.
5. El watermark se escribe al final. Registra s3://lake/_checkpoints/silver/dt=2026-10-11.json solo después de que PublishCatalog tenga éxito: eso es lo que hace idempotente el re-disparo del mismo día.
6. La cuarentena es un destino, no un estado. Aterriza las claves de la partición que falla en algún sitio donde un humano o un sistema de tickets puedan verlas.
7. ValidateInput es un estado Choice, y la rama FailFast termina en un estado Fail: una salida temprana y barata gana a descubrir un rango de fechas defectuoso tres horas después de un fan-out.

5.1 Ejemplo resuelto E5: precificar esta máquina exacta

Esa es la lección de coste más importante de esta lección: Step Functions es un error de redondeo al lado del cómputo que planifica. Optimiza para el enrutado de fallos y la seguridad de reproducción, y no para el recuento de transiciones: con la única excepción de las políticas de reintento sin límite (sección 3.3).

---

6. Amazon EventBridge para el lakehouse

6.1 Buses, reglas, cuotas

AWS le da a cada cuenta un bus de eventos predeterminado que recibe los eventos de cambio de estado de los servicios de AWS (la ingesta de eventos de gestión es gratis; los eventos de datos opcionales como los de S3 deben habilitarse). La página de precios describe cuatro tipos de bus de eventos: el bus predeterminado; dos buses propios, Custom event bus: Classic (julio de 2019) y un Custom event bus mejorado lanzado en septiembre de 2026, y un bus de eventos de socios para eventos de proveedores SaaS (precios de Amazon EventBridge, consultados 2026-10-11).

6.2 Patrones de eventos

Los patrones casan con source, detail-type, account, region y detail, con el conjunto de operadores And, anything-but (incluidas las formas prefix, suffix, ignore-case y wildcard), prefix, suffix, empty, equals-ignore-case, exists, null, rangos numeric, $or, wildcard y cidr. Dos filos afilados: «Actualmente el carácter comodín está soportado solo en reglas de bus de eventos», y cualquier patrón donde $or se expanda a más de 1.000 combinaciones de reglas hace que PutRule, CreateArchive, UpdateArchive y TestEventPattern lanzen InvalidEventPatternException (Guía de usuario de EventBridge, consultada 2026-10-11).

6.3 Horarios: reglas heredadas frente a EventBridge Scheduler

Las reglas programadas son explícitamente «una función heredada de EventBridge» y AWS «recomienda que uses Scheduler para invocar destinos en un horario». El cron heredado tiene seis campos obligatorios (minutos, horas, día del mes, mes, día de la semana, año) y «no se admiten expresiones cron que lleven a tasas más rápidas que 1 minuto»; todo se ejecuta en UTC.

EventBridge Scheduler es la respuesta actual: tres tipos de horario, basados en rate, basados en cron y puntuales, con «precisión de 60 segundos», manejo automático del horario de verano (en un hueco de adelanto la invocación se omite), ventanas de tiempo flexibles de 1 a 1.440 minutos, políticas de reintento y antigüedad de eventos, y destinos con plantilla en cientos de servicios de AWS. Cuotas: 10.000.000 de horarios por Región, CreateSchedule a 5.000 TPS, invocaciones a 1.000 TPS.

Precios: $1.00 por millón de invocaciones tras 14.000.000 de invocaciones gratis al mes (precios de EventBridge, consultados 2026-10-11).

6.4 Pipes: del origen al filtro, al enriquecimiento y al destino

Una tubería es «elige el origen, añade filtrado opcional, define enriquecimiento opcional y elige el destino»: con el orden preservado cuando el origen lo impone, agrupamiento, informe de fallos parciales, y su propio rol IAM bajo pipes.amazonaws.com.

• Orígenes: DynamoDB Streams, streams de Kinesis, Amazon MQ, MSK, SQS y Apache Kafka (autoalojado, Confluent Cloud, CloudKarafka, Redpanda). No trates ninguna lista publicada como exhaustiva: la página de documentación de AWS es la autoridad.
• Destinos: destino de API, API Gateway, cola de trabajos de Batch, grupo de logs de CloudWatch, tarea de ECS, bus de eventos de la misma cuenta y Región, stream de entrega de Firehose, stream de Kinesis, Lambda (SYNC o ASYNC), consultas de la API de datos de Redshift, pipelines de SageMaker AI, topic de SNS (FIFO no soportado), cola de SQS, Step Functions (Express SYNC o ASYNC; Standard debe ser ASYNC), Timestream.
• Techos de payload: los Pipes admiten 6 MB, pero el destino te acota: un destino de bus de eventos es de 1 MB y un destino de máquina de estados de Step Functions de 256 KB. Una salida de enriquecimiento por encima del límite del destino hace fallar la invocación.
• Los tamaños de lote son el mínimo entre origen y destino: Kinesis admite lotes de 10.000 registros, los destinos de SQS solo 10, Firehose y Kinesis 500, CloudWatch Logs 10.000, bus de eventos 10, SNS 10: así que el pipe toma el número menor.
• Techo de ejecución de un pipe: 5 minutos incluyendo enriquecimiento y procesamiento del destino: «Este límite actualmente no puede aumentarse.»
• Valores por defecto de concurrencia: SQS 1.250; Kafka hasta el recuento de particiones (máx. 1.000); Amazon MQ 5; Kinesis y DynamoDB = ParallelizationFactor multiplicado por el número de shards.
• Fallo parcial de lote usa la forma de payload {"batchItemFailures": [{"itemIdentifier": "id2"}]}.
• Facturación: «solo se te cobra por aquellos eventos que coinciden con el filtro»: $0.40 por millón de peticiones, medido en fragmentos de 64 KB, después del filtro.

6.5 API Destinations, Archive y Replay

API Destinations permiten que una regla llame a un endpoint HTTP externo a través de una conexión gestionada por AWS: $0.20 por millón de eventos, con 3.000 destinos y 3.000 conexiones por cuenta/Región y 300 invocaciones por segundo por destino.

Archive y Replay es la caja negra de eventos del lago. «Por defecto, EventBridge almacena eventos en el archivo indefinidamente»; «Reproducir eventos no los elimina del archivo… EventBridge solo elimina eventos cuando superan el periodo de retención del archivo, o cuando tú eliminas el archivo en sí»; las reproducciones se eliminan después de 90 días; puede haber como máximo 10 reproducciones concurrentes activas por cuenta por Región; y «solo puedes reproducir eventos hacia el mismo bus de eventos que emitió los eventos.»

6.6 La ruta de eventos del lakehouse: de S3 directo a EventBridge

Una vez habilitado EventBridge, S3 entrega cada evento a nivel de objeto sin configuración por tipo: una regla filtra source: aws.s3, detail-type: Object Created, el nombre del bucket, un prefix de bronze/orders/ y un suffix de _SUCCESS, y apunta a una máquina de estados, un Pipe, una función Lambda o una cola de SQS. Esto sustituye a las notificaciones de eventos de S3 por tipo más un fan-out con Lambda cuando necesitas muchos consumidores, filtrado por contenido, archivos y enrutado entre cuentas.

6.7 Ejemplo resuelto E6: la factura del lago dirigido por eventos

• 📚 ¿Sabías que…? S3 no te hace enumerar tipos de evento. Una vez habilitado EventBridge en la cuenta, «no necesitas seleccionar qué tipos de evento quieres entregar»: fluyen todos, incluidos Object Created, Object Deleted, Restore Initiated / Completed / Expired, Storage Class Changed, Object Tags Added/Deleted, Retention Updated y Annotation Created/Removed. El filtrado pertenece a la regla, no a una configuración de notificación por tipo (Guía de usuario de Amazon S3, consultada 2026-10-11).

---

7. Orquestación idempotente: sobrevivir a la segunda ejecución

7.1 Cuatro mecanismos, en el orden en que los construyes

Los nombres son únicos por cuenta y Región, con un tope de 80 caracteres, y el historial de ejecuciones se retiene 90 días (reducible a 30 mediante solicitud de cuota). Un patrón diario práctico:

7.2 Checkpoints y traspaso de watermarks

Step Functions no rastrea watermarks de datos; esto es un patrón de ingeniería construido sobre primitivas verificadas, no una función gestionada. Persiste el watermark después del commit, en uno de estos soportes: un elemento de DynamoDB, un objeto marcador de S3 como _checkpoints/silver/dt=2026-10-11.json, un id de instantánea de Iceberg, o un job bookmark de Glue. El lector debe entonces tomar su límite inicial de ese watermark, lo que convierte la relectura de una ventana cerrada en una operación nula en lugar de una escritura duplicada.

Tres reglas baratas de determinismo completan el panorama: deriva las claves de objetos y los identificadores de contexto de (capa, fecha_partición, fuente); mantén cada campo Payload aguas abajo referenciado mediante rutas .$ en lugar de asumido; y haz que el marcador de éxito sea lo único sobre lo que filtra una regla aguas abajo, de modo que una escritura parcial nunca pueda pasar por completada.

7.3 Ejemplo resuelto E7: diseñar la reejecución segura

7.4 Ordenar el pipeline idempotente

---

8. Backfill con un Distributed Map sobre particiones por fecha

El backfill es donde el Distributed Map deja de ser una curiosidad y se convierte en la herramienta más barata que posees: una ejecución padre, cientos de hijas por partición de fecha, concurrencia acotada a lo que Glue puede absorber de verdad.

8.1 Ejemplo resuelto E8: un backfill de 90 días

Tres reglas para backfills de producción:

1. Acota MaxConcurrency al servicio aguas abajo. La propia guía de AWS: «recomendamos que no superes la capacidad de un servicio de AWS aguas abajo, como AWS Lambda», y 10.000 hijas a la vez chocarán al instante con la cuota de trabajos de la cuenta de Glue.
2. Fija ToleratedFailurePercentage deliberadamente. El por defecto es cero, así que una sola partición corrupta hace fallar el Map Run completo.
3. Prefiere redrive a Retry en un Map. Reintentar un estado Map «crea un nuevo Map Run»; redrive reutiliza el existente dentro de la ventana de 14 días.

• 📚 ¿Sabías que…? Un backfill también es la forma más barata de probar tu diseño de idempotencia: reejecuta una ventana que ya está comprometida y observa si el escritor converge o agrega. Si la segunda ejecución cambia los recuentos de filas, tu traspaso de watermarks está roto antes de que un incidente lo encuentre por ti.

---

9. Amazon MWAA: Airflow gestionado para el lakehouse

9.1 Qué es en realidad un entorno

Amazon MWAA ejecuta Apache Airflow sobre AWS Fargate, workers, planificadores y un servidor web, respaldado por una base de datos de metadatos Aurora PostgreSQL de inquilino único en tu propia VPC, con los DAG y los plugins almacenados en un bucket de S3. Los tamaños van de mw1.micro, mw1.small, mw1.medium, mw1.large, mw1.xlarge y mw1.2xlarge. Auto escalado: workers 10 por defecto / 1 mínimo / 25 máximo, reduciendo al mínimo cuando las tareas en cola más las en ejecución permanecen en cero durante más de dos minutos; planificadores 2 por defecto / 2 mínimo / 5 máximo.

El consejo de dimensionamiento de AWS es directo: «Recomendamos elegir el tamaño más pequeño necesario para dar soporte a tu carga de trabajo.»

Almacenamiento de la base de datos de metadatos: $0.10 por GB-mes. Todas las tarifas de US East (N. Virginia) del archivo de oferta de AWS Price List publicado el 2026-09-11, consultado 2026-10-11. mw1.xlarge da 8 vCPU / 24 GB para planificador y worker con un por defecto de 40 tareas y hasta 2.000 DAG; mw1.2xlarge da 16 vCPU / 48 GB, 80 tareas, 4.000 DAG; un cambio de tamaño de entorno tarda 20 a 30 minutos en completarse.

Pagas «por el tiempo que se ejecuta tu Entorno de Airflow más cualquier auto escalado adicional», facturado con resolución de un segundo: que es la razón por la que la tarifa del entorno, no la del worker, domina la factura.

9.2 Higiene de versiones

En octubre de 2026 MWAA ofrece Airflow 3.3.1 (disponible 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) y 3.0.6 (2025-10-01). Con efecto desde el 30 de diciembre de 2025, Amazon MWAA puso fin al soporte de las versiones de Apache Airflow v2.4.3, v2.5.1 y v2.6.3. AWS se compromete a soportar al menos tres versiones menores en cualquier momento, al menos 12 meses por versión, con 180 días de anuncio de fin de soporte.

Dos restricciones que muerden: MWAA admite actualizaciones menores in situ, «pero no a una nueva versión mayor», así que de Airflow 2 a 3 es una migración, no una actualización, y a partir de Airflow v2.7.2 tu archivo de requisitos debe incluir una instrucción --constraint. AWS también documenta que «Amazon MWAA no admite actualmente el modo de múltiples equipos.»

9.3 Qué patrones de DAG de lakehouse justifica MWAA

Airflow gana su coste de siempre activo en exactamente cuatro situaciones:

1. Reanudación por checkpoint sobre ventanas largas. El propio blog de MWAA frente a Step Functions de AWS de 2026-06-10 encuadra MWAA en torno a «reanudar desde el último checkpoint exitoso» para «procesos de larga duración que se extienden de 2 a 12 horas» sobre «5-10 TB de datos de transacciones financieras al diario», frente al «lógica de reintentos integrada con backoff exponencial» y la «ejecución paralela» de Step Functions.
2. DAG legibles entre equipos con semántica catchup, sensores y una UI para backfills.
3. Backfills estacionales o parametrizados donde un analista elige un rango de fechas y espera una vista de progreso.
4. Tipos de tarea heterogéneos, ECS, Bash, Python, APIs externas, bajo un mismo grafo de dependencias.

9.4 Ejemplo resuelto E9: MWAA frente a Step Functions al mes

El propio ejemplo de entorno grande de AWS aterriza en $1.047,46 al mes, de los cuales el entorno ($736,56) más los planificadores ($163,68) es aproximadamente 86% de coste fijo: que es exactamente el hueco que aborda MWAA Serverless. Un pipeline de una vez al día en un entorno medium cuesta 744 x $0.74 = $550,56 al mes antes de que corra un solo worker.

• 📚 ¿Sabías que…? MWAA Serverless (GA 2025-11-17, disponible en 15 regiones de AWS en el lanzamiento) es una opción de despliegue separada, no un nivel de tamaño: los workflows se definen en YAML (un DAG de Python convertido a YAML), se inician con start-workflow-run, se acotan con IAM por workflow, y se factura «por tarea según su duración, con un mínimo de 1 minuto» a $0.08 por hora para la tarea gestionada por AWS: con «escalado automático según la demanda del workflow» y sin ningún entorno que dimensionar (Guía de usuario de Amazon MWAA Serverless; AWS Big Data Blog, 2025-11-17).

---

10. AWS Glue Workflows y triggers de eventos

Glue puede orquestar a sí mismo sin Step Functions. «Un trigger se dispara bajo demanda, según un horario, o según una combinación de eventos», con valores de Type SCHEDULED, CONDITIONAL, ON_DEMAND y EVENT.

Cuatro trampas que vale la pena memorizar:

1. Los triggers condicionales solo ven ejecuciones iniciadas por un trigger. Si un trabajo se inició de otra manera, su completado nunca dispara el trigger condicional.
2. Una ejecución de workflow iniciada por EventBridge que falla consume su evento: «ese evento o lote de eventos ya no se considera para iniciar una ejecución de workflow», y no hay reentrega.
3. Glue no reintenta ejecuciones de workflow que fallan por límites de concurrencia superados.
4. Los crawlers y los trabajos no son intercambiables dentro de un mismo trigger: el tope de dos crawlers es una regla dura, y superar los 100 componentes puede romper las operaciones de reanudación y detención.

10.1 Ejemplo resuelto E10: cadena solo con Glue frente a Step Functions

---

11. Seguridad: roles de ejecución de mínimo privilegio

Los roles de orquestación son una superficie de escalada de privilegios, porque una máquina de estados puede iniciar trabajos que escriben en tu lago. El propio ejemplo de mínimo privilegio de Distributed Map de AWS concede exactamente dos cosas:

La forma de esa segunda sentencia es el punto: StartExecution recibe el ARN de una máquina de estados; DescribeExecution y StopExecution reciben el ARN de una ejecución. Conceder DescribeExecution contra stateMachine:... no concede nada.

Una lista de comprobación completa de mínimo privilegio para un orquestador de lakehouse:

---

12. La matriz de decisión de planificadores

12.1 La matriz

Dos entradas que pertenecen en la pizarra pero rara vez se enseñan:

• cron en una instancia EC2: autooperado, siempre activo, sin historial de ejecuciones, sin primitivas de reintento, sin rastro de auditoría más allá de tus propios logs. Es la línea base desde la que todos empiezan, y lo que toda opción gestionada está discutiendo. Elígelo solo cuando ya operes esa flota por otras razones y el horario sea trivial.
• Orquestadores de terceros (Airflow de código abierto que operas tú mismo, o un orquestador comercial): compras portabilidad de motor y el conjunto de habilidades existente de un equipo, y te asumes el planificador, la base de datos de metadatos, las actualizaciones y la guardia. ZS publicó exactamente esta evaluación, comparando «Amazon MWAA, Azkaban en Amazon EMR y AWS Step Functions» antes de elegir MWAA con cuentas de AWS por cliente para el aislamiento de inquilinos (AWS Big Data Blog, 2022-09-16).

12.2 Comprobación de relación: patrón a herramienta

---

Actualizaciones de 2026 (en octubre de 2026)

• 📚 ¿Sabías que…? El patrón de enrutado de S3 a EventBridge a Glue/Firehose no cambió en 2026: lo que cambió es dónde puede aterrizar el resultado transformado: Firehose hacia S3 Tables llegó a GA el 2025-03-14, así que la misma cadena dirigida por eventos puede terminar ahora en una tabla Iceberg gestionada en lugar de un prefijo en bruto (AWS Big Data Blog, 2025-03-14). La forma de la orquestación es estable; los destinos se ampliaron.

---

Casos Reales

AWS publica cómo se ven estas abstracciones en producción. Cada cifra de abajo es afirmada por el cliente o por AWS y no auditada, con la fuente nombrada para que puedas comprobarla: el punto examinable es el patrón, no el marketing.

Caso A, Transport for NSW: más de 400 workflows fuera de una herramienta ETL con licencia

«El equipo también usó AWS Step Functions para mejorar la orquestación y la monitorización de workflows… Para el almacenamiento escalable, el equipo adoptó Amazon Simple Storage Service (Amazon S3) como fundamento de su lago de datos.»: caso de estudio de AWS (consultado 2026-10-11)

La lección de orquestación es la que el propio AWS pone en la franja de beneficios: quitar la factura de la licencia fue la victoria financiera, pero Step Functions fue el mecanismo que hizo de la orquestación y la monitorización una competencia compartida en lugar de una de especialista. «Más miembros del equipo capaces de gestionar flujos de trabajo de datos con herramientas nativas de la nube, eliminando la dependencia de la experiencia en la plataforma heredada» es un resultado de orquestación, no de ETL.

Caso B, TrueCar: quitar el horario, no afinar el motor

El punto de orquestación: el 48x de TrueCar vino de quitar el horario de lote, no de un motor de consultas más rápido. Cuando el trigger pasa de un cron nocturno a un evento, la capa de orquestación cambia con él: que es el argumento de la sección 6 en un solo número de cliente. Las barras de TfNSW son conversiones a índice de la reducción de coste «80%» publicada por AWS y del «de varios meses» a «menos de 3 semanas» de plazo, mostradas contra una línea base heredada de 100.

Caso C, Cisco Webex: enrutado dirigido por eventos a 147 TB por día

La lectura de orquestación: el volumen de eventos de Cisco (más de 100.000 millones de mensajes al día) es exactamente el régimen donde un cron de sondeo no puede competir con un bus de eventos con filtrado por contenido, y donde el origen, filtro, enriquecimiento y destino al estilo Pipe le gana a una flota de consumidores a medida. Las decisiones de enrutado a esa tasa pertenecen a los patrones, no al código.

• 📚 ¿Sabías que…? Cada cifra de esta sección es la medición de un cliente sobre una carga de trabajo, y las páginas de TfNSW y Cisco no tienen fecha: AWS solo publica «consultado en octubre de 2026» para ellas. Nunca las reexpongas como especificaciones actuales de AWS; son instantáneas fechadas de migraciones concretas (digest 18, fuentes S3, S8, S12).

---

Preguntas de Práctica (Practice Questions)