EBS vs. EFS für mehrere EC2-Instanzen: Gemeinsame Ordner richtig teilen

Du hast fünf EC2-Instanzen und willst, dass alle auf denselben Ordner zugreifen — ein klassisches Setup, das auf den ersten Blick trivial wirkt, aber schnell zur Falle wird, wenn man EBS und EFS verwechselt. EBS verhält sich wie eine externe Festplatte: einmal angesteckt, einmal gemountet. EFS dagegen ist ein Netzwerk-Dateisystem, das genau für diesen Anwendungsfall gebaut wurde.

TL;DR: EBS vs. EFS auf einen Blick

Kriterium EBS EFS
Gleichzeitiger Zugriff mehrerer Instanzen Nur mit EBS Multi-Attach (eingeschränkt) Ja, nativ unterstützt
Dateisystem-Typ Block Storage (ext4, xfs, etc.) NFS v4.1 / v4.2
Regionsübergreifend Nein (AZ-gebunden) Ja (regionaler Dienst)
Typischer Anwendungsfall Einzelne Instanz, Datenbanken Shared Workloads, CMS, ML-Training
Kapazitätsplanung Manuell (feste Größe) Automatisch skalierend
Preismodell Provisionierte GB/Monat Verbrauchte GB/Monat

Preise und Limits variieren — immer die aktuelle AWS-Dokumentation prüfen.

Wie EBS und EFS grundlegend funktionieren

EBS ist Block Storage. AWS hängt ein EBS-Volume an eine einzelne EC2-Instanz in derselben Availability Zone. Das Betriebssystem formatiert das Volume mit einem Dateisystem (ext4, xfs) und mountet es wie eine lokale Festplatte. Dieses Modell ist für Einzelinstanz-Workloads optimiert — Datenbanken, Boot-Volumes, transaktionale I/O.

EBS Multi-Attach existiert, aber es ist kein Ersatz für EFS. Multi-Attach ist ausschließlich für io1- und io2-Volumes verfügbar, auf bis zu 16 Instanzen innerhalb einer einzigen Availability Zone beschränkt, und erfordert ein Cluster-fähiges Dateisystem (z. B. GFS2). Standarddateisysteme wie ext4 oder xfs sind nicht für gleichzeitigen Schreibzugriff von mehreren Hosts ausgelegt — Datenverlust ist das wahrscheinliche Ergebnis.

EFS ist ein vollständig verwalteter NFS-Dienst. Mehrere EC2-Instanzen mounten dasselbe EFS-Dateisystem gleichzeitig über NFS v4.1 oder v4.2. AWS verwaltet Replikation, Skalierung und Verfügbarkeit transparent. Kapazität wächst und schrumpft automatisch mit dem tatsächlichen Datenvolumen.

graph LR subgraph EBS_Modell["EBS: Eine Instanz"] EBS_Vol["EBS Volume"] EC2_A["EC2 Instanz A"] EC2_B["EC2 Instanz B (kein Zugriff)"] EC2_C["EC2 Instanz C (kein Zugriff)"] EBS_Vol -- "gemountet" --> EC2_A EBS_Vol -. "nicht moeglich" .-> EC2_B EBS_Vol -. "nicht moeglich" .-> EC2_C end subgraph EFS_Modell["EFS: Mehrere Instanzen"] EFS_FS["EFS Dateisystem"] MT_1A["Mount Target AZ-1"] MT_1B["Mount Target AZ-2"] EC2_1["EC2 Instanz 1"] EC2_2["EC2 Instanz 2"] EC2_3["EC2 Instanz 3"] EC2_4["EC2 Instanz 4"] EC2_5["EC2 Instanz 5"] EFS_FS --> MT_1A EFS_FS --> MT_1B MT_1A -- "NFS v4.1" --> EC2_1 MT_1A -- "NFS v4.1" --> EC2_2 MT_1A -- "NFS v4.1" --> EC2_3 MT_1B -- "NFS v4.1" --> EC2_4 MT_1B -- "NFS v4.1" --> EC2_5 end
  1. EBS-Volume ist an genau eine EC2-Instanz in einer AZ gebunden. Andere Instanzen haben keinen direkten Zugriff.
  2. EFS Mount Target wird pro AZ erstellt. Alle Instanzen in der Region mounten dasselbe Dateisystem über ihren jeweiligen Mount Target.
  3. NFS-Protokoll koordiniert den gleichzeitigen Zugriff — kein Cluster-Dateisystem erforderlich.
  4. EFS ist ein regionaler Dienst: Instanzen aus mehreren AZs teilen dasselbe Dateisystem ohne zusätzliche Konfiguration.

EBS Multi-Attach: Wann es trotzdem relevant ist

