Construyendo Kataru en AWS por Menos de €300/Mes: Nuestro Stack de Infraestructura

Uno de los compromisos que asumimos al iniciar Kataru fue construir en público donde pudiéramos. Eso significa mostrar no solo las decisiones de producto, sino también las decisiones de ingeniería — incluyendo las partes que involucran dinero.

Esta es una instantánea de nuestro stack de infraestructura a partir de mayo de 2026. Estamos en fase alfa, con una base de usuarios pequeña y sin financiación externa, así que mantener los costos predecibles es importante.

El stack

Compute: ECS Fargate (backend FastAPI, containerizado). Sin EC2 que administrar, sin instancias inactivas. Pagamos por segundo de tarea de uso real de CPU y memoria.

Base de datos: RDS Postgres (db.t4g.micro en alfa, con extensión pgvector para búsqueda de embeddings). Single-AZ por ahora — no es de grado producción para un producto escalado, pero es apropiado para alfa.

Almacenamiento: S3 con encriptación KMS para documentos de usuario. Reglas de ciclo de vida archivan cualquier cosa más antigua que 90 días.

CDN / hosting estático: CloudFront + S3 para el sitio de marketing. Costo de servidor cero para la página de inicio.

Auth: AWS Cognito para gestión de usuarios e emisión de tokens. El nivel gratuito cubre 50.000 MAU, a los que no llegaremos por mucho tiempo.

Qué cuesta

A partir del lanzamiento alfa (usuarios activos diarios de un dígito):

Servicio	Estimación mensual
ECS Fargate (1 tarea, 0.25 vCPU / 512MB)	~€6
RDS db.t4g.micro	~€12
CloudFront + S3 (marketing)	~€2
Cognito	€0 (nivel gratuito)
Secrets Manager, KMS	~€2
Total	~€22

Con tráfico de usuario real, el primer elemento de línea costoso será tareas de Fargate (escalaremos a más de una) y RDS (necesitaremos Multi-AZ). Con 1.000 DAU, estimaríamos €80–120/mes — aún muy por debajo del objetivo.

En qué comprometimos

Elegimos Terraform para toda la infraestructura, lo que añadió tiempo inicial pero nos da auditabilidad completa y reproducibilidad. Cada recurso se define en código, se versiona en git, y se puede desplegar desde cero en menos de 15 minutos.

Omitimos servicios administrados donde la relación costo-valor era pobre a esta escala — sin ElasticSearch, sin SQS, sin EventBridge para flujos MVP. Usamos Postgres para mucho de lo que esos servicios harían, lo que tiene sentido para un equipo de dos personas.

Qué viene después

El siguiente post de infraestructura cubrirá nuestro pipeline CI/CD — GitHub Actions desplegando en ECS, con actualizaciones rolling sin tiempo de inactividad y health checks canary.

Si estás construyendo algo similar y quieres comparar notas, contáctame en LinkedIn.