Introducción

Cuando un equipo quiere escalar pipelines de datos sin aumentar overhead operativo, el enfoque serverless suele ser la opción más eficiente. En AWS, la combinación S3 + Glue + Athena cubre gran parte de los casos de ETL analítico sin gestionar clusters permanentes.

El reto no es crear recursos una vez. El reto real es mantener consistencia entre entornos, cambios y equipos. Ahí es donde Terraform marca diferencia: convierte decisiones de infraestructura en código versionado, revisable y repetible.

Este artículo explica un patrón práctico para construir ETL serverless en AWS sin caer en complejidad innecesaria.

Objetivo de la arquitectura

1. Ingestar datos en S3 de forma ordenada.
2. Transformar datos con Glue Jobs.
3. Exponer datasets curados vía Athena.
4. Gestionar toda la plataforma como IaC con Terraform.
5. Mantener coste y operación bajo control.

Componentes base y responsabilidades

S3 como storage por capas

Separar rutas por estado del dato:

• bronze para ingesta.
• silver para limpieza y estandarización.
• gold para consumo analítico.

Esto facilita permisos, retención y gobierno.

Glue para catalogación y transformación

Glue Crawler detecta esquemas, y Glue Jobs ejecuta transformaciones.

Buenas prácticas:

• Scripts PySpark pequeños y modulares.
• Parámetros por entorno.
• Logs y métricas habilitadas por defecto.

Athena como capa SQL

Athena permite consulta serverless sobre datos en S3, ideal para BI y validaciones operativas.

Clave de coste:

• Formato columnar.
• Particionado correcto.
• Evitar SELECT * en tablas pesadas.

Terraform como motor de despliegue

Terraform define y versiona:

• Buckets S3.
• Catalogo Glue.
• Jobs y roles IAM.
• Workgroups de Athena y configuraciones base.

Resultado: menos drift, mejor trazabilidad y despliegues consistentes.

Estructura de módulos Terraform recomendada

Un patrón simple que funciona:

1. modules/storage
2. modules/catalog
3. modules/jobs
4. modules/query
5. environments/dev|staging|prod

Cada módulo debe exponer inputs claros y outputs reutilizables. Evita mega módulos monolíticos: dificultan testing y evolución.

Flujo operativo sugerido

1. Commit de cambio de infraestructura.
2. Pull Request con terraform fmt + terraform validate.
3. terraform plan revisado por otro miembro del equipo.
4. Apply controlado por entorno.
5. Verificación post deploy (jobs, catalogo, queries base).

Este flujo evita sorpresas en producción y facilita auditoría de cambios.

Riesgos comunes y mitigaciones

Riesgo 1: permisos IAM demasiado amplios

Mitigación:

• Principio de mínimo privilegio.
• Roles separados por función (crawler, job, consulta).
• Revisión periodica de políticas.

Riesgo 2: Glue Job acoplado a rutas duras

Mitigación:

• Parametrizar rutas S3 por entorno.
• Evitar hardcoded en scripts.
• Mantener convención de carpetas estable.

Riesgo 3: coste de Athena fuera de control

Mitigación:

• Workgroups con limites.
• Formato Parquet y compresión.
• Particiones alineadas con filtros.

Riesgo 4: drift entre entornos

Mitigación:

• Backend remoto con locking.
• Variables por entorno controladas.
• Prohibir cambios manuales en consola salvo emergencia.

Integración con CI/CD

Tu IaC no debería ejecutarse a mano de forma habitual. Integrar Terraform en pipeline aporta:

• Validación automática de cambios.
• Historial de planes/applies.
• Políticas antes de desplegar.
• Menor dependencia de conocimiento tribal.

Si quieres profundizar en este enfoque, revisa Pipeline CI/CD en AWS, donde detallo gates de calidad y rollback.

Relación con calidad de datos

Una plataforma ETL serverless no es solo infraestructura. Debe incorporar controles de calidad:

• Validación de esquemas.
• Reglas de negocio en transformaciones.
• Registro de rechazos.
• Alertas de fallos por lote.

Sin este bloque, puedes desplegar impecable y aún así generar datos no confiables.

Hoja de ruta de adopción en 3 iteraciones

Iteración 1: baseline funcional

• Bucket por capas.
• Catalogo inicial.
• Primer Glue Job.
• Athena operativo para consultas base.

Iteración 2: robustez

• Módulos Terraform maduros.
• Controles IAM refinados.
• Alertas de fallos en jobs.

Iteración 3: escalado

• Múltiples dominios de datos.
• Optimización de coste.
• CI/CD completo para infraestructura y jobs.

Checklist de producción

• Terraform state remoto con locking.
• Roles IAM por servicio y entorno.
• Glue Jobs parametrizados.
• Athena optimizado en formato/partición.
• Alertas de fallos y seguimiento de ejecuciones.
• Runbook de recuperación documentado.

Referencias recomendadas

• AWS Glue: What is AWS Glue?
• Amazon Athena User Guide
• AWS Prescriptive Guidance: Serverless ETL
• Terraform: Develop Modules

Cierre

El enfoque ETL serverless con Terraform funciona bien cuando combinas simplicidad de arquitectura con disciplina operativa. El objetivo no es solo “hacerlo serverless”, sino desplegar rápido sin perder control de calidad, seguridad y coste.

Siguiente paso práctico: aplica este patrón en un dominio pequeño durante dos sprints y mide tiempo de despliegue, tasa de fallo y coste por consulta.

¿Evolucionamos tu plataforma de datos?

Si quieres mejorar arquitectura, calidad y coste de tu pipeline, puedo ayudarte a aterrizar una hoja de ruta por fases.

Contactar Ver más sobre Data Engineering