Bevor wir zu EFS übergehen: Multi-Attach ist nicht wertlos, aber der Anwendungsbereich ist eng. Es eignet sich für hochverfügbare Cluster-Anwendungen, die selbst Schreibkonflikte koordinieren — etwa Oracle RAC oder bestimmte Datenbank-Cluster. Für einen gemeinsamen Ordner zwischen fünf Standard-EC2-Instanzen ist Multi-Attach die falsche Wahl.

EBS Multi-Attach ist wie ein USB-Stick mit einem Y-Adapter: Beide Rechner können ihn physisch anschließen, aber ohne Software-Koordination überschreiben sie sich gegenseitig die Daten.

EFS einrichten: Schritt-für-Schritt für fünf EC2-Instanzen

Schritt 1: EFS-Dateisystem erstellen

Zunächst das Dateisystem anlegen. Der Parameter --performance-mode generalPurpose ist für die meisten Workloads korrekt. --throughput-mode bursting skaliert den Durchsatz automatisch mit der gespeicherten Datenmenge.

aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --region us-east-1 \
  --tags Key=Name,Value=shared-folder-efs

Die Ausgabe enthält die FileSystemId (Format: fs-XXXXXXXX). Diese ID wird für alle folgenden Schritte benötigt.

Schritt 2: Security Group für EFS konfigurieren

EFS kommuniziert über NFS (TCP Port 2049). Die Security Group des EFS Mount Targets muss eingehenden Traffic auf Port 2049 von den Security Groups der EC2-Instanzen erlauben — nicht von einzelnen IP-Adressen, da sich diese ändern können.

aws ec2 create-security-group \
  --group-name efs-mount-sg \
  --description 'Security Group fuer EFS Mount Targets' \
  --vpc-id vpc-0123456789abcdef0 \
  --region us-east-1
aws ec2 authorize-security-group-ingress \
  --group-id sg-0efs1234567890abc \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0ec2instances1234 \
  --region us-east-1

Schritt 3: Mount Targets pro Availability Zone erstellen

Für jede AZ, in der EC2-Instanzen laufen, muss ein Mount Target erstellt werden. Instanzen mounten EFS über den Mount Target in ihrer eigenen AZ — das minimiert Latenz und AZ-übergreifenden Datentransfer.

aws efs create-mount-target \
  --file-system-id fs-0abc12345def6789 \
  --subnet-id subnet-0a1b2c3d4e5f6a7b8 \
  --security-groups sg-0efs1234567890abc \
  --region us-east-1

Diesen Befehl für jedes Subnet (jede AZ) wiederholen, in dem Instanzen laufen.

Schritt 4: IAM-Rolle für EC2-Instanzen konfigurieren

Wenn EFS-Zugriffskontrolle über IAM-Autorisierung aktiviert ist, benötigen die EC2-Instanzen entsprechende Berechtigungen. Die folgende Policy erlaubt das Mounten und den Dateizugriff auf ein spezifisches EFS-Dateisystem.

🔽 IAM Policy für EFS-Zugriff anzeigen 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:DescribeMountTargets"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-0abc12345def6789"
    }
  ]
}

Schritt 5: EFS auf EC2-Instanzen mounten

AWS empfiehlt den EFS Mount Helper (amazon-efs-utils), der TLS-Verschlüsselung im Transit und IAM-Autorisierung automatisch handhabt. Ohne Mount Helper muss NFS manuell konfiguriert werden — fehleranfälliger und ohne automatische TLS-Unterstützung.

# amazon-efs-utils installieren (Amazon Linux 2 / Amazon Linux 2023)
sudo yum install -y amazon-efs-utils

# Mount-Verzeichnis erstellen
sudo mkdir -p /mnt/shared

# EFS mit TLS und IAM-Autorisierung mounten
sudo mount -t efs -o tls,iam fs-0abc12345def6789:/ /mnt/shared

Diesen Schritt auf allen fünf EC2-Instanzen ausführen. Alle Instanzen sehen danach denselben Verzeichnisinhalt in Echtzeit.

Schritt 6: Persistenten Mount via /etc/fstab einrichten

Ohne fstab-Eintrag geht der Mount nach einem Neustart verloren. Der _netdev-Parameter stellt sicher, dass das System wartet, bis das Netzwerk verfügbar ist, bevor es den Mount versucht.

