AWS Step Functions: cómo orquestamos un pipeline IoT completo sin una línea de lógica de control

El problema que queríamos resolver

Antes de incorporar Step Functions al pipeline, la situación era la que probablemente muchos equipos reconocen:

• Los crawlers y jobs de Glue se corrían manualmente, esperando que terminaran antes de lanzar el siguiente paso.

• La lógica de orquestación vivía dentro del código: condicionales, sleeps, reintentos artesanales.

• Si algo fallaba en el medio de un pipeline con múltiples servicios, detectarlo a tiempo era difícil.

• Monitorear el estado de cada ejecución requería entrar a múltiples consolas y cruzar logs.

La complejidad no venía de los datos en sí. Venía de cómo estaban conectados todos los servicios. Y esa es exactamente la clase de problema que Step Functions resuelve.

La arquitectura que construimos

Para este Devtalk construimos una PoC de un pipeline IoT end-to-end. El objetivo era tener datos fluyendo desde sensores simulados hasta un dashboard de visualización, completamente orquestado y automatizado.

Generación de datos (capa on-prem simulada)

Una función Lambda disparada por Amazon EventBridge genera 100 registros por minuto simulando 50 sensores industriales distribuidos en 3 plantas. Los tipos de datos incluyen temperatura, humedad, presión, consumo eléctrico y vibración, todos en formato JSON.

Storage Layer: S3 en tres etapas

Los datos pasan por tres buckets S3 con roles bien definidos:

• devlights-datalake-raw: JSON crudo tal como llega de los sensores.

• devlights-datalake-processed: Parquet limpio, validado y particionado.

• devlights-datalake-curated: Datos agregados por hora y día, listos para dashboards.

Procesamiento: AWS Glue

AWS Glue maneja las transformaciones en tres capas:

Governance Layer: tres crawlers que descubren y catalogan los datos en cada bucket.

Data Catalog Layer: catálogos separados para raw, processed y curated, que permiten consultar los datos con Athena sin configuración adicional.

Processing Layer: dos jobs ETL:

• Raw to Processed: limpieza, validación y conversión a formato Parquet.

• Processed to Curated: agregaciones temporales para alimentar el dashboard. Ambos con job bookmarks habilitados, lo que garantiza que cada ejecución procese solo los datos nuevos.

Visualización: QuickSight

El dashboard final en Amazon QuickSight muestra gráficos de tendencias sobre los datos curados. Desde ahí, el equipo puede ver el comportamiento de los sensores sin interactuar con los datos crudos.

AWS Step Functions: el pegamento del pipeline

Con la arquitectura definida, el desafío siguiente era orquestar todo esto de forma confiable. Ahí entra Step Functions.

¿Qué es?

AWS Step Functions es un servicio serverless de orquestación de workflows. Permite coordinar múltiples servicios de AWS mediante máquinas de estado: flujos visuales donde cada paso es un estado, cada estado tiene un input y un output, y las transiciones entre estados están definidas explícitamente.

Las características que más nos importaron:

• Manejo automático de errores y reintentos — sin código de retry artesanal.

• Visualización gráfica de cada ejecución en tiempo real desde la consola de AWS.

• Integración nativa con Glue, Lambda, SNS, S3 y prácticamente cualquier servicio AWS.

• Modelo de cobro por transiciones — no hay costo fijo. Solo pagás por lo que el pipeline consume.

Los cuatro conceptos clave

Antes de ver cómo lo implementamos, vale la pena tener claros los conceptos básicos:

La State Machine que construimos: etl-data-team

La state machine etl-data-team controla la secuencia completa de crawlers y jobs de Glue para mover datos a través de las tres etapas del pipeline:

RAW → PROCESSED → CURATED

El flujo en detalle:

1. Start Raw Crawler — descubre los datos nuevos en el bucket raw.

2. Wait for Raw Crawler — espera a que el crawler termine (polling nativo de Step Functions).

3. Start Raw-to-Processed Job — lanza el job de Glue que limpia y convierte a Parquet.

4. Wait for Raw-to-Processed Job — espera la finalización del job.

5. Start Processed Crawler — cataloga los datos recién procesados.

6. Wait for Processed Crawler — espera al crawler.

7. Start Processed-to-Curated Job — ejecuta las agregaciones temporales.

8. Wait for Processed-to-Curated Job — espera la finalización.

9. Start Curated Crawler — cataloga los datos curados.

10. Success / Fail — la ejecución finaliza con uno de estos dos estados.

Cada paso espera al anterior antes de continuar. Eso es lo que antes se hacía manualmente o con lógica ad-hoc en el código.

Automatización y notificaciones: EventBridge + SNS

Una State Machine que hay que lanzar a mano no resuelve el problema de raíz. Por eso lo integramos con dos servicios más:

Amazon EventBridge

Configuramos una regla de schedule en EventBridge que dispara la State Machine automáticamente una vez por semana. Una sola regla, sin servidores, sin cron jobs, sin nada que mantener.

Simple Notification Service (SNS)

Dos reglas adicionales en EventBridge monitorean el resultado de cada ejecución:

• success-email-etl-data-team → envía un email al equipo cuando el pipeline termina correctamente.

• error-email-etl-data-team → envía una alerta si algo falla en cualquier punto del flujo.

El equipo no necesita entrar a la consola para saber si el pipeline corrió bien. La información llega sola.

Antes y después: el impacto real

Costos del PoC

Una de las preguntas más frecuentes cuando se evalúa Step Functions es el costo. Para esta PoC, los números son:

*Step Functions cobra por transiciones de estado. Para workflows de baja frecuencia como este (una vez por semana), el costo es prácticamente cero dentro del free tier de AWS.

Conclusión

Step Functions no es una herramienta para simplificar código. Es una herramienta para sacar la lógica de coordinación fuera del código y ponerla donde puede ser vista, monitoreada y mantenida de forma independiente.

Para pipelines de datos con múltiples servicios en secuencia, como este ETL con Glue, el valor es inmediato: cada paso está explícito, los errores se notifican solos, y cualquier miembro del equipo puede entrar a la consola y ver exactamente en qué estado está o estuvo cada ejecución.

"No toda la complejidad viene de los datos. A veces viene de cómo conectás todo. Step Functions resuelve eso."

Si tu equipo trabaja con pipelines de datos en AWS y todavía maneja la orquestación de forma manual o con lógica dispersa en el código, Step Functions es probablemente el cambio de menor fricción con mayor impacto que podés hacer hoy.

¿Querés implementar algo parecido en tu organización? En Devlights podemos ayudarte a diseñar y construir la arquitectura de datos que necesitás. Hablemos.