Alta Disponibilidad y Serverless con Terraform

Resumen Ejecutivo

Terra AWS es un proyecto de Infraestructura como Codigo (IaC) diseñado para aprovisionar y gestionar una arquitectura en la nube de alta disponibilidad, segura y escalable en Amazon Web Services (AWS) utilizando Terraform. La infraestructura da soporte a la plataforma de joyeria fina LuxGem Jewelry Store, transicionando un prototipo de desarrollo local orquestado en Docker Compose hacia un entorno de produccion robusto en AWS que combina contenedores autogestionados (ECS Fargate) y flujos serverless impulsados por eventos (API Gateway, Lambda, S3, SQS y SNS).

Situacion

El equipo de LuxGem habia desarrollado un prototipo funcional basado en Docker Compose con un backend en Node.js, un frontend en Next.js y una base de datos PostgreSQL. No obstante, para llevar el proyecto a produccion, se requeria una infraestructura cloud que cumpliera con estandares empresariales: alta disponibilidad multi-zona de disponibilidad, aislamiento estricto de componentes de red, persistencia administrada sin gestion directa de servidores y la capacidad de automatizar cargas e informes masivos mediante microservicios independientes que no sobrecargaran la aplicacion principal.

Objetivo

Disenar, codificar y desplegar la infraestructura cloud completa de LuxGem en AWS utilizando Terraform. El sistema debia garantizar tolerancia a fallos mediante un balanceador de carga, aislar las capas de aplicacion y base de datos en subredes privadas con NAT Gateways independientes por zona de disponibilidad, y habilitar un flujo serverless de importacion/exportacion de catalogos a traves de API Gateway y funciones Lambda conectadas a un almacenamiento privado en S3 y colas asincronas de mensajeria.

El Prototipo Local (JoyeriaCloud)

La aplicacion de joyeria fina LuxGem consta de tres componentes orquestados localmente:

Frontend: Una aplicacion en Next.js (App Router, React 19) con estilo premium (Glassmorphism, Tailwind CSS, fuentes Vollkorn) que consume la API del backend y maneja la cesta de compras mediante Zustand.
Backend: Una API REST en Node.js y Express con Sequelize como ORM para mapear la base de datos PostgreSQL.
Base de Datos: PostgreSQL ejecutandose en un contenedor Alpine con persistencia local y seeding de catalogos estructurados mediante sentencias SQL.

Arquitectura Cloud y Provisionamiento (Terraform)

Toda la infraestructura se define de forma modular y declarativa, abarcando las siguientes capas de servicios en AWS:

1. VPC y Aislamiento de Redes (`vpc.tf`)

La red se estructura con un CIDR principal 10.0.0.0/16 distribuido en dos Zonas de Disponibilidad (AZs: us-east-1a y us-east-1b) para tolerancia a fallos, dividida en tres capas funcionales:

Subredes Publicas: Alojan el Application Load Balancer (ALB) expuesto a los usuarios de internet y los NAT Gateways.
Subredes de Aplicacion: Privadas. Contienen las tareas de ECS Fargate (frontend y backend) y las funciones Lambda asociadas al VPC. No tienen direcciones IP publicas asignadas.
Subredes de Base de Datos: Privadas y dedicadas exclusivamente para la base de datos RDS, bloqueando cualquier conexion externa directa.

El diseño original contenia un error de enrutamiento cruzado donde las subredes de la AZ B apuntaban al NAT Gateway de la AZ A. Esto fue corregido en el codigo de Terraform para asegurar que cada AZ dirija su trafico saliente a traves de su respectivo NAT Gateway local, eliminando costos innecesarios de transferencia cross-AZ y mejorando la resiliencia general.

2. Capa de Contenedores y Balanceo (`ecs.tf`, `alb.tf`)

El prototipo de Docker Compose se traslada a ECS Fargate (servidores administrados por AWS):

ECS Cluster: luxgem-cluster con Container Insights habilitado para monitorizar el uso de CPU y memoria en CloudWatch.
Backend Service: Ejecuta tareas de Fargate (Node.js) detras de dos balanceadores de carga. Utiliza un ALB publico para procesar las llamadas /api/* hechas desde los navegadores de los clientes, y un ALB interno para llamadas Server-Side (SSR) desde el frontend, optimizando el ancho de banda y la latencia.
Frontend Service: Ejecuta tareas standalone de Next.js detras del ALB publico, respondiendo a las peticiones del puerto 3000.
CloudWatch Logs: Registro automatico de stdout/stderr de cada contenedor con politicas de retencion controladas.

3. Persistencia de Datos (`rds.tf`)

La base de datos relacional PostgreSQL local es reemplazada por RDS PostgreSQL 15:

Subnet Group que asocia las subredes privadas de base de datos en ambas AZs.
Instancia t3.micro con almacenamiento de estado solido gp3 de 20 GB de inicio, autoescalable a 100 GB para evitar cuellos de botella por volumen de datos.
Parameter Group personalizado que optimiza PostgreSQL 15, desactivando la obligatoriedad de SSL temporalmente en desarrollo e inicializando la extension requerida uuid-ossp para la generacion de identificadores unicos en el esquema de la base de datos.

4. Flujos Serverless y Procesamiento de Archivos (`lambda.tf`, `s3.tf`, `apigateway.tf`)

Para evitar que procesos pesados de importacion y exportacion degraden el rendimiento del backend de la joyeria, se diseño un subsistema serverless en Python 3.11:

Bucket S3: Almacenamiento privado de datos LuxGem con versionamiento habilitado y politicas estrictas de bloqueo de acceso publico.
Lambda import_data: Procesa peticiones HTTP POST con la ruta de un archivo CSV en S3, analiza las filas correspondientes a nuevos productos de joyeria y las inserta en la base de datos en RDS utilizando psycopg2. Si se agregan productos nuevos con exito, publica una alerta en SNS.
Lambda export_data: Consulta las tablas indicadas en la base de datos (con una whitelist de seguridad para evitar inyecciones), genera un archivo de tipo CSV, lo almacena de forma inmutable en S3 con un timestamp y devuelve al usuario una URL presirmada de S3 valida por una hora para la descarga del catalogo exportado.
API Gateway: Gateway HTTP v2 que enruta /import y /export a sus respectivas funciones Lambda con politicas CORS y autorizaciones de invocacion explicitas.

5. Mensajeria y Notificaciones Asincronas (`sns_sqs.tf`)

Para la notificacion de eventos criticos:

SNS Topic: Canal centralizado para reportar productos importados.
SQS Queue: Cola de mensajeria (notify-email) que realiza long polling de 20 segundos para minimizar costos de peticiones vacias. Posee una cola de descarte (Dead Letter Queue - DLQ) con Redrive Policy configurada a un maximo de 3 intentos de entrega fallidos.
Lambda notify: Escucha los mensajes de la cola SQS y los envia a los destinatarios mediante una suscripcion de correo configurada en SNS.

Stack Tecnologico Utilizado

Capa	Tecnologias
Infraestructura	Terraform v1.14+, AWS (VPC, ECS, Fargate, RDS, S3, Lambda, API Gateway, SQS, SNS, IAM, CloudWatch)
Aplicacion (Frontend)	Next.js (App Router, Standalone mode), React 19, Zustand, Tailwind CSS v4, Lucide React, Vollkorn Fonts
Aplicacion (Backend)	Node.js v20, Express, Sequelize ORM, PostgreSQL (driver pg), Multer, JWT
Automatizacion (Serverless)	Python 3.11, Psycopg2 (capa Lambda dedicada), Boto3
Contenedores locales	Docker, Docker Compose, Postgres 15 Alpine, Nginx

Resultados y Logros

Aprovisionamiento automatizado: Migracion completa de la arquitectura de la aplicacion de joyeria fina a la nube de AWS con un solo comando de Terraform.
Arquitectura de red corregida: Aislamiento total en subredes de 3 capas con asociacion local de NAT Gateways para evitar transferencia cruzada ineficiente de datos.
Separacion de responsabilidades: Reduccion de carga en el servidor Express moviendo la exportacion e importacion de catalogos a microservicios serverless bajo demanda.
Seguridad mejorada: Almacenamiento seguro en S3 con URLs presirmadas de acceso temporal y ejecucion de contenedores Fargate bajo el rol restrictivo expressjs en lugar del usuario administrador root.
Mensajeria robusta: Cola SQS con DLQ asociada y auto-rollback de reintentos para el envio asincrono de notificaciones.