echo 'fs-0abc12345def6789:/ /mnt/shared efs _netdev,tls,iam 0 0' | sudo tee -a /etc/fstab
sequenceDiagram participant EC2_1 as EC2 Instanz 1 (AZ-1) participant MT1 as Mount Target AZ-1 participant EFS as EFS Dateisystem participant MT2 as Mount Target AZ-2 participant EC2_5 as EC2 Instanz 5 (AZ-2) EC2_1->>MT1: NFS Mount Request (Port 2049) MT1->>EFS: Verbindung herstellen EFS-->>MT1: Bestaetigung MT1-->>EC2_1: Mount erfolgreich EC2_5->>MT2: NFS Mount Request (Port 2049) MT2->>EFS: Verbindung herstellen EFS-->>MT2: Bestaetigung MT2-->>EC2_5: Mount erfolgreich EC2_1->>EFS: Datei schreiben: /mnt/shared/data.txt EFS-->>EC2_5: Datei sichtbar: /mnt/shared/data.txt
  1. EC2-Instanzen in verschiedenen AZs verbinden sich jeweils mit dem Mount Target in ihrer eigenen AZ.
  2. Alle Mount Targets gehören zum selben EFS-Dateisystem — Änderungen einer Instanz sind sofort für alle anderen sichtbar.
  3. NFS v4.1 koordiniert gleichzeitige Lese- und Schreibzugriffe.

Ein reales Fehlerbild: Warum der Mount hängt

Symptom: mount -t efs hängt ohne Fehlermeldung. Nach dem Timeout erscheint Connection timed out. Der erste Reflex ist, das EFS-Dateisystem zu prüfen — falsche Fährte.

Die tatsächliche Ursache ist fast immer die Security Group. Die EC2-Instanz kann den Mount Target auf Port 2049 nicht erreichen, weil die Inbound-Regel der EFS-Security-Group fehlt oder auf die falsche Source zeigt. Das Tückische: AWS zeigt keinen expliziten Verbindungsfehler im Mount-Prozess — der Befehl hängt einfach.

Diagnose in zwei Schritten:

# Mount Target Status und IP-Adresse prüfen
aws efs describe-mount-targets \
  --file-system-id fs-0abc12345def6789 \
  --region us-east-1
# NFS-Erreichbarkeit direkt testen (von der EC2-Instanz aus)
nc -zv <mount-target-ip> 2049

Wenn nc einen Timeout zurückgibt, ist die Security Group das Problem — nicht das Dateisystem, nicht IAM, nicht der Mount Helper. Security Group zuerst prüfen, dann weitermachen.

EFS Performance-Modi und wann sie relevant werden

EFS bietet zwei Performance-Modi: generalPurpose und maxIO. Der maxIO-Modus ist für Workloads mit Hunderten von Instanzen ausgelegt und akzeptiert dafür höhere Latenz bei Metadatenoperationen. Für fünf Instanzen ist generalPurpose die richtige Wahl — maxIO würde hier nur Latenz hinzufügen ohne messbaren Vorteil.

Beim Durchsatz gilt: bursting funktioniert gut für variable Workloads mit Ruhephasen, da EFS Burst-Credits akkumuliert. Für kontinuierlich hohe Durchsatzanforderungen ist provisioned Throughput die stabilere Option — aber das ist ein Sizing-Thema, kein Architekturthema.

EBS vs. EFS: Die richtige Entscheidung treffen

Für einen gemeinsamen Ordner zwischen mehreren EC2-Instanzen ist EFS die einzige praktikable Wahl ohne Cluster-Dateisystem-Overhead. EBS bleibt die bessere Wahl für Einzelinstanz-Workloads mit hohen IOPS-Anforderungen — Datenbanken, Boot-Volumes, transaktionale Systeme.

Die Entscheidungsregel ist einfach: Wenn mehr als eine Instanz gleichzeitig schreiben muss, ist EBS ohne spezialisierte Cluster-Software keine Option.

graph TD Start(["Mehrere Instanzen brauchen
gemeinsamen Speicher?"]) Q1{"Gleichzeitiger Schreibzugriff
von mehreren Instanzen?"} Q2{"Cluster-Dateisystem
verfuegbar (GFS2 etc.)?"} Q3{"Hohe IOPS fuer
Einzelinstanz noetig?"} EFS_Rec["EFS verwenden
(empfohlen)"] MultiAttach["EBS Multi-Attach
(io1/io2, max. 16 Instanzen, 1 AZ)"] EBS_Rec["EBS verwenden
(Standard)"] Start --> Q1 Q1 -- "Ja" --> Q2 Q1 -- "Nein" --> Q3 Q2 -- "Nein" --> EFS_Rec Q2 -- "Ja" --> MultiAttach Q3 -- "Ja" --> EBS_Rec Q3 -- "Nein" --> EFS_Rec

Wrap-Up: EBS vs. EFS für gemeinsame Ordner — nächste Schritte

Für fünf EC2-Instanzen mit einem gemeinsamen Ordner ist EFS die direkte Antwort. Die Einrichtung folgt einem klaren Muster: Dateisystem erstellen, Mount Targets pro AZ anlegen, Security Groups korrekt konfigurieren, Mount Helper installieren, fstab-Eintrag setzen. Der häufigste Fehler ist die Security Group — Port 2049 muss von den EC2-Security-Groups erreichbar sein.

Weiterführende Dokumentation:

Glossar

Begriff Bedeutung
EBS (Elastic Block Store) Block-Storage-Dienst von AWS, der an einzelne EC2-Instanzen angehängt wird. Verhält sich wie eine lokale Festplatte.
EFS (Elastic File System) Vollständig verwalteter NFS-Dienst von AWS für gleichzeitigen Dateizugriff mehrerer Instanzen.
Mount Target Netzwerk-Endpunkt in einer Availability Zone, über den EC2-Instanzen auf ein EFS-Dateisystem zugreifen.
NFS (Network File System) Netzwerkprotokoll für verteilten Dateizugriff. EFS verwendet NFS v4.1 und v4.2.
EBS Multi-Attach Feature, das ein EBS-Volume (io1/io2) an bis zu 16 Instanzen in einer AZ anhängt — erfordert Cluster-fähiges Dateisystem.

Related Posts

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

EC2 ohne Internetzugang im eigenen VPC – Internet Gateway und Route Table korrekt einrichten

Du hast ein eigenes VPC erstellt, eine EC2-Instanz in einem öffentlichen Subnetz gestartet – und ping google.com läuft ins Leere. Kein Timeout-Fehler, keine Fehlermeldung, einfach nichts. Dieses Problem tritt fast immer auf, wenn ein Custom VPC ohne Internet Gateway oder mit einer unvollständigen Route-Table-Konfiguration aufgesetzt wird, weil AWS bei eigenen VPCs bewusst keine Standard-Internetverbindung mitliefert. TL;DR – EC2 Internetzugang im Custom VPC Schritt Aktion Warum notwendig 1 Internet Gateway erstellen und an VPC anhängen Ohne IGW gibt es keinen Pfad ins öffentliche Internet 2 Route Table aktualisieren (0.0.0.0/0 → IGW) Der Traffic muss explizit über das IGW geroutet werden 3 Subnetz mit Route Table verknüpfen Eine Route Table ohne Subnetz-Assoziation hat keine Wirkung 4 Öffentliche IP oder Elastic IP prüfen Ohne öffentliche IP kann das IGW keinen eingehenden Rückpfad aufbauen 5 Securi...
Mehr anzeigen

LSI vs. GSI in DynamoDB: Den richtigen Sekundärindex wählen

Man hat eine DynamoDB-Tabelle aufgebaut, die Abfragen über den Primärschlüssel laufen schnell — und dann kommt die Anforderung, dieselben Daten nach einem anderen Attribut zu filtern. Genau hier beginnt die Entscheidung zwischen einem Local Secondary Index (LSI) und einem Global Secondary Index (GSI) , und wer sie falsch trifft, zahlt entweder mit Flexibilitätsverlust oder mit unerwartetem Durchsatz-Overhead. TL;DR: LSI vs. GSI auf einen Blick Merkmal LSI GSI Erstellungszeitpunkt Nur bei Tabellenerstellung Jederzeit Partition Key Identisch mit Basistabelle Beliebiges Attribut Sort Key Anderes Attribut als Basistabelle Beliebiges Attribut (optional) Konsistenzmodell Strongly consistent möglich Nur eventually consistent Kapazität Teilt RCU/WCU mit Basistabelle Eigene RCU/WCU (Provisioned) oder On-Demand Datenmenge pro Partition Key Max. 10 GB Unbegrenzt Max. Anzahl pro Tabelle 5 20 (Standard...
Mehr anzeigen

ElastiCache Redis einsetzen: Wann ein Caching-Layer deine RDS-Datenbank entlastet

Du hast die Abfragen optimiert, Indizes gesetzt, Read Replicas hinzugefügt — und der RDS-Endpunkt ist immer noch der Engpass. Das passiert fast immer dann, wenn dieselben Zeilen hunderte Male pro Sekunde gelesen werden und jede Anfrage trotzdem den vollen Datenbankpfad durchläuft. Ein ElastiCache Redis-Layer löst genau dieses Problem, indem er häufig gelesene Ergebnisse im Arbeitsspeicher hält und RDS damit aus der kritischen Anfragekette herausnimmt. TL;DR: ElastiCache Redis als Caching-Layer vor RDS Aspekt Ohne Cache Mit ElastiCache Redis Lesepfad App → RDS (Disk/Buffer Pool) App → Redis (RAM) → RDS nur bei Cache Miss Latenz (typisch) Einige Millisekunden bis Dutzende ms Unter 1 ms bei Cache Hit RDS-Last bei hohem Traffic Linear steigend Deutlich reduziert bei hoher Hit-Rate Datenkonsistenz Immer aktuell Abhängig von TTL und Invalidierungsstrategie Operativer Aufwand Gering Mittel (Cache-Strategie,...
Mehr anzeigen