SaaS multi-tenant serverless en AWS: arquitectura que escala por tenant

La pregunta que define tu arquitectura

Déjame ser directo: la decisión que da forma a un SaaS multi-tenant es cómo aíslas a los tenants. Hazlo bien y escalas a miles de clientes sobre infraestructura compartida con un modelo de costos limpio. Hazlo mal y o filtras los datos de un cliente a otro, lo que acaba con la empresa, o levantas infraestructura dedicada por tenant, lo que la lleva a la quiebra.

La respuesta no es «elige un modelo de aislamiento». Es aplicar aislamiento en cada capa, para que ningún error aislado exponga datos entre tenants. Esto es defensa en profundidad aplicada al multi-tenant, y es la diferencia entre una plataforma a la que puedes confiarle datos empresariales y una demo a la que no.

El aislamiento multi-tenant no es una funcionalidad que agregas. Es una propiedad que impones en cada capa: la base de datos, el índice de búsqueda, la API, los agentes y el dashboard. Una sola capa no basta.

Corremos esta arquitectura en producción en nuestra propia plataforma Exfinity, un SaaS multi-tenant en AWS que sirve tenants aislados desde infraestructura compartida en una región de la UE. Esta guía es el diseño real. Para la alternativa con orquestación de contenedores, mira nuestra guía de Kubernetes para plataformas SaaS, y esto es trabajo central de cloud.

A quién le importa qué

Serverless versus contenedores: elige por servicio

Serverless no es todo o nada. La arquitectura correcta usa ambos, elegidos por carga de trabajo.

Las functions-as-a-service encajan con trabajo con picos, dirigido por eventos y de corta duración: un endpoint de API, un consumidor de colas, un job programado. Pagas por invocación y escalas a cero. Los servicios de larga duración o con estado, una API de búsqueda que mantiene índices calientes, un runtime de AI que gestiona estado de agentes, encajan con contenedores sobre cómputo gestionado, donde mantienes los procesos calientes y controlas el runtime.

Exfinity corre su API y sus flujos de checkout como funciones, y su búsqueda, runtime de AI, ingesta y dashboard como contenedores sobre cómputo gestionado, cada uno escalando de forma independiente. La lección: no fuerces un solo modelo para todo. Nuestra guía de platform engineering cubre este trade-off a fondo.

Las seis capas de aislamiento de tenants

Este es el núcleo de toda la guía. El aislamiento se impone en cada capa que toca una request.

Request with tenant identity
   │
   ▼
[1] API middleware   ── tenant id from the token, never the query string
[2] Database         ── tenant id as partition key on every query
[3] Search index     ── tenant filter on every search
[4] Agents / AI       ── conversation and memory scoped per tenant
[5] Tool layer       ── every tool checks scope before it runs
[6] Dashboard        ── cross-tenant access returns not-found, not forbidden

Middleware de API. La identidad del tenant viene de claims verificados del token, no de un parámetro de query que quien llama podría falsificar. Un tenant id en la URL desde un no-admin se ignora en silencio. Esta es la primera puerta, y la que más gente hace mal.

Base de datos. Cada query incluye al tenant como clave de partición. No hay ninguna ruta de código que lea una tabla sin scope de tenant. Esto se impone en la capa de acceso a datos, no se deja a la memoria de cada llamador.

Índice de búsqueda. Cada búsqueda lleva un filtro de tenant, así que la query de un tenant nunca puede devolver los documentos de otro, aunque compartan un índice.

Agentes y memoria. Cada conversación está acotada a un solo tenant, y el recuerdo de memoria de los agentes impone ese scope, así que un agente que sirve al tenant A no puede recuperar los hilos del tenant B. Lo cubrimos en nuestra guía de memoria de agentes.

Capa de herramientas. Cada herramienta que un agente puede llamar comprueba el scope del tenant antes de ejecutarse, llevando el tenant, el canal y los recursos permitidos en su contexto de ejecución.

Dashboard. El acceso cross-tenant devuelve un not-found en lugar de un forbidden, para que la respuesta ni siquiera confirme que el recurso de otro tenant existe.

Seis capas, y un check olvidado en una de ellas no expone datos, porque las demás siguen aguantando. Ese es todo el punto de la defensa en profundidad. Nuestra guía de diseño de sistemas multi-tenant profundiza en los patrones.

Los bloques de construcción de AWS

Así es como las piezas se mapean a servicios concretos, sacadas de un despliegue en producción.

El patrón a notar: los data stores viven en subredes privadas sin acceso público, el cómputo los alcanza a través de la VPC, y solo el load balancer y el CDN dan la cara a internet. El enriquecimiento de tokens en la capa de auth es donde se estampa la identidad del tenant en cada request, para que los servicios aguas abajo puedan confiar en ella. Nuestra guía de infraestructura como código cubre cómo aprovisionar todo esto de forma reproducible.

Límites por tenant: evitar que un tenant hunda el barco

Infraestructura compartida significa que la carga desbocada de un tenant o su clave filtrada es problema de todos, a menos que la acotes. Dos controles importan.

Los límites de tasa por tenant acotan el volumen de requests por tenant y por tipo de credencial, para que un tenant caliente no pueda dejar sin recursos al resto. Los topes de costo por tenant ponen un techo mensual duro a las operaciones caras, las llamadas a modelos sobre todo, como freno del radio de impacto contra una clave filtrada o un loop de agente desbocado. En Exfinity estos topes se fijan bien por encima del uso esperado de un tier, así que son una red de seguridad, no un freno de facturación, y alcanzar uno devuelve un error claro durante el resto del mes en lugar de cobrar de más en silencio.

Sin esto, tu cliente más descuidado fija el piso de fiabilidad para todos. Nuestra guía de diseñar sistemas para el fallo cubre esta postura defensiva.

El backbone de eventos: desacoplar la plataforma

Una plataforma multi-tenant que hace todo en el camino de la request es frágil, porque una dependencia lenta detiene al usuario. Los servicios que escalan bien mueven el trabajo fuera del camino de la request hacia un backbone asíncrono, para que el usuario reciba una respuesta rápida y el trabajo pesado ocurra fuera de banda.

Dos mecanismos cargan con esto. Las colas ordenadas manejan el trabajo que debe ocurrir exactamente una vez y en secuencia, una reserva que se convierte en una reserva con el proveedor, con una dead-letter queue que atrapa cualquier cosa que falle para que nada se pierda en silencio. Un servicio de programación dispara los jobs recurrentes, chequeos de frescura, limpieza, archivado, sin un servidor de cron que cuidar.

User action ──▶ fast response
     │
     └──▶ ordered queue ──▶ worker ──(fail)──▶ dead-letter queue
                                                      │
                                            alert, inspect, replay

Exfinity pasa las reservas y la generación de documentos por colas ordenadas con dead-letter queues, y dirige sus calendarios de crawl y mantenimiento desde un bus de eventos. Una plataforma sana mantiene esas dead-letter queues vacías, así que una que no está vacía es una alerta. Es la misma disciplina de fiabilidad que nuestra guía de integración empresarial, aplicada dentro de una sola plataforma, y el patrón general está en nuestra guía de arquitectura dirigida por eventos.

Residencia de datos: dónde viven físicamente

Para clientes europeos esto no es una preferencia, es un requisito. Si tu contrato o el GDPR dice que los datos se quedan en la UE, tu arquitectura tiene que imponerlo, no solo afirmarlo.

Eso significa elegir una región deliberadamente y mantener el almacenamiento y el procesamiento dentro de ella. Exfinity corre en una región de la UE, con todos los datos operacionales, la búsqueda y el caché en la región, y una lista documentada de subencargados y qué toca cada uno. Los proveedores de modelos fuera de la UE se manejan como subencargados con términos de tratamiento de datos, y los datos personales pueden mantenerse completamente fuera de ellos con tokenización, como cubrimos en nuestra guía de RAG seguro para PII. Nuestra guía de GDPR y AI y la página de confianza cubren el encuadre de cumplimiento.

