Serverless en AWS: lecciones de construir una plataforma SaaS desde cero

Cuando me uní a AppWhoop como consultor senior, el desafío era claro: construir desde cero una plataforma SaaS de economía colaborativa que soportara alta concurrencia, sin el costo de servidores dedicados siempre encendidos.

La respuesta fue arquitectura serverless en AWS. Pero como aprenderás, "serverless" no significa "sin problemas".

¿Por qué Serverless?

Para un SaaS en etapa inicial, los beneficios son claros:

Costo por uso: pagas solo cuando hay tráfico real
Escalado automático: AWS maneja los picos sin configuración manual
Menos DevOps: no gestionas servidores, parches ni actualizaciones de OS

Pero tiene tradeoffs importantes que debes conocer antes de comprometerte.

La Arquitectura que Elegimos

React.js (Vite) → CloudFront (CDN)
       ↓
API Gateway → Lambda Functions
       ↓
MariaDB (RDS en VPC privada)
S3 (archivos estáticos y uploads)
CloudWatch (logs y alertas)

Los 3 ambientes desde el inicio

Un error que veo frecuentemente es arrancar con solo un ambiente. Nosotros configuramos tres desde el día 1:

Development — branch develop, deploy automático en cada push
QA — branch staging, deploy manual con aprobación
Pre-production — branch main, espejo de producción para testing final

Esto nos salvó múltiples veces de bugs críticos que solo aparecen en datos reales.

Lección 1: El Cold Start de Lambda es Real

El problema más subestimado de Lambda: las cold starts. Cuando una función no ha sido invocada en ~15 minutos, el próximo request tarda 800ms-3s adicionales en "despertar" el contenedor.

Solución que implementamos:

// Provisioned Concurrency para rutas críticas de autenticación
// serverless.yml
functions:
  auth:
    handler: src/handlers/auth.handler
    provisionedConcurrency: 2  # Siempre 2 instancias "calientes"
    events:
      - http:
          path: /auth/{proxy+}
          method: any

Para rutas menos críticas (dashboards, reportes), aceptamos el cold start y educamos al equipo en expectativas de rendimiento.

Lección 2: RDS en VPC = Lambda con VPC = Cold Start Peor

Este fue nuestro error más costoso. Pusimos RDS (MariaDB) dentro de una VPC privada por seguridad — correcto. Pero Lambda también necesita estar en la VPC para conectarse. Y Lambda en VPC tiene cold starts de 8-10 segundos.

La solución: RDS Proxy

Lambda (fuera de VPC) → RDS Proxy (en VPC) → RDS MariaDB

RDS Proxy mantiene un pool de conexiones persistentes, elimina la necesidad de poner Lambda en VPC, y mejora los cold starts dramáticamente.

Costo adicional: ~$35/mes. Valió cada centavo.

Lección 3: Estructurar las Lambdas como Microservicios, no Monolito

El antipatrón más común: una Lambda gigante que maneja todo.

❌ handler.ts → maneja auth, usuarios, productos, pagos, reportes

Nosotros organizamos cada Lambda por dominio de negocio:

✅ 
handlers/
  auth/         → login, registro, refresh token
  users/        → CRUD de usuarios  
  listings/     → CRUD de listados de servicios
  payments/     → integración con procesador de pagos
  notifications/→ emails y push notifications

Beneficio: cada función escala independientemente. Si hay spike de registros, solo Lambda auth escala. El resto no se ve afectado.

Los Números Finales

Después de 3 meses en producción:

Latencia P99: < 200ms (excluyendo cold starts de funciones no-críticas)
Disponibilidad: 99.97%
Costo mensual: ~$180 (para volumen de 50k requests/día)
Equivalente en EC2: ~$450/mes para el mismo rendimiento con auto-scaling

¿Cuándo NO usar Serverless?

Sería deshonesto no mencionarlo. Serverless no es la respuesta correcta para:

Aplicaciones con conexiones WebSocket persistentes (usar EC2 + Socket.io)
Procesamiento de video/audio (Lambda tiene límite de 15 min y 10GB memoria)
Startups en etapa muy temprana que necesitan iterar rápido sin pensar en infra (usa Railway o Render)
Cargas de trabajo con latencia ultra-baja constante (gaming, trading en tiempo real)

Conclusión

Serverless en AWS nos permitió lanzar un producto robusto con un equipo pequeño y un costo predecible. La clave fue entender los tradeoffs desde el inicio y no tratar a Lambda como un servidor tradicional.

Si estás considerando esta arquitectura para tu próximo SaaS, el mayor consejo que puedo darte: configura tus 3 ambientes desde el día 1 y agrega RDS Proxy si usas base de datos relacional en VPC.

¿Tienes preguntas sobre la arquitectura? Contáctame aquí — me encanta hablar de sistemas distribuidos.

Uriel Arana es Senior Full Stack Developer y Consultor Tecnológico con experiencia en arquitecturas serverless en AWS. Actualmente disponible para proyectos de consultoría.