Amazon MWAA ya soporta Apache Airflow 3.2: qué cambia para equipos de datos en AWS

Introducción

Hasta hace unas semanas, los equipos que ejecutaban pipelines de datos en AWS con Amazon Managed Workflows for Apache Airflow (MWAA) estaban limitados a versiones anteriores de Airflow, como 2.11, que aunque robustas, carecían de funcionalidades críticas para entornos de producción modernos. Con el anuncio del soporte para Apache Airflow 3.2 en MWAA, AWS cierra esa brecha al permitir la ejecución de workflows con un orquestador que ya incluye mejoras significativas en scheduling basado en datos, gestión de XCom y capacidades Human-in-the-Loop (HITL). Esto no es un mero update de versión: implica cambios en cómo se diseñan, ejecutan y auditan los pipelines de datos en la nube.

Para equipos de DevOps y data engineering, la pregunta no es si migrar, sino cuándo hacerlo y qué ajustes requieren los DAGs existentes. La buena noticia es que MWAA permite lanzar entornos nuevos con 3.2 o actualizar desde 2.11+ sin necesidad de infraestructura adicional. Sin embargo, hay detalles técnicos que vale la pena revisar antes de apretar el botón de upgrade.

Qué ocurrió

El 15 de abril de 2025, AWS anunció oficialmente que Amazon MWAA ahora soporta Apache Airflow 3.2 en todas sus regiones disponibles. Este release es el primero en MWAA que incorpora una versión mayor de Airflow desde que se lanzó la compatibilidad con Airflow 2.x en 2021. Según el anuncio oficial, la actualización está disponible tanto para nuevos entornos como para migraciones desde versiones iguales o superiores a Airflow 2.11.

Las novedades más relevantes para equipos técnicos giran en torno a tres ejes:

1. Scheduling basado en datos con particionado de assets: permite disparar DAGs aguas abajo no solo cuando un asset completo está listo, sino cuando una porción específica de ese asset cumple una condición (por ejemplo, una ruta en S3 particionada por fecha).
2. Mejoras en productividad de desarrolladores: incluye renderizado virtualizado en la Grid View para DAGs grandes, gestión completa de XCom desde la UI de Airflow y soporte asíncrono en PythonOperator.
3. Capacidades HITL (Human-in-the-Loop): agrega un historial de auditoría completo para aprobaciones, soporte para AgenticOperator y callbacks síncronos para alertas de deadline.

Según el changelog de Apache Airflow 3.2, estas mejoras responden a necesidades comunes en entornos de producción:

• Reducción de tiempo de ejecución: el renderizado virtualizado en Grid View acelera la visualización de DAGs con más de 100 tareas.
• Precisión en pipelines: el particionado de assets evita reprocesamientos innecesarios al ejecutar solo las porciones de datos modificadas.
• Traceabilidad: el historial de auditoría en HITL facilita cumplir con requisitos de compliance en sectores regulados como finanzas o salud.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para los equipos de infraestructura, la migración a Airflow 3.2 en MWAA implica cambios en la configuración de los workers y el balanceo de carga. AWS ya anunció que los entornos actualizados usarán Python 3.11 por defecto, lo que requiere revisar dependencias en los DAGs que usen librerías compiladas para esa versión. Además, el soporte para XCom desde la UI reduce la necesidad de acceder a bases de datos externas (como PostgreSQL o Redis) para debuggear valores intermedios, lo que simplifica la arquitectura de logging.

En cuanto a seguridad, Airflow 3.2 introduce mejoras en el manejo de credenciales con el operador SecretsBackend, que ahora soporta integración nativa con AWS Secrets Manager y AWS Systems Manager Parameter Store. Esto reduce la exposición de secretos en variables de entorno o archivos de configuración. Sin embargo, los equipos de seguridad deben revisar los permisos IAM de los workers, ya que el nuevo operador puede requerir políticas adicionales para acceder a Secrets Manager.

