SaaS multi-tenant serverless sur AWS : une architecture qui scale par tenant

La question qui définit ton architecture

Je vais être direct : la décision qui façonne un SaaS multi-tenant, c'est la façon dont tu isoles les tenants. Fais-le bien et tu sers des milliers de clients sur une infrastructure partagée avec un modèle de coûts propre. Fais-le mal et soit tu fais fuiter les données d'un client chez un autre, ce qui met fin à l'entreprise, soit tu montes une infrastructure dédiée par tenant, ce qui la met en faillite.

La réponse n'est pas « choisis un modèle d'isolation ». C'est d'appliquer l'isolation à chaque couche, pour qu'aucune erreur isolée n'expose de données entre tenants. C'est la défense en profondeur appliquée à la multi-tenancy, et c'est la différence entre une plateforme à laquelle tu peux confier des données d'entreprise et une démo à laquelle tu ne peux pas.

L'isolation multi-tenant n'est pas une fonctionnalité que tu ajoutes. C'est une propriété que tu imposes à chaque couche : la base de données, l'index de recherche, l'API, les agents et le dashboard. Une seule couche ne suffit pas.

Nous faisons tourner cette architecture en production dans notre propre plateforme Exfinity, un SaaS multi-tenant sur AWS qui sert des tenants isolés depuis une infrastructure partagée dans une région UE. Ce guide, c'est le design réel. Pour l'alternative par orchestration de conteneurs, regarde notre guide Kubernetes pour plateformes SaaS, et tout ceci est au cœur de notre travail cloud.

Qui se soucie de quoi

Serverless ou conteneurs : choisis par service

Le serverless n'est pas tout ou rien. La bonne architecture utilise les deux, choisis par workload.

Les functions-as-a-service conviennent au travail irrégulier, événementiel et de courte durée : un endpoint API, un consommateur de queue, un job planifié. Tu paies à l'invocation et tu redescends à zéro. Les services de longue durée ou avec état, une API de recherche qui garde des index chauds, un runtime AI qui gère l'état d'agents, conviennent aux conteneurs sur du compute managé, où tu gardes les process chauds et tu contrôles le runtime.

Exfinity fait tourner son API et ses flux de checkout en fonctions, et sa recherche, son runtime AI, son ingestion et son dashboard en conteneurs sur du compute managé, chacun scalant indépendamment. La leçon : ne force pas un seul modèle sur tout. Notre guide platform engineering couvre ce compromis en profondeur.

Les six couches d'isolation des tenants

C'est le cœur de tout le guide. L'isolation est imposée à chaque couche que traverse une requête.

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 API. L'identité du tenant vient des claims vérifiés du token, pas d'un paramètre de requête qu'un appelant pourrait forger. Un tenant id dans l'URL venant d'un non-admin est ignoré silencieusement. C'est la première porte, et celle que les gens ratent le plus souvent.

Base de données. Chaque requête inclut le tenant comme clé de partition. Il n'existe aucun chemin de code qui lit une table sans scope tenant. C'est imposé dans la couche d'accès aux données, pas laissé à la mémoire de chaque appelant.

Index de recherche. Chaque recherche porte un filtre tenant, donc la requête d'un tenant ne peut jamais retourner les documents d'un autre, même s'ils partagent un index.

Agents et mémoire. Chaque conversation est scopée à un seul tenant, et le rappel de mémoire des agents impose ce scope, donc un agent qui sert le tenant A ne peut pas rappeler les threads du tenant B. On couvre ça dans notre guide sur la mémoire des agents.

Couche d'outils. Chaque outil qu'un agent peut appeler vérifie le scope tenant avant de s'exécuter, en portant le tenant, le canal et les ressources autorisées dans son contexte d'exécution.

Dashboard. Un accès cross-tenant retourne un not-found plutôt qu'un forbidden, pour que la réponse ne confirme même pas que la ressource d'un autre tenant existe.

Six couches, et un check raté sur l'une d'elles n'expose pas de données, parce que les autres tiennent encore. C'est tout l'intérêt de la défense en profondeur. Notre guide de design de systèmes multi-tenant va plus loin sur les patterns.

Les briques AWS

Voici comment les pièces se mappent sur des services concrets, tirées d'un déploiement en production.

Le pattern à remarquer : les data stores vivent dans des sous-réseaux privés sans accès public, le compute les atteint via le VPC, et seuls le load balancer et le CDN font face à internet. L'enrichissement des tokens à la couche auth, c'est là que l'identité du tenant est estampillée dans chaque requête, pour que les services en aval puissent lui faire confiance. Notre guide infrastructure as code couvre le provisioning reproductible de tout ça.

Limites par tenant : empêcher un tenant de couler le navire

Une infrastructure partagée, ça veut dire que la charge folle d'un tenant ou sa clé qui a fuité devient le problème de tout le monde, sauf si tu la bornes. Deux contrôles comptent.

Les limites de débit par tenant plafonnent le volume de requêtes par tenant et par type de credential, pour qu'un tenant chaud ne puisse pas affamer les autres. Les plafonds de coûts par tenant posent un plafond mensuel dur sur les opérations coûteuses, les appels de modèles surtout, comme garde-fou de rayon d'impact contre une clé qui fuit ou une boucle d'agent qui s'emballe. Dans Exfinity, ces plafonds sont fixés bien au-dessus de l'usage attendu d'un tier, donc ce sont des filets de sécurité, pas un throttle de facturation, et en toucher un retourne une erreur claire pour le reste du mois plutôt que de surfacturer en silence.

Sans ça, ton client le plus négligent fixe le plancher de fiabilité pour tout le monde. Notre guide sur le design de systèmes pour la panne couvre cette posture défensive.

Le backbone événementiel : découpler la plateforme

Une plateforme multi-tenant qui fait tout dans le chemin de la requête est fragile, parce qu'une seule dépendance lente bloque l'utilisateur. Les services qui scalent bien déplacent le travail hors du chemin de la requête vers un backbone asynchrone, pour que l'utilisateur reçoive une réponse rapide et que le gros du travail se fasse en dehors.

Deux mécanismes portent ça. Les queues ordonnées gèrent le travail qui doit arriver exactement une fois et dans l'ordre, une réservation qui devient une réservation fournisseur, avec une dead-letter queue qui attrape tout ce qui échoue pour que rien ne se perde en silence. Un service de planification déclenche les jobs récurrents, checks de fraîcheur, nettoyage, archivage, sans serveur cron à surveiller.

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

Exfinity fait passer les réservations et la génération de documents par des queues ordonnées avec dead-letter queues, et pilote ses plannings de crawl et de maintenance depuis un bus d'événements. Une plateforme saine garde ces dead-letter queues vides, donc une queue non vide, c'est une alerte. C'est la même discipline de fiabilité que notre guide d'intégration d'entreprise, appliquée à l'intérieur d'une seule plateforme, et le pattern général est dans notre guide d'architecture événementielle.

Résidence des données : où elles vivent physiquement

Pour les clients européens, ce n'est pas une préférence, c'est une exigence. Si ton contrat ou le GDPR dit que les données restent dans l'UE, ton architecture doit l'imposer, pas juste l'affirmer.

Ça veut dire choisir une région délibérément et garder le stockage et le traitement à l'intérieur. Exfinity tourne dans une région UE, avec toutes les données opérationnelles, la recherche et le cache dans la région, et une liste documentée de sous-traitants avec ce que chacun touche. Les fournisseurs de modèles hors UE sont traités comme des sous-traitants avec des clauses de traitement des données, et les données personnelles peuvent en être tenues complètement à l'écart par tokenisation, comme couvert dans notre guide RAG sans exposition de PII. Notre guide GDPR et AI et notre page confiance couvrent le cadrage conformité.

Infrastructure as code : reproductible ou rien

Une plateforme multi-tenant que tu ne peux pas reconstruire depuis le code est un passif. Tout, le réseau, le compute, les data stores, l'IAM, est défini comme du code et appliqué via une pipeline, pour que les environnements soient reproductibles et que les changements soient relus.

La discipline qui compte : un state séparé par environnement, des rôles au moindre privilège pour la pipeline elle-même, et aucun changement manuel en console qui dérive du code. Exfinity provisionne son stack avec Terraform et un wrapper pour la configuration par service et le state distant, en promouvant à travers développement, staging et production avec approbation manuelle sur la production. Notre guide infrastructure as code couvre les pratiques qui gardent tout ça maintenable.

Par où commencer

1. Décide l'isolation d'abord. Impose le scope tenant à chaque couche avant de construire des features.
2. Sépare le compute par workload. Fonctions pour l'irrégulier et l'événementiel, conteneurs pour le chaud et le stateful.
3. Estampille l'identité du tenant à l'auth. Mets-la dans des claims de token vérifiés, ne fais jamais confiance au client.
4. Ajoute les limites par tenant tôt. Limites de débit et plafonds de coûts avant d'accueillir de la vraie charge.
5. Codifie tout. Infrastructure as code dès le premier jour, pas rétrofittée.

C'est étagé, et ça colle à la livraison par phases de notre méthodologie. Nos équipes cloud et consulting conçoivent et construisent ces plateformes. Commence par contact ou demande un devis.

Comment ça tourne mal, classiquement

1. L'isolation sur une seule couche. Un seul check raté fait fuiter des données. Impose le scope tenant partout.
2. Faire confiance au client pour l'identité du tenant. Un tenant id dans l'URL est forgeable. Utilise des claims de token vérifiés.
3. Pas de limites par tenant. La charge ou la clé fuitée d'un seul tenant coule tout le monde. Borne-la.
4. Des data stores publics. Les bases de données et la recherche doivent vivre dans des sous-réseaux privés, joignables uniquement via le VPC.
5. L'infrastructure manuelle. Les changements en console dérivent et ne peuvent pas être reconstruits. Codifie tout.
6. Ignorer la résidence jusqu'à ce qu'un contrat la demande. Rétrofitter des contraintes de région est douloureux. Choisis délibérément dès le départ.

Qui construit ça

Oronts est une société de logiciels dirigée par son fondateur, basée à Munich. Refaat Al Ktifan, notre fondateur et architecte solution, dirige une équipe senior couvrant backend, cloud et plateforme. L'architecture de ce guide est le design réel derrière Exfinity, un SaaS multi-tenant que nous faisons tourner sur AWS dans une région UE. Nous concevons le modèle d'isolation, construisons les couches serverless et conteneurs, codifions l'infrastructure et te remettons une plateforme que tu peux opérer et scaler. Regarde nos pages services et solutions.

À retenir

• La décision qui définit un SaaS multi-tenant, c'est l'isolation, imposée à chaque couche, pas à une seule.
• Sépare le compute par workload : fonctions pour l'irrégulier et l'événementiel, conteneurs pour le chaud et le stateful.
• Estampille l'identité du tenant à la couche auth depuis des claims vérifiés, et ne fais jamais confiance au client pour ça.
• Borne chaque tenant avec des limites de débit et des plafonds de coûts pour qu'aucun ne puisse couler la plateforme.
• Choisis ta région délibérément pour la résidence des données, et codifie toute l'infrastructure.

La multi-tenancy bien faite est invisible pour le client et évidente dans l'architecture. Chaque couche sait à qui appartiennent les données qu'elle tient, et aucune erreur isolée ne peut franchir cette ligne.

Tu construis ou tu scales une plateforme multi-tenant sur AWS ? Parle-nous de tes besoins d'isolation et de résidence. Commence par contact ou demande un devis cadré.