Infraestructura como código: reproducible o nada

Una plataforma multi-tenant que no puedes reconstruir desde código es un pasivo. Todo, redes, cómputo, data stores, IAM, se define como código y se aplica a través de un pipeline, para que los entornos sean reproducibles y los cambios pasen por revisión.

La disciplina que importa: estado separado por entorno, roles de mínimo privilegio para el propio pipeline, y cero cambios manuales en la consola que deriven del código. Exfinity aprovisiona su stack con Terraform y un wrapper para configuración por servicio y estado remoto, promoviendo a través de desarrollo, staging y producción con aprobación manual en producción. Nuestra guía de infraestructura como código cubre las prácticas que mantienen esto mantenible.

Cómo empezar

1. Decide el aislamiento primero. Impón el scope de tenant en cada capa antes de construir funcionalidades.
2. Divide el cómputo por carga de trabajo. Funciones para lo que tiene picos y es dirigido por eventos, contenedores para lo caliente y con estado.
3. Estampa la identidad del tenant en el auth. Ponla en claims de token verificados, nunca confíes en el cliente.
4. Agrega límites por tenant temprano. Límites de tasa y topes de costo antes de recibir carga real.
5. Codifica todo. Infraestructura como código desde el primer día, no como retrofit.

Esto va por etapas, y encaja con la entrega por fases de nuestra metodología. Nuestros equipos de cloud y consultoría diseñan y construyen estas plataformas. Empieza en contacto o pide una cotización.

Las formas comunes en que esto sale mal

1. Aislamiento en una sola capa. Un solo check olvidado filtra datos. Impón el scope de tenant en todas partes.
2. Confiar en el cliente para la identidad del tenant. Un tenant id en la URL es falsificable. Usa claims de token verificados.
3. Sin límites por tenant. La carga o la clave filtrada de un tenant hunde a todos. Acótala.
4. Data stores públicos. Las bases de datos y la búsqueda deben vivir en subredes privadas, alcanzables solo a través de la VPC.
5. Infraestructura manual. Los cambios en la consola derivan y no se pueden reconstruir. Codifica todo.
6. Ignorar la residencia hasta que un contrato la pida. Retroajustar restricciones de región es doloroso. Elige deliberadamente desde el inicio.

Quién construye esto

Oronts es una empresa de software liderada por su fundador, con sede en Múnich. Refaat Al Ktifan, nuestro fundador y arquitecto de soluciones, lidera un equipo senior en backend, cloud y plataforma. La arquitectura de esta guía es el diseño real detrás de Exfinity, un SaaS multi-tenant que corremos en AWS en una región de la UE. Diseñamos el modelo de aislamiento, construimos las capas serverless y de contenedores, codificamos la infraestructura y te entregamos una plataforma que puedes operar y escalar. Mira nuestras páginas de servicios y soluciones.

Conclusiones

• La decisión que define un SaaS multi-tenant es el aislamiento, impuesto en cada capa, no solo en una.
• Divide el cómputo por carga de trabajo: funciones para lo que tiene picos y es dirigido por eventos, contenedores para lo caliente y con estado.
• Estampa la identidad del tenant en la capa de auth desde claims verificados, y nunca confíes en el cliente para eso.
• Acota a cada tenant con límites de tasa y topes de costo para que ninguno pueda hundir la plataforma.
• Elige tu región deliberadamente por residencia de datos, y codifica toda la infraestructura.

El multi-tenant bien hecho es invisible para el cliente y obvio en la arquitectura. Cada capa sabe de quién son los datos que sostiene, y ningún error aislado puede cruzar esa línea.

¿Construyendo o escalando una plataforma multi-tenant en AWS? Cuéntanos tus necesidades de aislamiento y residencia. Empieza en contacto o pide una cotización acotada.