EBS vs EFS pour plusieurs instances EC2 : partager un dossier entre 5 serveurs

Vous venez de concevoir une architecture multi-instances et vous réalisez que cinq EC2 doivent lire et écrire dans le même répertoire — uploads utilisateurs, fichiers de configuration partagés, assets statiques. La première question qui vient : est-ce que EBS peut faire ça, ou faut-il absolument passer par EFS ? La réponse change radicalement selon le type de volume EBS et le mode d'accès souhaité.

TL;DR — EBS vs EFS pour le partage entre instances EC2

Critère EBS (volume standard) EBS Multi-Attach (io1/io2) EFS
Instances simultanées 1 seule Jusqu'à 16 (même AZ) Illimité, multi-AZ
Portée géographique 1 AZ 1 AZ uniquement Toute la région
Système de fichiers ext4, xfs, ntfs… Cluster-aware requis (GFS2, OCFS2) NFS v4.1 natif
Compatibilité OS Linux, Windows Linux (cluster FS) Linux, Windows, macOS
Gestion de la cohérence N/A (accès exclusif) À la charge de l'application Gérée par AWS (NFS)
Cas d'usage typique Base de données, OS Clustering haute dispo Partage de fichiers, CMS, ML
Coût relatif Faible Élevé (io2) Moyen à élevé selon usage

Comment fonctionne EBS — et pourquoi il bloque sur le partage

Un volume EBS est un périphérique bloc attaché à une instance via le réseau AWS interne. Par défaut, un volume EBS ne peut être attaché qu'à une seule instance à la fois. Cette contrainte n'est pas un choix de conception arbitraire : les systèmes de fichiers classiques (ext4, xfs, NTFS) ne sont pas conçus pour gérer des écritures concurrentes depuis plusieurs hôtes. Si deux instances montaient le même volume ext4 simultanément, la corruption du système de fichiers serait quasi-certaine.

EBS Multi-Attach existe pour les volumes io1 et io2, et permet d'attacher un volume à jusqu'à 16 instances — mais uniquement dans la même zone de disponibilité. Et surtout, Multi-Attach ne règle pas le problème de cohérence : AWS livre les I/O à chaque instance, mais c'est l'application ou un système de fichiers cluster-aware (GFS2, OCFS2) qui doit gérer les verrous et la cohérence. Pour cinq instances réparties sur plusieurs AZ, Multi-Attach ne fonctionne tout simplement pas.

graph TD subgraph EBS_Standard["EBS Standard"] V1["Volume EBS"] I1["Instance EC2 A"] V1 -->|"Attaché exclusivement"| I1 I2["Instance EC2 B"] I3["Instance EC2 C"] V1 -.-|"Accès refusé"| I2 V1 -.-|"Accès refusé"| I3 end subgraph EBS_MA["EBS Multi-Attach (même AZ uniquement)"] V2["Volume io2"] I4["Instance EC2 D"] I5["Instance EC2 E"] V2 -->|"Cluster FS requis"| I4 V2 -->|"Cluster FS requis"| I5 end subgraph EFS_Block["EFS (multi-AZ, NFS managé)"] FS["Filesystem EFS"] MT1["Mount Target AZ-1"] MT2["Mount Target AZ-2"] I6["Instance 1"] I7["Instance 2"] I8["Instance 3"] FS --> MT1 FS --> MT2 MT1 --> I6 MT1 --> I7 MT2 --> I8 end
  1. EBS standard : attaché à une seule instance, dans une seule AZ. Les autres instances n'y ont aucun accès.
  2. EBS Multi-Attach : plusieurs instances dans la même AZ peuvent accéder au volume, mais la cohérence des écritures reste à la charge du système de fichiers cluster.
  3. EFS : système de fichiers NFS managé, accessible depuis n'importe quelle instance dans la région via des mount targets par AZ.

EFS — l'architecture NFS managée d'AWS

Amazon EFS expose un système de fichiers NFS v4.1 entièrement managé. Vous créez un filesystem EFS, vous déployez des mount targets dans chaque AZ où vos instances résident, et chaque instance monte le filesystem via NFS. AWS gère la réplication des données, la disponibilité et la scalabilité du stockage sous-jacent.