Para DevOps, el impacto más significativo está en la gestión de recursos. El particionado de assets en el scheduling puede reducir costos al evitar ejecuciones innecesarias de DAGs aguas abajo. Según benchmarks internos de AWS, en pipelines con particionado diario de datos en S3 (ej: s3://bucket/year=2025/month=04/day=15/), el uso de CPU en workers puede caer hasta un 30% al evitar reprocesamientos. Esto es crítico en entornos con facturación por hora de CPU, como los de MWAA.

Para equipos de cloud, la migración a 3.2 permite aprovechar mejor los servicios de AWS como Step Functions para workflows híbridos. Airflow 3.2 incluye mejor soporte para triggers síncronos con callbacks, lo que facilita la integración con servicios serverless como Lambda o Fargate. Esto elimina la necesidad de implementar soluciones personalizadas para orquestar workflows entre Airflow y otros servicios de AWS.

Detalles técnicos

Requisitos y versiones afectadas

• MWAA: Requiere entorno actualizado a la versión más reciente del servicio (lanzada el 15/04/2025). Los entornos existentes con Airflow 2.11+ pueden actualizarse via AWS Console.
• Python: Los workers usarán Python 3.11 por defecto. Los DAGs que usen librerías como pandas o numpy deben estar compiladas para Python 3.11. Si un DAG falla por falta de dependencias, MWAA lo reportará en los logs de CloudWatch con el error:

  ModuleNotFoundError: No module named 'pandas'
  

Para solucionarlo, el equipo debe recrear el environment con un requirements.txt actualizado:

  pandas==2.2.2
  numpy==1.26.4
  

• XCom: Airflow 3.2 migra el backend de XCom a un sistema basado en objetos (similar a cómo funciona en Airflow 2.x pero con mejoras de rendimiento). Los equipos que usen XCom con Redis o PostgreSQL deben migrar sus datos manualmente antes de actualizar, usando el script proporcionado en la documentación de Airflow.

Nuevos operadores y cambios en APIs

• Asset Partitioning: El nuevo operador Asset permite definir particiones en S3, JDBC o incluso APIs externas. Por ejemplo, para disparar un DAG cuando solo una partición de una ruta en S3 está disponible:

  from airflow.operators.trigger_dagrun import TriggerDagRunOperator

  @dag(
      dag_id="process_partitioned_data",
      schedule_interval=None,
  )
  def process_partitioned_data():
      trigger = TriggerDagRunOperator(
          task_id="trigger_downstream",
          trigger_dag_id="downstream_dag",
          conf={"partition": "{{ ds_nodash }}"}  # Ej: "20250415"
      )
  

Esto evita ejecutar el DAG aguas abajo hasta que la partición específica esté lista.

• AgenticOperator: Introduce soporte para agentes de IA en workflows. Requiere instalar el paquete apache-airflow-providers-agentic y configurar un endpoint de agente (ej: un modelo de LLM en SageMaker):

  pip install apache-airflow-providers-agentic
  

Luego, en el DAG:

  from airflow.providers.agentic.operators.agentic import AgenticOperator

  agent_task = AgenticOperator(
      task_id="generate_report",
      agent_type="llm",
      input_data={"query": "resume sales data for Q1 2025"},
  )
  

• Deadline Alerts: Los callbacks síncronos para alertas de deadline permiten cancelar tareas que superen un tiempo máximo de ejecución. Requiere configurar el operador TimeSensor con un parámetro timeout:

  from airflow.sensors.time_sensor import TimeSensor

  timeout_sensor = TimeSensor(
      task_id="check_timeout",
      timeout=3600,  # 1 hora
      mode="poke",
      poke_interval=60,
  )
  

Integración con S3 y otros servicios de AWS

Airflow 3.2 mejora el operador S3KeySensor para soportar etags y checksums en archivos, lo que permite detectar cambios parciales en datos. Por ejemplo, para verificar que solo una parte de un archivo Parquet en S3 ha cambiado:

  from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor

  sensor = S3KeySensor(
      task_id="check_parquet_changes",
      bucket_name="mi-bucket",
      bucket_key="data/year=2025/month=04/part-00000.parquet",
      check_fn=lambda x: x.get("ETag") != "d41d8cd98f00b204e9800998ecf84279",  # ETag cambiado
  )
  

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar la compatibilidad de los DAGs existentes

Antes de actualizar, revisá si tus DAGs usan funcionalidades que han cambiado en Airflow 3.2. Los checks críticos son:

• Dependencias de Python: Verificá que todas las librerías en requirements.txt estén compiladas para Python 3.11. Usá el comando:

  pip install -r requirements.txt --target ./vendor
  

Si falla, actualizá las librerías o usá un Dockerfile personalizado para MWAA.

• XCom: Si usás un backend externo (Redis, PostgreSQL), migrá los datos a XCom nativo usando el script oficial:

  airflow db migrate-xcom --old-backend redis://localhost:6379 --new-backend db+postgresql://user:pass@host:5432/db
  

• Schedules: Revisá que los schedules de tus DAGs usen la sintaxis compatible con Airflow 3.2. Por ejemplo, si tenés un DAG con schedule_interval="@daily", cambialo a schedule="0 0 * * *" para evitar warnings.

2. Planificar la migración en entornos de staging

AWS recomienda probar la migración en un entorno de staging antes de actualizar producción. Para crear un entorno de prueba con Airflow 3.2:

1. Abrí la consola de MWAA y seleccioná «Create environment».
2. Elegí Airflow 3.2 en la lista de versiones.
3. Configurá el entorno con los mismos parámetros que el de producción (VPC, IAM roles, etc.).
4. Desplegá los DAGs de prueba y verificá:

– Que los schedules funcionen como en producción.

– Que las tareas que usan XCom o S3KeySensor no fallen.

3. Actualizar entornos de producción

Si los tests en staging son exitosos, actualizá el entorno de producción con estos pasos:

1. Hacé un backup de los metadatos de Airflow (bases de datos de Airflow y XCom) usando:

   airflow db backup --backup-path /tmp/backup.sql
   

1. Actualizá el entorno via AWS Console:

– Hacé clic en «Upgrade».

– Elegí Airflow 3.2 en la lista de versiones disponibles.

1. Monitoreá los logs en CloudWatch para detectar errores en:

– Tareas que usen APIs obsoletas (ej: airflow.models.BaseOperator en lugar de airflow.models.Operator).

4. Aprovechar las nuevas funcionalidades

Una vez actualizado, implementá las mejoras de Airflow 3.2 en tus pipelines:

• Asset Partitioning: Modificá los DAGs aguas abajo para que se disparen solo cuando una partición específica de datos esté disponible. Por ejemplo, si tus datos están en S3 con particionado por fecha:

  from airflow.models import DAG
  from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor
  from datetime import datetime

  with DAG(
      dag_id="process_daily_data",
      schedule_interval="{{ ds }}",  # Ej: "2025-04-15"
      start_date=datetime(2025, 1, 1),
  ) as dag:
      check_partition = S3KeySensor(
          task_id="check_partition",
          bucket_name="mi-bucket",
          bucket_key=f"data/year={{ ds_nodash[:4] }}/month={{ ds_nodash[4:6] }}/day={{ ds_nodash[6:] }}/*.parquet",
      )
  

• Deadline Alerts: Agregá timeouts a tareas críticas para evitar costos innecesarios. Por ejemplo, para una tarea que procese datos de ventas:

  from airflow.decorators import task
  from airflow.utils.state import TaskInstanceState

  @task(task_id="process_sales_data", timeout=7200)  # 2 horas
  def process_sales():
      # Lógica de procesamiento
      pass
  

Conclusión

La incorporación de Apache Airflow 3.2 en Amazon MWAA no es un mero update de versión, sino una actualización estratégica para equipos que buscan optimizar pipelines de datos con scheduling basado en datos, mejoras en productividad y capacidades Human-in-the-Loop. Para DevOps, implica ajustar configuraciones de Python y XCom, mientras que para data engineering, abre la puerta a workflows más precisos y auditable.

La recomendación es clara: evaluá la compatibilidad de tus DAGs, probá la migración en staging y actualizá en producción con un plan de rollback. Las mejoras en asset partitioning y deadline alerts pueden traducirse en ahorros significativos de costos y tiempo, especialmente en entornos con pipelines complejos. Si tus equipos ya usan MWAA con Airflow 2.11+, el upgrade a 3.2 es un paso natural para mantener la plataforma al día con las necesidades de datos modernas.

Fuentes

• AWS Announces Support for Apache Airflow 3.2 in Amazon MWAA
• Apache Airflow 3.2 Changelog
• Migrating XCom Backends in Airflow 3.2