Descripción del proyecto
TBF Cloud Infrastructure es una plataforma SaaS completa que demuestra cómo construir, desplegar y operar una aplicación web moderna en AWS con todas las mejores prácticas de seguridad, escalabilidad y automatización.
El proyecto incluye backend (Spring Boot 4), frontend (React 18 + Vite) y toda la infraestructura AWS en Terraform modular, con tres pipelines independientes de CI/CD.
Arquitectura de la plataforma
El tráfico de usuarios llega a CloudFront. Las peticiones al frontend se sirven desde S3 directamente. Las peticiones a la API (/api/*) se redirigen al ALB, que las distribuye entre los contenedores ECS Fargate ejecutando Spring Boot.
Los contenedores acceden a RDS PostgreSQL y a S3 para documentos. Los secretos (contraseña DB, JWT secret, credenciales email) se obtienen de AWS Secrets Manager en el arranque del contenedor.
Decisiones de diseño Dev vs Prod
Una decisión deliberada es que dev y prod tienen configuraciones de infraestructura diferentes:
Dev: ECS tasks en subnets públicas, sin NAT Gateway (ahorra ~$35/mes), RDS sin Multi-AZ.
Prod: ECS en subnets privadas, NAT Gateway, RDS Multi-AZ, deletion protection habilitada, HTTPS con ACM.
Esta separación permite desarrollar y testear en un entorno económico mientras prod mantiene todos los controles de seguridad y disponibilidad.
CI/CD con tres pipelines
backend.yml: Ejecuta tests Maven, construye imagen Docker, la sube a ECR y hace force-deploy del servicio ECS. Usa AWS OIDC para autenticación sin credenciales hardcodeadas.
frontend.yml: Build con Vite, sube artefactos a S3 y ejecuta invalidación de CloudFront para que los usuarios reciban la versión nueva inmediatamente.
terraform.yml: Valida y planea en PRs; aplica solo en push a main desde el workflow aprobado.
Gestión de secretos
En entornos desplegados, ningún secreto existe en variables de entorno del repositorio ni en archivos .env. Spring Boot obtiene todos los secretos de AWS Secrets Manager al arrancar, usando el IAM role del task de ECS.
Esto significa que rotar una contraseña no requiere redesplegar la aplicación, solo actualizar el secreto en Secrets Manager y reiniciar el task.
Lessons learned
La mayor complejidad fue el orden de creación de recursos en Terraform. El security group del ECS task necesita saber el ID del security group de RDS para la regla de egreso, pero RDS necesita el security group de ECS para su regla de ingreso. Esto crea dependencias circulares que Terraform resuelve con referencias explícitas entre módulos.
La segunda lección importante: los presigned URLs de S3 tienen tiempo de expiración. Para documentos que los usuarios acceden repetidamente, es mejor generar URLs nuevas en cada request en lugar de guardarlas en la base de datos.
Stack tecnológico
Puntos clave
- ECS Fargate sin gestión de servidores: escalado automático en producción
- CloudFront con OAC: frontend React servido globalmente desde S3
- RDS PostgreSQL 15 Multi-AZ con deletion protection en producción
- AWS Secrets Manager para todos los secretos en runtime (sin .env en prod)
- AWS OIDC para CI/CD sin credenciales de larga duración en GitHub
- 11 módulos Terraform: vpc, ecr, ecs_backend, rds, alb, cloudfront, s3_frontend, s3_documents, secrets_manager, nat, security_group
Repositorio
¿Algo similar para ti?
Puedo diseñar e implementar una arquitectura adaptada a tu proyecto.
HablemosComponentes del sistema
CloudFront + S3
CDN global serviendo el frontend React con OAC (Origin Access Control)
ALB → ECS Fargate
Load balancer redirige tráfico a contenedores Spring Boot en Fargate
RDS PostgreSQL 15
Base de datos en subnets privadas, Multi-AZ en producción
AWS Secrets Manager
Inyección de secretos en runtime sin exponer credenciales
S3 Documents
Bucket separado para documentos de usuario con presigned URLs
NAT Gateway (prod)
Dev usa subnets públicas para reducir costos; prod usa NAT privado