graph LR subgraph Region["Région AWS (us-east-1)"] subgraph EFS_Service["Amazon EFS"] FS["Filesystem EFS
fs-0123456789abcdef0"] end subgraph AZ1["AZ us-east-1a"] MT1["Mount Target
IP privée VPC"] EC1["Instance EC2 #1"] EC2["Instance EC2 #2"] EC3["Instance EC2 #3"] end subgraph AZ2["AZ us-east-1b"] MT2["Mount Target
IP privée VPC"] EC4["Instance EC2 #4"] EC5["Instance EC2 #5"] end FS --> MT1 FS --> MT2 MT1 -->|"NFS v4.1 / TCP 2049"| EC1 MT1 -->|"NFS v4.1 / TCP 2049"| EC2 MT1 -->|"NFS v4.1 / TCP 2049"| EC3 MT2 -->|"NFS v4.1 / TCP 2049"| EC4 MT2 -->|"NFS v4.1 / TCP 2049"| EC5 end
  1. Le filesystem EFS est une ressource régionale. Les données sont stockées de façon redondante sur plusieurs AZ.
  2. Chaque AZ dispose d'un mount target — une interface réseau dans votre VPC avec une IP privée. C'est le point d'entrée NFS pour les instances de cette AZ.
  3. Les instances EC2 montent le filesystem via le DNS du mount target ou le DNS régional d'EFS.
  4. Toutes les instances voient le même namespace de fichiers, avec une cohérence forte pour les opérations séquentielles.

Pensez à EFS comme à un NAS dans le cloud : vous branchez autant de serveurs que vous voulez, ils voient tous le même système de fichiers. La différence, c'est qu'AWS gère le NAS pour vous — capacité, réplication, disponibilité.

Déployer EFS pour cinq instances EC2 — étape par étape

Prérequis

  • Un VPC avec des sous-réseaux dans les AZ où vos instances résident
  • Un Security Group pour EFS autorisant le port 2049 (NFS) depuis les instances
  • Le package amazon-efs-utils installé sur chaque instance (recommandé pour le montage TLS)
  • AWS CLI configuré avec les permissions nécessaires

Étape 1 — Créer le filesystem EFS

La création du filesystem définit les paramètres fondamentaux : chiffrement, mode de performance et mode de débit. Le mode de performance generalPurpose convient à la majorité des workloads. Le mode bursting pour le débit est adapté aux accès intermittents.

# Créer le filesystem EFS avec chiffrement activé
aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --tags Key=Name,Value=shared-fs \
  --region us-east-1

Notez le FileSystemId retourné (format fs-XXXXXXXX). Vous en aurez besoin pour les étapes suivantes.

Étape 2 — Créer les mount targets dans chaque AZ

Un mount target par AZ suffit pour desservir toutes les instances de cette AZ. Si vos cinq instances sont réparties sur trois AZ, créez trois mount targets. Chaque mount target est associé à un sous-réseau et à un Security Group.

# Mount target pour us-east-1a
aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0a1b2c3d4e5f60001 \
  --security-groups sg-0a1b2c3d4e5f60002 \
  --region us-east-1

# Mount target pour us-east-1b
aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0a1b2c3d4e5f60003 \
  --security-groups sg-0a1b2c3d4e5f60002 \
  --region us-east-1

# Mount target pour us-east-1c
aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0a1b2c3d4e5f60004 \
  --security-groups sg-0a1b2c3d4e5f60002 \
  --region us-east-1

Attendez que les mount targets passent à l'état available avant de procéder au montage :

aws efs describe-mount-targets \
  --file-system-id fs-0123456789abcdef0 \
  --region us-east-1 \
  --query 'MountTargets[*].{AZ:AvailabilityZoneName,State:LifeCycleState,IP:IpAddress}' \
  --output table

Étape 3 — Configurer le Security Group EFS

Le Security Group attaché aux mount targets doit autoriser le trafic NFS (TCP 2049) depuis les instances EC2. La règle la plus propre : autoriser le Security Group des instances EC2, pas une plage CIDR.

# Autoriser NFS depuis le SG des instances EC2
aws ec2 authorize-security-group-ingress \
  --group-id sg-0a1b2c3d4e5f60002 \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0a1b2c3d4e5f60010 \
  --region us-east-1

Étape 4 — Monter EFS sur chaque instance EC2

Avec amazon-efs-utils, vous pouvez utiliser le type de montage efs qui gère automatiquement le chiffrement TLS en transit et la sélection du mount target le plus proche. C'est la méthode recommandée.

# Installer amazon-efs-utils (Amazon Linux 2 / AL2023)
sudo yum install -y amazon-efs-utils

# Créer le point de montage
sudo mkdir -p /mnt/shared

# Monter avec chiffrement TLS
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

Pour un montage persistant au redémarrage, ajoutez l'entrée dans /etc/fstab :

fs-0123456789abcdef0:/ /mnt/shared efs defaults,_netdev,tls 0 0

Vérifiez que le montage est actif sur chaque instance :

df -h /mnt/shared
mount | grep efs

IAM et politiques d'accès EFS

EFS supporte deux couches de contrôle d'accès distinctes qui s'appliquent indépendamment :

  • Politique de ressource EFS (attachée au filesystem) : contrôle quels principals IAM peuvent effectuer des appels d'API EFS sur ce filesystem (ex. elasticfilesystem:ClientMount). C'est l'équivalent d'une bucket policy S3, mais pour EFS.
  • Politique basée sur l'identité (attachée au rôle IAM de l'instance) : contrôle ce que l'instance est autorisée à faire via l'API EFS. L'exemple ci-dessous est une politique de ce type — elle est attachée au rôle IAM de l'instance EC2, et non au filesystem lui-même.
🔽 Politique IAM basée sur l'identité — accès EFS en lecture/écriture (attachée au rôle de l'instance EC2) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EFSMountAccess",
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-0123456789abcdef0"
    }
  ]
}

