De Raspberry Pi a AWS: migrar un SaaS real sin romper el presupuesto

---

title: De Raspberry Pi a AWS: migrar un SaaS real sin romper el presupuesto category: Migración cloud keywords:

• AWS
• ECS
• RDS
• Next.js
• Cloud Migration
• DevOps

---

De la Raspberry Pi a la Nube: Lecciones Inesperadas al Migrar un SaaS Real a AWS

Dar el salto de un servidor casero a la nube profesional es un rito de pasaje para cualquier desarrollador independiente o startup. Lo que comienza en una Raspberry Pi bajo un escritorio, alimentado por hardware limitado y mucha voluntad, tarde o tarde exige la robustez de un centro de datos. Sin embargo, este camino no se trata solo de mover contenedores; está lleno de fricciones técnicas que ningún tutorial de "Hola Mundo" te advierte.

Este es el caso de TEA Connect, un proyecto con un propósito social crítico enfocado en la neurodiversidad. La misión era clara: profesionalizar la infraestructura para manejar datos sensibles de salud mental, garantizando estabilidad sin romper un presupuesto mensual de 30 USD. En este proceso, enfrentamos errores sutiles de integración y decisiones arquitectónicas que ofrecen lecciones invaluables para cualquier ingeniero con enfoque pragmático.

Lección 1: El "Silencioso" Enemigo de los Health Checks (Next.js 15.5.12 y el Error 307)

Uno de los hallazgos más frustrantes durante la migración fue la interacción entre el middleware de internacionalización (i18n) de Next.js 15.5.12 y el Application Load Balancer (ALB) de AWS. En una arquitectura local, un redireccionamiento suele pasar desapercibido, pero en AWS es la diferencia entre una aplicación funcional y una marcada como "muerta".

El ALB consulta periódicamente una ruta de salud (en nuestro caso, /health) para verificar que el contenedor responde. Sin embargo, el middleware de Next.js interceptaba esta ruta y, al no detectar un idioma preferido, aplicaba un fallback automático, redirigiendo la petición a /es/health. El resultado para el balanceador era un código de estado HTTP 307 (Temporary Redirect).

routehealth ... event=middleware.redirect ... reason=localefallback ... result=307

Para el ALB, cualquier código fuera del rango 200-299 es un fracaso (Target.ResponseCodeMismatch). Esto provocaba un ciclo infinito de reinicios. La solución no fue relajar las reglas del balanceador, sino desacoplar la infraestructura de la lógica de negocio creando un archivo app/health/route.ts que devuelve un NextResponse.json directo, excluyéndolo explícitamente del middleware para asegurar un 200 OK neutro.

Además, aprendimos que la red en la nube tiene matices geográficos. Experimentamos el error Target.NotInUse porque una de nuestras tareas de ECS se lanzó en una subred de la zona de disponibilidad us-east-2c, la cual no estaba habilitada en la configuración inicial del Load Balancer. En AWS, si tus subredes y tu balanceador no están perfectamente alineados, tu aplicación será invisible aunque el contenedor esté "Ready".

Lección 2: La Paradoja del Costo vs. Simplicidad ($30 USD al mes)

Migrar una arquitectura que incluye PostgreSQL, Redis, MinIO y Next.js con un presupuesto de 30 USD exige una ingeniería de costos agresiva. La tentación de usar servicios "totalmente gestionados" como ECS Fargate puede ser arriesgada para proyectos iniciales debido a sus costos base.

Nuestra estrategia consistió en un "replatform" pragmático utilizando Amazon ECS sobre instancias EC2 pequeñas. La clave fue el análisis de consumo real frente a los límites teóricos. Mientras que en la Raspberry Pi definimos límites preventivos de 1.5 GB de RAM para la app y 768 MB para la base de datos, los logs de CloudWatch revelaron que el consumo real era de apenas 136 MB y 29 MB respectivamente.

"Prioridad 1: Costo, 2: Seguridad, 3: Simplicidad"

Esta jerarquía nos permitió maximizar el AWS Free Tier. Al ver el bajo consumo, confirmamos que una instancia Single-AZ de Amazon RDS para PostgreSQL 16.2 (con sus 20 GB de almacenamiento gratuito) era más que suficiente para nuestra base de datos actual de menos de 5 GB. El pragmatismo aquí fue no pagar por una escalabilidad que los datos aún no exigían.

Lección 3: Seguridad "Append-only" y Aislamiento de Datos Sensibles

Dado que TEA Connect maneja reportes clínicos y evidencia escolar, la seguridad se diseñó con una mentalidad HIPAA-ready. Una de las defensas más robustas que trasladamos de la Raspberry Pi y fortalecimos en AWS fue el uso de la tabla access_audit_logs.

Esta tabla es estrictamente append-only (solo adición) a nivel de base de datos. Cualquier acceso o modificación de datos sensibles genera un registro inmutable. Al migrar a AWS, complementamos esto con dos pilares:

1. Aislamiento de Inquilinos: Implementamos filtros transaccionales por organization_id para garantizar que un usuario jamás acceda a datos de otra organización.
2. Transición a Amazon S3: Sustituimos MinIO por S3 para el almacenamiento de archivos clínicos. Esto eliminó la carga operativa de gestionar parches de seguridad y backups de objetos, ganando cifrado en reposo y durabilidad nativa.

Lección 4: Docker como el "Pasaporte Informativo" y la Fricción del Build

La migración fue posible porque la arquitectura ya estaba containerizada. Docker actuó como el pasaporte que permitió mover el stack desde una arquitectura ARM64 en la Raspberry Pi hacia la infraestructura en Ohio (us-east-2).

Sin embargo, el "mundo real" del CI/CD presentó retos de tiempo. Usando Jenkins y docker buildx para asegurar la compatibilidad multi-arquitectura, nos enfrentamos a un timeout de construcción de 25 minutos. Esta es la cara oculta de la nube: los pipelines de construcción consumen tiempo y recursos que deben ser optimizados.

Migrar a servicios gestionados como RDS también resolvió un riesgo crítico de nuestra configuración anterior: el uso de volúmenes anónimos en Docker. En la Raspberry, un comando accidental como docker-compose down -v podría haber borrado datos vitales. En AWS, la persistencia está desacoplada del ciclo de vida del contenedor, brindando una paz mental que el hardware casero simplemente no puede ofrecer.

Conclusión y Reflexión Final

La arquitectura final de TEA Connect en AWS presenta un flujo limpio: el tráfico es validado por el ALB, procesado por contenedores saludables en ECS y persistido en una base de datos gestionada en RDS. Hemos pasado de la incertidumbre de un servidor bajo un escritorio a una infraestructura con observabilidad total a través de CloudWatch.

Migrar no es solo "cambiar de computadora"; es la oportunidad de profesionalizar la estabilidad de un proyecto con impacto social. Al final del día, cabe preguntarse: ¿Tu infraestructura actual está impulsando el crecimiento de tu aplicación o es un cuello de botella que bloquea su estabilidad? La nube no es solo "las computadoras de otros", es el estándar necesario para operar con la seriedad que tus usuarios merecen.