Modernizá tu arquitectura serverless con Terraform

Modernizar arquitectura serverless con Terraform significa definir todos los recursos de AWS (Lambda, API Gateway, Cognito, S3, CloudFront) en archivos de código versionables, y desplegarlos con un solo comando en vez de hacer clic en la consola. El caso Wild Rydes, publicado el 1 de junio de 2026 en dev.to, muestra exactamente eso: el workshop serverless de referencia de AWS pasó de infraestructura manual a IaC completo con Terraform y GitHub Actions, reduciendo los tiempos de deployment de forma medible.

Hosting es un servicio de alojamiento de sitios web en servidores remotos, proporcionado por empresas especializadas, que permite que los sitios sean accesibles en internet. Incluye almacenamiento de archivos, bases de datos, procesamiento, y mantenimiento de la infraestructura necesaria.

Qué es la modernización serverless y por qué importa

Terraform es una herramienta open-source de HashiCorp que te permite describir tu infraestructura en archivos HCL (HashiCorp Configuration Language) y aplicar esos cambios de forma declarativa. No es un concepto nuevo, pero aplicarlo a arquitecturas serverless en AWS es donde el cambio se siente de verdad.

El proyecto Wild Rydes nació como un workshop oficial de AWS para aprender serverless: una app de transporte ficticia con backend en Lambda, autenticación en Cognito y datos en DynamoDB. Durante años funcionó como referencia, pero el setup era manual: entrabas a la consola de AWS, creabas cada recurso a mano, y rezabas para que el entorno de tu compañero de trabajo estuviera configurado igual. Spoiler: nunca estaba igual.

La modernización publicada en junio de 2026 cambia eso. Todo el stack se define en Terraform. Levantás el entorno con terraform apply y tenés los mismos recursos en dev, staging y producción, sin discrepancias. Y si algo se rompe, el MTTR (tiempo medio de recuperación) baja porque sabés exactamente qué estaba corriendo y podés recrearlo.

Blexr, según su reporte de 2026, documentó que después de adoptar IaC en su arquitectura web, mejoró sus Core Web Vitals de 80 a 95 puntos y vio un incremento del 30% en conversión. El vínculo no es magia: cuando controlás la infraestructura como código, podés optimizar configuraciones de CloudFront o Lambda sin miedo a romper algo que no documentaste.

Los pilares de la modernización: Terraform e Infrastructure as Code

Infrastructure as Code (IaC) es el concepto de describir infraestructura en archivos de texto con la misma lógica con que escribís código: versionable en Git, revisable con pull requests, testeable, y ejecutable de forma reproducible.

Terraform, en el ecosistema AWS, compite directamente con AWS CloudFormation. La diferencia práctica: Ya lo cubrimos antes en opciones de cloud hosting disponibles.

Característica	Terraform	AWS CloudFormation
Lenguaje	HCL (legible, conciso)	JSON/YAML (verboso)
Multi-cloud	Sí (AWS, GCP, Azure)	Solo AWS
State management	Archivo .tfstate (S3 + DynamoDB para lock)	Gestionado por AWS
Plan previo	terraform plan muestra qué cambia antes de aplicar	Change sets (menos interactivo)
Velocidad de aprendizaje	Curva media, comunidad enorme	Más integrado en el ecosistema AWS
Drift detection	terraform plan detecta cambios manuales	Drift detection disponible pero separado

Para Wild Rydes, la estructura básica de archivos queda así:

main.tf — recursos principales (Lambda, API Gateway, Cognito, DynamoDB)
variables.tf — parámetros configurables (nombre del entorno, región, ARNs)
outputs.tf — valores exportados (endpoint de API, URL de CloudFront)
providers.tf — proveedor AWS con versión fija

La regla de oro: nunca hagás cambios manuales en la consola de AWS si estás usando Terraform. Si lo hacés, el state se desincroniza y el próximo terraform apply puede pisar ese cambio sin avisarte.

Arquitectura de Wild Rydes modernizada con Terraform

Según el artículo publicado por Norvik Tech el 1 de junio de 2026, la arquitectura modernizada tiene estos componentes, todos definidos como código:

AWS Lambda: el compute sin servidor

Las funciones Lambda manejan la lógica de negocio: registrar usuarios, procesar solicitudes de viaje, consultar estado. En Terraform, cada función tiene su aws_lambda_function con el runtime, el handler, las variables de entorno y los permisos IAM asociados. Nada de esto vive en la consola.

API Gateway: los endpoints expuestos

API Gateway es lo que expone las Lambdas al mundo exterior como endpoints HTTP REST. La definición en Terraform incluye rutas, métodos, integraciones y las políticas CORS. Un recurso aws_api_gateway_rest_api más sus aws_api_gateway_resource hijos.

Amazon Cognito: autenticación sin complejidad

Cognito maneja registro de usuarios, login y tokens JWT sin que tengas que construir ese sistema desde cero. En Terraform se define con aws_cognito_user_pool y aws_cognito_user_pool_client. El frontend recibe el pool ID como output y lo usa directamente.

CloudFront + S3: el frontend distribuido

El sitio estático vive en un bucket S3 privado, servido a través de CloudFront con HTTPS. CloudFront es quien recibe las peticiones del usuario y las sirve desde el edge más cercano. Terraform crea el bucket, la distribución de CloudFront y la Origin Access Control (OAC) que conecta ambos sin exponer el bucket directamente.

DynamoDB: los datos

La tabla de DynamoDB almacena el estado de los viajes. Con aws_dynamodb_table en Terraform definís el nombre, las claves, la capacidad y los índices secundarios. En 10 líneas de HCL. Sobre eso hablamos en resolver problemas de hosting y dominio.

CI/CD con GitHub Actions y Terraform: pipeline automatizado

Ponele que estás trabajando en el pipeline y hacés un push a la rama main. GitHub Actions toma ese commit, ejecuta el workflow, y si todo está bien, aplica los cambios en AWS. Sin que toques la consola. Así funciona la modernización de Wild Rydes.

El workflow básico tiene esta secuencia:

• Checkout: descarga el código del repositorio
• terraform init: inicializa providers y backend remoto (S3 + DynamoDB para el state)
• terraform validate: verifica sintaxis y referencias
• terraform plan: muestra qué va a cambiar (y guarda el plan como artefacto)
• Aprobación manual (en rama main): un humano revisa el plan antes de continuar
• terraform apply: ejecuta los cambios en AWS con el plan aprobado

Un detalle que mucha gente ignora y después lo lamenta: guardá el plan de Terraform como artefacto en Actions, y usá ese mismo plan en el apply. Si no, hay una ventana de tiempo entre el plan y el apply donde alguien pudo haber cambiado algo en la infra (drift), y tu apply puede ejecutar cosas diferentes a lo que aprobaste.

¿Y los secretos de AWS? Las credenciales van como secrets en el repositorio de GitHub, nunca en el código. Para producción, lo correcto es usar OIDC (OpenID Connect) con un IAM Role, que emite tokens temporales sin necesidad de credenciales de larga duración. Menos exposición, más seguridad.

Los pipelines serverless con GitHub Actions y Terraform ya son práctica estándar en equipos que manejan múltiples entornos. El beneficio más concreto no es la velocidad del deployment, sino que el entorno reproducible elimina el clásico “funciona en mi máquina” de la infraestructura.

Implementación paso a paso: de la infraestructura manual a código

Si tenés una arquitectura serverless en AWS que hasta ahora creaste a mano, el camino para migrarla a Terraform no es tirarlo todo y empezar de cero. Es más pragmático:

Paso 1: Importar lo que ya existe. Terraform tiene el comando terraform import que lee recursos existentes en AWS y los trae al state. Así podés escribir la definición HCL de un recurso que ya existe y sincronizarla sin recrearlo.

Paso 2: Organizar los archivos. La convención para proyectos medianos es separar en módulos: un módulo para Lambda, uno para API Gateway, uno para auth. Cada módulo tiene su main.tf, variables.tf y outputs.tf. Evitá tener un solo main.tf con 500 líneas.

Paso 3: Backend remoto para el state. El terraform.tfstate no puede vivir en tu máquina local si trabajan en equipo. Configurá un backend en S3 con DynamoDB para el lock. Así dos personas no pueden aplicar cambios al mismo tiempo. Cubrimos ese tema en detalle en infraestructura moderna en la nube.

Paso 4: Variables por entorno. Usá archivos terraform.tfvars separados para dev, staging y prod. Los valores que cambian entre entornos (nombres de recursos, capacidades de DynamoDB, configuraciones de Cognito) van ahí.

Paso 5: GitHub Actions. Una vez que el código está en orden, el workflow de Actions es el último paso. Empezá con un pipeline que solo haga plan en todas las ramas y apply solo en main, con aprobación manual.

Si buscás hosting para los proyectos web que rodean esta arquitectura, donweb.com tiene opciones de cloud y VPS compatibles con pipelines de Terraform.

Métricas y resultados: cómo medir el éxito de la modernización

Modernizar sin medir es hacer turismo. Los KPIs concretos que importan:

• Deployment time: cuánto tardaba un deploy manual vs. el pipeline automatizado. En Wild Rydes, la reducción fue significativa según el análisis de Norvik Tech (los números exactos dependen de la complejidad del stack, pero la referencia apunta a mejoras de 40-60% en tiempo).
• MTTR (Mean Time To Recovery): iFood, después de adoptar IaC en su arquitectura serverless, logró reducir su MTTR en un 90%. Si algo se rompe, recreás el entorno desde código en minutos.
• Drift incidents: cuántas veces alguien hizo un cambio manual en la consola que no quedó documentado. Con Terraform y el comando terraform plan corriendo en CI, esto se detecta antes de que cause problemas.
• Disponibilidad: iFood también documentó +30% de disponibilidad. No porque Terraform haga magia, sino porque la infraestructura documentada como código es más fácil de entender, revisar y corregir.

Para observabilidad, la arquitectura de Wild Rydes modernizada integra CloudWatch para logs y métricas de Lambda, y X-Ray para trazas distribuidas. Todo esto también se puede configurar en Terraform: los aws_cloudwatch_log_group, las alarmas, los dashboards. Así el monitoreo también queda versionado.

Errores comunes al modernizar con Terraform

Error 1: Guardar el state local y en Git. El terraform.tfstate contiene datos sensibles (IDs de recursos, a veces ARNs con información de la cuenta). Nunca va en Git. Y si lo guardás solo en tu máquina, el día que la laptop explota, tu equipo no puede operar la infra. La solución es el backend remoto en S3 desde el primer día.

Error 2: Un solo workspace para todos los entornos. Usar el mismo state para dev, staging y prod es un accidente esperando pasar. Un terraform destroy en el workspace equivocado borra producción. Usá workspaces o directorios separados por entorno.

Error 3: No versionar los providers. Si no fijás la versión del provider de AWS en providers.tf, Terraform puede descargar una versión diferente la próxima vez que alguien haga terraform init. Un provider actualizado puede deprecar recursos o cambiar comportamientos. Siempre version = "~> 5.0" o similar.

Error 4: Hacer apply sin revisar el plan. Terraform dice qué va a crear, modificar o destruir antes de aplicar. Si ves “will be destroyed” y seguís, después no te quejés. El plan es tu última oportunidad de detectar un recurso que no debería estar en la lista. Complementá con pipelines de CI/CD en 2026.

Preguntas Frecuentes

¿Cómo modernizar mi arquitectura serverless con Terraform?

El proceso tiene cuatro pasos concretos: importar los recursos existentes con terraform import, organizar el código en módulos (Lambda, API Gateway, auth), configurar un backend remoto en S3 para el state, y conectar el repositorio a un pipeline de CI/CD con GitHub Actions. No es necesario recrear todo desde cero; Terraform puede tomar el control de infraestructura que ya existe en AWS.

¿Qué es Infrastructure as Code y cómo usarla en AWS?

Infrastructure as Code (IaC) es definir los recursos de AWS (servidores, bases de datos, redes, funciones Lambda) en archivos de texto que se pueden versionar en Git, revisar con pull requests y ejecutar de forma reproducible. En AWS, las herramientas principales son Terraform (multi-cloud, HCL) y CloudFormation (nativo AWS, JSON/YAML). Con Terraform, un terraform apply crea o actualiza todos los recursos definidos en el código.

¿Cómo configurar CI/CD con Terraform y GitHub Actions?

El workflow de GitHub Actions ejecuta en orden: checkout del código, terraform init con backend S3, terraform validate para verificar sintaxis, terraform plan (cuyo output se guarda como artefacto), aprobación manual si es la rama principal, y finalmente terraform apply usando el plan guardado. Las credenciales de AWS van como secrets del repositorio, preferiblemente usando OIDC con IAM Roles temporales en vez de access keys de larga duración.

¿Cuáles son los beneficios de automatizar el deployment en serverless?

Los beneficios medibles incluyen: entornos idénticos entre dev, staging y producción (elimina el “funciona en mi máquina”), detección automática de drift cuando alguien hace cambios manuales en la consola, MTTR reducido porque recreás la infraestructura desde código, y auditoría completa de qué cambió, cuándo y quién lo aprobó. iFood documentó -90% en MTTR y +30% en disponibilidad tras adoptar IaC en su stack serverless.

¿Qué servicios de AWS se usan con Terraform para modernizar arquitecturas serverless?

Los servicios centrales son: AWS Lambda (funciones de compute sin servidor), API Gateway (exposición de endpoints HTTP), DynamoDB (base de datos NoSQL), Amazon Cognito (autenticación y gestión de usuarios), S3 (almacenamiento de assets estáticos) y CloudFront (CDN para distribución con baja latencia). Cada uno tiene su recurso Terraform correspondiente: aws_lambda_function, aws_api_gateway_rest_api, aws_dynamodb_table, aws_cognito_user_pool, aws_s3_bucket y aws_cloudfront_distribution.

Conclusión

La modernización de Wild Rydes publicada en junio de 2026 no es solo un ejercicio académico. Es el patrón que equipos reales están aplicando para pasar de arquitecturas serverless creadas a mano a infraestructura como código: versionable, reproducible y operable por más de una persona.

Terraform es la herramienta que hace posible ese salto. No porque sea perfecta (el manejo del state tiene sus complejidades, el drift puede sorprenderte), sino porque el costo de aprender IaC es mucho menor que el costo de seguir operando infraestructura que solo existe en la memoria de la persona que la configuró.

Si tu arquitectura serverless todavía vive en la consola de AWS, el primer paso es empezar por el backend remoto del state y un módulo Terraform para uno solo de tus servicios. No el stack completo. Un módulo. Y construir desde ahí.

Fuentes

• Norvik Tech – Modernizing Wild Rydes with Terraform (junio 2026)
• AWS Samples – Serverless Workshops (repositorio oficial)
• David Iriondo – Building a Serverless CI/CD Pipeline con GitHub Actions y Terraform
• AWS Builders – API REST con Terraform, Serverless, Lambda y Python: CI/CD
• AWS – Arquitecturas Serverless con Lambda