Pour que l'autorisation IAM soit appliquée lors du montage, vous devez activer l'option iam dans la commande de montage :

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Erreur classique : EBS Multi-Attach mal compris

Voici un scénario réel. L'équipe déploie cinq instances dans deux AZ différentes. Quelqu'un lit la documentation EBS Multi-Attach et pense avoir trouvé la solution. Le volume io2 est créé, attaché aux instances de la première AZ — ça fonctionne en apparence. Puis on essaie d'attacher aux instances de la deuxième AZ : erreur immédiate, Multi-Attach refuse l'attachement cross-AZ.

Deuxième tentative : toutes les instances sont déplacées dans la même AZ. Le volume est attaché aux cinq instances. Mais personne n'a configuré GFS2 ou OCFS2 — chaque instance monte le volume en ext4 indépendamment. Résultat : corruption silencieuse du système de fichiers en quelques heures d'écritures concurrentes.

La leçon : Multi-Attach n'est pas un système de fichiers partagé. C'est un mécanisme de bas niveau pour des applications qui implémentent elles-mêmes la coordination des accès. Pour du partage de fichiers entre instances, EFS est la réponse correcte.

Multi-Attach sans cluster filesystem, c'est comme donner les clés d'un même appartement à cinq personnes sans leur dire qu'elles partagent le même espace — le chaos est inévitable.

EBS vs EFS : quand choisir quoi

graph TD Start(["Besoin de stockage partagé"]) Q1{"Plusieurs instances
accèdent au stockage ?"} Q2{"Même AZ uniquement
+ cluster filesystem ?"} Q3{"Stockage objet
(assets, backups) ?"} EBS["EBS Standard
Recommandé"] EBSMA["EBS Multi-Attach io1/io2
+ GFS2 ou OCFS2"] EFS_Rec["Amazon EFS
Recommandé"] S3["Amazon S3"] Start --> Q1 Q1 -->|"Non — instance unique"| EBS Q1 -->|"Oui"| Q2 Q2 -->|"Oui"| EBSMA Q2 -->|"Non — multi-AZ ou sans cluster FS"| Q3 Q3 -->|"Oui"| S3 Q3 -->|"Non — système de fichiers POSIX"| EFS_Rec
  1. Si une seule instance accède au stockage, EBS est le choix naturel — latence plus faible, coût moindre.
  2. Si plusieurs instances dans la même AZ ont besoin d'accès concurrent et que vous gérez un cluster filesystem, EBS Multi-Attach (io1/io2) est envisageable.
  3. Pour tout partage de fichiers entre plusieurs instances, surtout multi-AZ, EFS est la solution appropriée.
  4. Pour du stockage objet (assets, backups, datasets ML), S3 est souvent plus adapté qu'EFS.

Optimisation des coûts EFS

EFS facture en fonction du stockage utilisé et du mode de débit. Deux leviers principaux pour réduire les coûts :

  • EFS Intelligent-Tiering : déplace automatiquement les fichiers peu accédés vers un tier de stockage moins coûteux (EFS Infrequent Access). Activez-le via une lifecycle policy.
  • Mode de débit Elastic : si vos workloads ont des pics imprévisibles, le mode Elastic ajuste automatiquement le débit sans surprovisionnement.
# Activer Intelligent-Tiering (transition après 30 jours sans accès)
aws efs put-lifecycle-configuration \
  --file-system-id fs-0123456789abcdef0 \
  --lifecycle-policies TransitionToIA=AFTER_30_DAYS \
  --region us-east-1

Conclusion — EBS vs EFS pour le partage entre instances EC2

Pour partager un dossier entre cinq instances EC2, EFS est la solution correcte dans la quasi-totalité des cas. EBS standard est mono-instance par conception. EBS Multi-Attach couvre un cas très spécifique (cluster filesystem, même AZ) qui ne correspond pas au besoin de partage de fichiers classique.

La mise en place d'EFS se résume à trois actions : créer le filesystem, déployer les mount targets dans chaque AZ, et monter via amazon-efs-utils avec TLS. Le reste — réplication, disponibilité, scalabilité — est géré par AWS.

Pour aller plus loin, consultez la documentation officielle Amazon EFS et le guide Mounting EFS file systems.

Glossaire

Terme Définition
EBS (Elastic Block Store) Stockage bloc persistant attaché à une instance EC2 via le réseau AWS. Comparable à un disque dur virtuel.
EFS (Elastic File System) Système de fichiers NFS managé par AWS, accessible simultanément par plusieurs instances dans une région.
Mount Target Interface réseau créée par EFS dans un sous-réseau VPC. Point d'entrée NFS pour les instances de cette AZ.
Multi-Attach Fonctionnalité EBS permettant d'attacher un volume io1/io2 à plusieurs instances dans la même AZ. Nécessite un cluster filesystem.
NFS (Network File System) Protocole réseau permettant à un système de fichiers d'être monté et accédé à distance. EFS utilise NFS v4.1.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite