S3 pour tout ce qui peut être stocké et lu comme un objet entier, EFS quand plusieurs fonctions ou conteneurs doivent partager le même système de fichiers POSIX, EBS quand une seule instance EC2 a besoin d'un disque persistant rapide. Dans une stack serverless Node.js, S3 est le choix par défaut, les deux autres sont des exceptions à justifier. Le /tmp éphémère de Lambda couvre l'espace de travail intermédiaire. Voici comment nous traçons ces frontières sur des systèmes réels.
Objet, fichier ou bloc : qu'est-ce qui change vraiment ?
S3 stocke des objets derrière une API HTTP : on écrit et on lit des blobs entiers, sans arborescence, sans descripteurs de fichiers, sans mise à jour partielle. EFS est un système de fichiers partagé à sémantique POSIX : chemins, permissions, lecteurs et écrivains concurrents. EBS est un périphérique bloc brut, un disque attaché à une seule instance EC2.
Tout le reste découle du modèle d'accès. S3 monte en charge sans planification de capacité mais ne se monte pas comme un disque (Mountpoint brouille la frontière, avec des réserves). Un système de fichiers partagé doit coordonner ses écrivains : EFS échange un peu de latence contre le partage. Un périphérique bloc est rapide parce qu'une seule machine le possède.
Quand S3 est-il le bon choix par défaut ?
Dès que la donnée est écrite une fois puis lue en entier : uploads, images, exports, logs, sauvegardes, assets statiques, fichiers analytiques. S3 ne demande aucune planification de capacité, peut déclencher une fonction Lambda à chaque écriture, et les règles de cycle de vie déplacent automatiquement les objets froids vers des classes de stockage moins chères.
La forme de coût convient au serverless : au Go stocké plus à la requête, sans rien provisionner à l'avance (paliers actuels sur la page de tarification S3). Les URL présignées font transiter uploads et téléchargements directement par le navigateur, en gardant les gros contenus hors de vos fonctions. Quand la latence objet compte vraiment, S3 Express One Zone propose une classe mono-AZ plus rapide, rarement nécessaire. Notre règle : tout workload modélisable en objets et événements va sur S3 jusqu'à preuve du contraire.
Quand EFS mérite-t-il sa place ?
Quand plusieurs nœuds de calcul ont besoin d'un accès en lecture-écriture aux mêmes fichiers via des appels filesystem ordinaires. Le cas serverless classique : de gros modèles ML ou des caches partagés montés dans Lambda ou Fargate, lus avec le module fs standard au lieu d'être téléchargés depuis S3 à chaque cold start.
// S3 : un appel HTTP via le SDK, aucun système de fichiers
const { Body } = await s3.send(
new GetObjectCommand({ Bucket: "models", Key: "v3/weights.bin" })
);
// EFS monté sur Lambda : une simple lecture POSIX sur le point de montage
const weights = await fs.readFile("/mnt/models/v3/weights.bin");Un montage EFS impose une fonction dans un VPC et un passage par un access point : du câblage réel à maintenir. La latence de lecture se situe typiquement dans les quelques millisecondes ; le débit se choisit par mode (élastique, provisionné, burst). Forme de coût : au Go réellement stocké plus des frais de débit (détails sur la page de tarification EFS). Un système partagé peu sollicité reste modeste ; un streaming intensif mérite un calcul préalable.
Vos fonctions Lambda ont-elles vraiment besoin de ce montage EFS ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Où EBS se situe-t-il dans une architecture serverless ?
Pas dans vos fonctions : les volumes EBS s'attachent à des instances EC2, et Lambda ne peut pas en monter un. EBS est le disque sous les bases de données autogérées, les volumes de démarrage et tout workload mono-machine qui exige des E/S bloc sous la milliseconde avec des IOPS prévisibles.
Sa forme de coût est l'inverse de S3 : chaque Go provisionné se paie, et sur gp3 chaque IOPS ou débit supplémentaire, utilisés ou non (voir la page de tarification EBS). Le partage se résume à un volume pour une instance ; le multi-attach io2 existe dans une même zone de disponibilité, mais reste un outil de niche. Les snapshots ramènent ensuite ces données vers le monde objet. En serverless-first, EBS n'apparaît que là où vous avez délibérément gardé EC2 : base autohébergée, service legacy avec état.
Et le /tmp de Lambda ?
Chaque environnement d'exécution Lambda embarque un /tmp éphémère, configurable de 512 Mo à 10 Go, et c'est souvent la réponse honnête : espace de travail pour décompresser des archives, redimensionner des images ou préparer un fichier le temps d'une invocation, sans aucun service externe.
Son contenu peut survivre entre deux invocations chaudes du même environnement, ce qui en fait un cache utile, mais rien ne le garantit : tout y est jetable. L'état durable va dans S3 ou DynamoDB. Si vous butez régulièrement sur les limites de /tmp, la question dépasse le stockage ; notre comparaison Lambda ou serveurs couvre les cas où le modèle de calcul lui-même doit changer.
S3 vs EFS vs EBS en un coup d'œil
Lisez d'abord la dernière ligne. Si un workload n'exige pas clairement des fichiers POSIX partagés ou un périphérique bloc dédié, il va sur S3 : le stockage objet est le moins cher des trois à exploiter, le seul nativement événementiel, et le moins riche en pièces mobiles.
| S3 | EFS | EBS | Lambda /tmp | |
|---|---|---|---|---|
| Modèle d'accès | API HTTP, objets entiers | Système de fichiers POSIX (NFS) | Périphérique bloc brut | Système de fichiers local |
| Partage | Clients concurrents illimités | Des milliers de clients concurrents | Une instance (multi-attach io2 mis à part) | Un environnement d'exécution |
| Profil de latence | Dizaines de ms par requête | Quelques ms | Sous la milliseconde | Sous la milliseconde |
| Forme de coût | Au Go stocké + à la requête | Au Go stocké + débit | Au Go provisionné + IOPS | Inclus jusqu'à 512 Mo, puis au Go configuré |
| Compatibilité serverless | Native : événements, URL présignées | Bonne, via montage VPC | Aucune | Intégré |
| Quand il gagne | Tout ce qui peut être un objet : uploads, assets, logs, exports | Fichiers partagés en lecture-écriture, gros modèles ML sur Lambda ou Fargate | Bases autogérées et volumes de démarrage sur EC2 | Données temporaires d'une seule invocation |
Deux réserves. La ligne latence donne des ordres de grandeur, pas des benchmarks : mesurez avec vos propres tailles de fichiers et schémas d'accès. Et la forme de coût pèse plus que le tarif affiché : un workload riche en requêtes peut rendre S3 plus cher que prévu, et des volumes provisionnés mais inactifs gonflent discrètement une facture EBS.
Quelles erreurs revoyons-nous sans cesse ?
Deux, en boucle. Des équipes montent EFS dans Lambda pour des données écrites une fois puis lues en entier, là où S3 serait plus simple et moins cher à exploiter ; et des équipes conçoivent comme si Lambda disposait d'un disque local persistant, un rôle qu'EBS n'y remplira jamais.
Le test pour la première : avez-vous besoin d'écritures partielles, de verrous de fichiers ou d'un chemin partagé entre écrivains concurrents ? Sinon, S3 avec URL présignées et notifications d'événements convient presque à coup sûr. La seconde cache en général un problème d'état : déplacez-le vers S3 ou DynamoDB et laissez /tmp jouer les caches. Remettre en cause précisément ce type de décision fait partie de notre travail d'architecture AWS.
Check-list de décision
Avant de provisionner :
- Écrit une fois, lu en entier ? S3, règles de cycle de vie dès le premier jour.
- Plusieurs fonctions ou conteneurs qui partagent des fichiers en lecture-écriture ? EFS, monté via un access point.
- Une seule instance EC2 qui a besoin d'un disque persistant rapide ? EBS, snapshots planifiés.
- Des données qui ne comptent que le temps d'une invocation ? Le /tmp de Lambda.
- Encore hésitant ? Chiffrez le schéma d'accès, pas le volume : requêtes et débit tranchent plus souvent que les gigaoctets.