Amazon SAA-C03: Speicherung & Datenlebenszyklus — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

S3-Speicherklassen und das Kosten-Latenz-Spektrum

S3-Speicherklassen bewegen sich auf einem Spektrum, bei dem Abruflatenz, Mindestspeicherdauer und Abrufgebühren pro GB gegen die Speicherkosten pro GB abgewogen werden. Die richtige Wahl ist der größte Hebel zur Kostenoptimierung bei Objektspeichern.

S3 Standard ist die Standardeinstellung: Haltbarkeit von elf Neunen über drei oder mehr AZs, Latenz im Millisekundenbereich, keine Abrufgebühr, höchster Preis pro GB. Standard-IA und One Zone-IA senken die Speicherkosten um etwa 40–50 %, fügen aber eine Abrufgebühr pro GB, eine abrechenbare Mindestdauer von 30 Tagen und eine minimale Objektgröße von 128 KB hinzu (kleinere Objekte werden als 128 KB abgerechnet, was die Einsparungen schmälert). One Zone-IA reduziert die Kosten weiter, indem die Speicherung in einer einzigen AZ erfolgt – dies ist nur für reproduzierbare sekundäre Kopien geeignet, bei denen der Verlust einer einzelnen AZ tolerierbar ist.

S3 Intelligent-Tiering ist die richtige Wahl, wenn Zugriffsmuster unbekannt, unvorhersehbar oder sich über einen großen Datenbestand hinweg ändernd sind. Es migriert Objekte automatisch zwischen den Stufen für häufigen Zugriff, seltenen Zugriff, Archiv-Sofortzugriff, Archiv und Tiefenarchiv basierend auf den beobachteten Zugriffen und berechnet dafür eine geringe Überwachungsgebühr pro Objekt. Da es keine Abrufgebühren zwischen den Stufen für häufigen und seltenen Zugriff und keine Mindestdauer gibt, ist es die sicherste Standardeinstellung für Data Lakes und gemischte Workloads mit Objekten ≥128 KB. Es ist die falsche Wahl, wenn Sie bereits wissen, dass Objekte dauerhaft intensiv genutzt werden (zusätzliche Überwachungskosten) oder ein Jahrzehnt lang dauerhaft kalt sind (Deep Archive ist weitaus günstiger).

Glacier Instant Retrieval bietet Zugriff im Millisekundenbereich zu Archivpreisen für Daten, auf die vierteljährlich oder seltener zugegriffen wird – medizinische Bilder, Compliance-PDFs, die bei Bedarf sofort vorgelegt werden müssen. Glacier Flexible Retrieval bietet einen Abruf innerhalb von Minuten bis Stunden. Glacier Deep Archive ist die günstigste Stufe in AWS mit etwa 1 $/TB/Monat, mit einem 12-stündigen Standardabruf (oder 48-stündigem Massenabruf) und einer Mindestdauer von 180 Tagen – die richtige Antwort für die regulatorische Aufbewahrung für 7–10 Jahre und als Ersatz für Bänder.

Die beiden häufigsten Kostenfallen sind gegensätzliche Fehler. Die Wahl von Standard für langfristig selten gelesene Daten verbrennt Geld, da Standard keinen Preisnachlass für kalte Speicherung bietet – ein 5-TB-Datensatz, der jahrelang in Standard aufbewahrt wird, kostet ein Vielfaches mehr als dieselben Daten in Deep Archive. Umgekehrt ist es eine Falle, brandneue Objekte direkt in Standard-IA oder Glacier zu verschieben, da die Mindestgebühren für 30/90/180 Tage zuzüglich der Abrufgebühren die Einsparungen übersteigen, solange die Objekte noch intensiv genutzt werden. Glacier Flexible oder Deep Archive sind auch gänzlich inkompatibel mit Workloads, die einen synchronen Lesezugriff erwarten – ein Benutzer, der auf einen HTTP-GET wartet, kann eine Abruf-SLA von Minuten bis 12 Stunden nicht tolerieren. Glacier Instant Retrieval ist die einzige Glacier-Stufe, die mit sofortigem Zugriff kompatibel ist.

Lifecycle-Richtlinien und Versionsverwaltung

Eine Lifecycle-Konfiguration ist eine deklarative JSON/YAML-Datei, die an einen Bucket angehängt wird und Objekte basierend auf Alter, Tag oder Präfix überführt oder ablaufen lässt. Übergänge werden einmal pro Tag ausgewertet und erst nach Erreichen des angegebenen Alters ausgelöst – ein Übergang mit Days: 30 bedeutet, dass die Standard-Raten für die ersten 30 Tage gelten. Übergänge müssen zu schrittweise kälteren Stufen erfolgen, und Objekte, die kleiner als 128 KB sind, werden nicht von Standard nach IA überführt, da der Mehraufwand pro Objekt die Einsparungen überwiegt; konsolidieren Sie kleine Objekte zuerst mittels tar/zip oder S3 Batch Operations.

Eine kanonische Richtlinie für einen Workload, der 30 Tage lang intensiv genutzt wird, danach kalt ist, während der gesamten Zeit sofortigen Zugriff benötigt, vier Jahre lang aufbewahrt wird und eine saubere Verwaltung aufweist:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Eine häufige Falle bei der Versionsverwaltung: Bei einem versionierten Bucket fügt eine Lifecycle-Regel, die aktuelle Objekte ablaufen lässt, lediglich Löschmarkierungen ein; frühere Versionen sammeln sich unbemerkt an und verursachen weiterhin Kosten. Nicht aktuelle Versionen erfordern ihre eigenen expliziten NoncurrentVersionTransitions und NoncurrentVersionExpiration. Ebenso sollten Sie immer AbortIncompleteMultipartUpload einbeziehen – verwaiste Teile von mehrteiligen Uploads sind in der Konsolenauflistung unsichtbar und verursachen unbegrenzt Speicherkosten.

Für gemischte Muster – zum Beispiel IoT-Telemetriedaten, die im ersten Monat für ML-Training intensiv genutzt, dann ein Jahr lang vierteljährlich abgefragt und anschließend archiviert werden – ist die richtige Antwort Intelligent-Tiering für das erste Jahr (wobei die Klasse die Optimierung zwischen Trainings-Spitzen und Leerlaufzeiten automatisch vornimmt), gefolgt von einem geplanten Übergang zu Deep Archive an Tag 365.

Versionierung, MFA Delete und Object Lock

Einmal aktiviert, kann die Versionierung nur noch ausgesetzt, aber nicht mehr deaktiviert werden. Jeder PUT-Vorgang erzeugt eine neue Versions-ID; ein DELETE-Vorgang fügt eine Löschmarkierung (Delete Marker) hinzu, anstatt die Daten zu entfernen. Die Versionierung schützt vor versehentlichem Überschreiben, ist aber keine Unveränderlichkeit: Jeder Prinzipal mit der Berechtigung s3:DeleteObjectVersion kann eine bestimmte Version endgültig entfernen. MFA Delete fügt die Anforderung hinzu, dass das Root-Konto ein MFA-Token vorweisen muss, um Versionen endgültig zu löschen oder den Versionierungsstatus zu ändern. Dies schließt die Lücke des versehentlichen Löschens für Buckets mit hohem Wert, verhindert aber nicht, dass ein autorisierter Akteur Daten zerstört.

Echte Unveränderlichkeit erfordert S3 Object Lock, was wiederum Versionierung voraussetzt und im Allgemeinen bei der Erstellung des Buckets aktiviert werden muss. Es gibt zwei Modi, die häufig verwechselt werden:

Die Aufbewahrungsfrist kann pro Objekt (Retain-Until-Date) oder über einen Legal Hold angewendet werden, der kein Ablaufdatum hat. Für Buchhaltungsunterlagen, die ein Jahr lang „heiß“ (hot), neun Jahre lang archiviert und zehn Jahre lang nicht gelöscht werden dürfen, ist das korrekte Muster Object Lock im Compliance-Modus mit einer zehnjährigen Aufbewahrungsfrist, kombiniert mit einem Lifecycle-Übergang zu Deep Archive nach 365 Tagen. Der Governance-Modus ist kein akzeptabler Ersatz für eine gesetzliche Vorschrift – eine Regulierungsbehörde wird „jemand mit Berechtigungen hätte dies löschen können“ nicht als Unveränderlichkeit akzeptieren.

Um eine Aufbewahrungsfrist auf einen bestehenden Korpus von PDFs in einem einzigen Job anzuwenden, verwenden Sie S3 Batch Operations, gesteuert durch ein S3 Inventory-Manifest. Batch Operations ist die verwaltete Lösung für umfangreiche Änderungen – Aufbewahrungsfristen, Tagging, PUT-Kopie-Neuverschlüsselung, Lambda-Aufrufe – über Milliarden von Schlüsseln hinweg; handgeschriebene Iterationsskripte sind hier nicht das richtige Muster.

Verschlüsselung: SSE-S3, SSE-KMS und Bucket Keys

Jeder Bucket verfügt über eine Standardverschlüsselung. SSE-S3 (AES-256, von S3 verwaltete Schlüssel) ist kostenlos und erfordert keine Schlüsselverwaltung. SSE-KMS verwendet einen KMS Customer Master Key und ermöglicht dadurch Audit-Protokolle pro Schlüssel in CloudTrail, IAM-basierte Schlüssel-Zugriffsrichtlinien und die Kontrolle über die Schlüsselrotation – dies verursacht jedoch Kosten für KMS-API-Aufrufe und, was noch wichtiger ist, eine Drosselung von KMS-Anfragen, die bei Leseworkloads mit hohem Durchsatz zum Engpass werden kann. Wählen Sie SSE-KMS, wenn Sie diese Kontrollmechanismen tatsächlich benötigen (regulatorische Nachweise, Funktionstrennung, kontoübergreifende Schlüssel-Freigabe). Standardmäßig SSE-KMS „zur Sicherheit“ zu verwenden, führt zu unnötigen Kosten und Komplexität, wenn SSE-S3 die Anforderungen bereits erfüllt.

S3 Bucket Keys reduzieren die Kosten für SSE-KMS-Anfragen. S3 generiert einen kurzlebigen Schlüssel auf Bucket-Ebene aus dem CMK und leitet daraus lokal objektbezogene Datenschlüssel ab. Dadurch wird ein KMS-Aufruf von GenerateDataKey/Decrypt pro Objekt vermieden und die Kosten für KMS-Anfragen um bis zu 99 % gesenkt:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Auf SSE-S3 zu wechseln, um „KMS-Kosten zu vermeiden“, ist der falsche Workaround, wenn die Anforderungen KMS vorschreiben – Bucket Keys erfüllen sowohl die Compliance- als auch die Kostenziele, ohne auf KMS zu verzichten.

Die Aktivierung der Standard-Bucket-Verschlüsselung stellt sicher, dass alle zukünftigen Uploads verschlüsselt werden (unverschlüsselte PUTs werden transparent verschlüsselt). Um unverschlüsselte PUTs vollständig abzulehnen, verweigern Sie Schreibvorgänge, denen der Header fehlt:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Die Standardverschlüsselung hat keine Auswirkungen auf bereits vorhandene, unverschlüsselte Objekte. Verschlüsseln Sie diese neu, indem Sie S3 Inventory und Batch Operations verwenden, um einen Copy-Job auszuführen, der jeden Schlüssel an Ort und Stelle überschreibt – das ist das Standardmuster für die Massen-Neuverschlüsselung.

Ad-hoc clientseitige Verschlüsselung ist der Standardverschlüsselung mit KMS unterlegen: Sie verteilt die Schlüsselverwaltung auf verschiedene Anwendungsteams, kann nicht zentral über CloudTrail-KMS-Ereignisse auditiert werden und kann keine Bucket Keys verwenden.

Cross-Region Replication und Multi-Region KMS Keys

Cross-Region Replication (CRR) kopiert Objekte asynchron in einen Bucket in einer anderen Region für Compliance-, DR- oder Latenzzwecke. Same-Region Replication (SRR) dient der Trennung für Compliance-Zwecke, der Protokollaggregation und kontoübergreifenden Kopien. Beide erfordern die Aktivierung der Versionierung auf dem Quell- und Ziel-Bucket sowie eine IAM-Rolle, die der Quell-Bucket annimmt. CRR ist die einfache Lösung, wenn ein Bucket in eine andere Region gespiegelt werden muss – das Skripten von aws s3 sync, das Verknüpfen von Lambdas mit ObjectCreated oder das Ausführen geplanter Batch-Kopierjobs führt zu operativem Mehraufwand, Race Conditions und stillen Fehlern. Weder CRR noch SRR replizieren standardmäßig bestehende Objekte; verwenden Sie S3 Batch Replication für die nachträgliche Replikation.

Die Interaktionen mit der Verschlüsselung sind ein Bereich, in dem Architekturen häufig scheitern:

• SSE-S3-Objekte werden transparent repliziert.
• SSE-KMS-Objekte werden nicht standardmäßig repliziert – Sie müssen dies explizit aktivieren, einen Ziel-KMS-Schlüssel in der Zielregion angeben und der Replikationsrolle die Berechtigungen kms:Decrypt für den Quellschlüssel und kms:Encrypt für den Zielschlüssel erteilen. Ein Schlüssel, der nur in einer Region existiert, kann keine Objekte in einer anderen Region verschlüsseln.
• Clientseitig verschlüsselte Objekte werden als undurchsichtiger Chiffretext repliziert; die Zielregion hat keinen Nutzen, es sei denn, das Schlüsselmaterial des Clients ist dort ebenfalls verfügbar.

Die frühere Komplexität bei der Verwaltung von zwei unabhängigen CMKs wird durch AWS KMS Multi-Region Keys gelöst, die dasselbe Schlüsselmaterial und dieselbe Schlüssel-ID (mit einem Regionspräfix) in mehreren Regionen bereitstellen. Ein repliziertes Objekt kann dann in der Zielregion ohne regionenübergreifende KMS-Aufrufe und ohne erneutes Verschlüsseln (Re-Wrapping) des Datenschlüssels entschlüsselt werden. Dies ist das kanonische Muster für verschlüsselte, replizierte Buckets, die bei einem regionalen Failover nutzbar bleiben müssen.

Die kontoübergreifende Freigabe von Snapshots und Objekten, die mit einem kundenseitig verwalteten KMS-Schlüssel verschlüsselt sind, erfordert, dass die Prinzipale des Zielkontos über eine Schlüsselrichtlinie die Berechtigungen kms:Decrypt, kms:CreateGrant, kms:DescribeKey und kms:ReEncrypt* für den Quellschlüssel sowie passende IAM-Berechtigungen besitzen. Von AWS verwaltete Schlüssel (z. B. aws/ebs, aws/s3) können nicht kontoübergreifend geteilt werden, daher sind für kontoübergreifende Workflows kundenseitig verwaltete Schlüssel zwingend erforderlich.

Block Public Access und Zugriffsbeschränkung auf CloudFront

S3 Block Public Access (BPA) hat vier Einstellungen – neue öffentliche ACLs blockieren, bestehende öffentliche ACLs ignorieren, neue öffentliche Bucket-Richtlinien blockieren, öffentliche Bucket-Richtlinien einschränken – die pro Bucket und, was noch wichtiger ist, auf Kontoebene konfigurierbar sind. BPA auf Kontoebene setzt jede Bucket-Richtlinie außer Kraft, die öffentlichen Zugriff gewähren würde, und ist die richtige Kontrolle für die Anforderung „kein Objekt in diesem Konto darf öffentlich sein“. Richtlinien nur auf Bucket-Ebene sind fragil: Ein neuer Bucket könnte ohne eine solche gestartet werden; BPA auf Kontoebene ist „fail-closed“ (standardmäßig sicher).

Um zu verhindern, dass ein Administrator in einem Mitgliedskonto BPA deaktiviert, wenden Sie eine Service Control Policy auf der Ebene der Organizations-OU oder des Root-Kontos an:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Um S3-Inhalte ausschließlich über CloudFront bereitzustellen, fügen Sie eine Origin Access Control (OAC) – der moderne Ersatz für die veraltete OAI – zur Distribution hinzu und steuern Sie die Bucket-Richtlinie über die ARN der Distribution:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA bleibt für den Bucket aktiviert. Für zeitlich begrenzten Zugriff auf private Objekte durch einen bestimmten Benutzer (Ablaufdatum für Upload/Download) generieren Sie eine Presigned URL, deren eingebettete Signatur die Berechtigungen des signierenden Prinzipals übernimmt.

Private Netzwerkpfade: Gateway-Endpunkte

EC2-zu-S3-Traffic innerhalb einer VPC nutzt nicht automatisch das private AWS-Backbone. Ohne Konfiguration werden S3-API-Aufrufe zu öffentlichen Endpunkten aufgelöst und laufen über das Internet-Gateway oder NAT-Gateway, was Datenverarbeitungsgebühren für NAT verursacht und den Traffic dem Internet aussetzt. Ein Gateway-VPC-Endpunkt für S3 (und DynamoDB) ist kostenlos, wird als Präfixlisten-Route in den angegebenen Routing-Tabellen hinzugefügt und hält den Traffic im AWS-Netzwerk. Interface-Endpunkte (PrivateLink) für S3 existieren ebenfalls, sind aber kostenpflichtig und nützlich, wenn der Zugriff von On-Premises über Direct Connect erfolgt. Kombinieren Sie den Endpunkt mit einer aws:SourceVpce-Bedingung in der Bucket-Richtlinie, um zu erzwingen, dass der Bucket nur von genehmigten VPC-Endpunkten aus erreichbar ist – das Standardmuster für regulierte Workloads.

Object Lambda für On-the-Fly-Transformationen

S3 Object Lambda fügt eine Lambda-Funktion in den GET/HEAD/LIST-Pfad ein, sodass das an den Aufrufer zurückgegebene Objekt zur Lesezeit transformiert wird. Dies vermeidet die Duplizierung von Daten für jede Variante (geschwärzt, größenverändert, neu formatiert) und bewahrt eine einzige „Source of Truth“ im zugrunde liegenden Bucket. Typische Anwendungsfälle: Schwärzung von PII für Analysten gegenüber vollständigen Daten für Auditoren, benutzerbezogene Wasserzeichen für Bilder, XML-zu-JSON-Konvertierung für Legacy-Clients. IAM- und Bucket-Richtlinien steuern weiterhin den Zugriff auf das zugrunde liegende Objekt; die Lambda-Funktion sieht nur das, was ihre Ausführungsrolle erlaubt.

Ereignisbenachrichtigungen

S3 sendet Ereignisse (s3:ObjectCreated:*, s3:ObjectRemoved:*, Replikations- und Lifecycle-Ereignisse) an Lambda, SQS, SNS oder EventBridge. EventBridge wird bevorzugt, wenn Sie mehrere Ziele, Filterung nach Objekt-Metadaten oder kontoübergreifendes Routing benötigen; direkte Benachrichtigungen sind einfacher und kostengünstiger für Pipelines mit einem einzigen Ziel, wie z. B. die Erstellung von Thumbnails beim Upload. Benachrichtigungen erfolgen nach dem „At-least-once“-Prinzip, daher müssen die Consumer idempotent sein.

Durchsatzoptimierung: Multipart Upload und Transfer Acceleration

Für Objekte über 100 MB ist der Multipart Upload Best Practice; über 5 GB ist er zwingend erforderlich. Die Teile werden parallel hochgeladen, fehlgeschlagene Teile werden unabhängig voneinander erneut versucht, und der Durchsatz skaliert mit der Gleichzeitigkeit (Concurrency). Byte-Range-GETs ermöglichen eine äquivalente Parallelität bei Downloads. Wie bereits erwähnt, fügen Sie immer eine AbortIncompleteMultipartUpload-Lifecycle-Regel hinzu, um die Abrechnung für verwaiste Teile zu vermeiden.

S3 Transfer Acceleration leitet Uploads über den nächstgelegenen CloudFront-Edge über das AWS-Backbone – verwenden Sie dies für global verteilte Clients, die in einen einzigen Bucket hochladen. Für Downloads schalten Sie CloudFront vor S3, um am Edge zu cachen. Transfer Acceleration ist auf Uploads ausgerichtet; CloudFront ist auf Downloads ausgerichtet; sie lösen verwandte, aber unterschiedliche Probleme.

EBS: Volume-Typen, Verschlüsselung und Snapshots

EBS-Volumes sind auf eine AZ beschränkte Block-Geräte, die an eine einzelne EC2-Instanz angehängt sind. gp3 ist die standardmäßige Allzweck-SSD; ihr entscheidender Vorteil gegenüber gp2 ist, dass IOPS (bis zu 16.000) und Durchsatz (bis zu 1.000 MiB/s) unabhängig von der Kapazität bereitgestellt werden. Dies eliminiert das gp2-Antimuster, Speicher nur zur Erreichung von Leistungszielen überzuprovisionieren. io2 Block Express liefert bis zu 256.000 IOPS bei Latenzen im Sub-Millisekundenbereich für latenzempfindliche Datenbanken. st1 und sc1 sind HDD-basiert für durchsatzorientierte sequentielle und kalte Workloads. Multi-Attach für io1/io2 existiert, ist aber auf 16 Instanzen in derselben AZ beschränkt, die ein clusterfähiges Dateisystem ausführen – eine seltene Ausnahme, kein allgemeines „Shared EBS“-Muster. Der Versuch, EBS breit über Instanzen hinweg anzuhängen (z. B. hinter einem Load Balancer), ist ein Kategorienfehler, der genau das Symptom hervorruft, dass „einige Dokumente nach dem Aktualisieren sichtbar sind, andere nicht“, da jedes Volume ein privates Block-Gerät ist.

EBS-Volumes werden im Ruhezustand (at rest) mit AES-256 verschlüsselt, wobei von KMS umschlossene Datenschlüssel verwendet werden. Die Verschlüsselung ist transparent – keine Leistungseinbußen, keine Anwendungsänderungen. Sobald ein Volume verschlüsselt ist, sind auch abgeleitete Snapshots und Volumes verschlüsselt; eine Entschlüsselung vor Ort ist nicht möglich. Aktivieren Sie die EBS-Verschlüsselung standardmäßig pro Region, damit jedes neue Volume und jeder neue Snapshot verschlüsselt wird, unabhängig davon, ob der Entwickler daran denkt:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Bestehende unverschlüsselte Volumes werden nicht rückwirkend verschlüsselt – die Behebung erfordert einen Snapshot, das Kopieren mit Verschlüsselung und die Erstellung eines Volumes aus dem verschlüsselten Snapshot.

Snapshots sind inkrementelle Backups auf Blockebene, die auf von S3 verwalteter Infrastruktur gespeichert werden – aber sie sind nicht kostenlos (man bezahlt für die beibehaltenen geänderten Blöcke), sie verschwinden nicht, wenn das Quell-Volume gelöscht wird, und sie werden nicht entfernt, wenn ein AMI, das auf sie verweist, deregistriert wird. Lagern Sie sie über aws ec2 modify-snapshot-tier, den Amazon Data Lifecycle Manager (DLM) oder AWS Backup in die Tier-Klasse EBS Snapshots Archive aus (75 % günstiger, 24–72 Stunden Wiederherstellungszeit). Fast Snapshot Restore (FSR) wärmt einen Snapshot in bestimmten AZs vor, sodass Instanzen, die daraus gestartet werden, sofort die volle Leistung erbringen – aktivieren Sie dies für AMIs hinter Auto-Scaling-Gruppen, die schnelle Scale-Out-Vorgänge bewältigen müssen.

Der Recycle Bin (Papierkorb) fängt gelöschte EBS-Snapshots und AMIs auf und bewahrt sie für ein Wiederherstellungsfenster (1 Tag bis 1 Jahr) auf. Ohne ihn ist die Löschung von Snapshots sofort und endgültig:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Sich allein auf tägliche EBS-Snapshots für die langfristige Aufbewahrung zur Einhaltung von Compliance-Vorschriften zu verlassen, ist ein häufiger Architekturfehler – Snapshots liegen preislich eher im Bereich von Warm-Storage und erfordern explizite Übergänge zur Archivierung.

Amazon EFS: Geteiltes POSIX für Linux-Flotten

EFS ist ein vollständig verwaltetes, elastisches, POSIX-konformes NFSv4.1-Dateisystem, das gleichzeitig von Tausenden von EC2-, ECS-, EKS- oder Lambda-Clients über mehrere AZs in einer Region hinweg und von On-Premises-Hosts über Direct Connect oder VPN gemountet werden kann. Die entscheidende Eigenschaft ist, dass dasselbe Dateisystem mit identischen File-Handles und Semantik auf Byte-Ebene für jeden Client gleichzeitig sichtbar ist. EFS ist daher die richtige Antwort, wenn eine Linux-Flotte hinter einem Load Balancer einen gemeinsamen Satz von Dateien gemeinsam nutzen muss – Benutzer-Uploads, Konfigurationsdateien, gemeinsam genutzte Home-Verzeichnisse.

Mount-Ziele (Mount Targets) befinden sich in jedem AZ-Subnetz, das Sie konfigurieren. Das Hilfsprogramm amazon-efs-utils ermöglicht TLS-Verschlüsselung während der Übertragung (in transit) und die Mount-Autorisierung über IAM:

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

EFS-Speicherklassen erstrecken sich über zwei Dimensionen. Lifecycle-Management stuft Dateien, auf die 7–90 Tage nicht zugegriffen wurde, von Standard nach Infrequent Access und optional nach Archive herab, was die Speicherkosten um bis zu 92 % senkt; Intelligent-Tiering verschiebt sie bei Zugriff wieder zurück. One Zone-Klassen speichern Daten für ca. 47 % weniger Kosten in einer einzigen AZ – geeignet für Entwicklungs-/Testumgebungen oder reproduzierbare Daten, niemals für Daten, deren Verlust bei einem AZ-Ausfall inakzeptabel ist. Eine Maßnahme zur Kostenoptimierung für einen Workload, der bereits auf EFS Standard-IA läuft, ist der Wechsel zu EFS One Zone-IA ohne Anwendungsänderungen.

Die Leistung hat zwei unabhängige Stellschrauben. Leistungsmodus (wird bei der Erstellung festgelegt): General Purpose (Allgemein) hat die niedrigste Latenz und ist die richtige Wahl für Web-Serving mit vielen Metadaten; Max I/O (Maximaler I/O) ist eine veraltete Option, die durch Elastic ersetzt wurde. Durchsatzmodus: Bursting skaliert mit der Größe (50 KB/s pro GB als Basis, Burst-Guthaben bei Unterschreitung der Basis), Provisioned (Bereitgestellt) bezahlt für eine feste MB/s-Rate unabhängig von der Größe, und Elastic – der aktuelle Standard – skaliert automatisch auf über 10 GB/s ohne Kapazitätsplanung. Ein sehr kleines Dateisystem unter Dauerlast kann sein Burst-Guthaben aufbrauchen und auf eine niedrige Basisleistung gedrosselt werden, daher müssen Workloads mit hohem I/O-Aufkommen und geringem Speicherbedarf Elastic oder Provisioned verwenden.

EFS ist kein Ersatz für Blockspeicher mit hohen IOPS. Jeder EFS-I/O ist ein NFS-RPC über das Netzwerk, daher gehören Workloads im Stil von Transaktionsprotokollen mit einem einzigen Schreiber (Single-Writer) und Latenzen im Sub-Millisekundenbereich auf EBS io2 Block Express – ein einziges Volume liefert 256.000 IOPS bei Sub-Millisekunden-Latenz, was EFS pro Operation nicht erreichen kann. EFS ist im Vergleich zu Deep Archive auch für kalte Daten extrem überteuert; Compliance-Daten auf EFS zu speichern, „weil es einfach ist“, ist nicht zu rechtfertigen.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx ist eine Familie von verwalteten Dateisystemen, die nach Protokoll und Workload ausgewählt werden:

FSx for Windows File Server liefert natives SMB 2.0/3.1.1 mit NTFS ACLs, DFS Namespaces, Schattenkopien und Kerberos über Active Directory. Multi-AZ-Bereitstellungen umfassen einen aktiven Dateiserver in einer AZ mit einem synchron replizierten Standby-Server in einer anderen und einem einzigen Failover-DNS-Namen. Die AD-Integration ist nicht optional: FSx muss einem AWS Managed Microsoft AD oder einem erreichbaren, selbstverwalteten AD beitreten, und Clients authentifizieren sich als Domänenbenutzer gegenüber Domänen-SIDs. Das Überspringen der AD-Integration oder das Verweisen von Clients auf ein Dateisystem in einer nicht vertrauenswürdigen Gesamtstruktur ohne eine gesamtstrukturübergreifende Vertrauensstellung führt zum klassischen Symptom „Zugriff verweigert, obwohl die Freigabe sichtbar ist“. FSx for Windows ist das direkte Ziel für den Lift-and-Shift von Windows-Dateifreigaben.

FSx for Lustre ist ein paralleles POSIX-Dateisystem für HPC, ML-Training, EDA und Genomik – Tausende von Clients, Hunderte von GB/s Durchsatz, Metadaten-Zugriff im Sub-Millisekunden-Bereich. Sein entscheidendes AWS-Merkmal ist die Data Repository Association mit S3: Objektschlüssel erscheinen als Dateien im Lustre-Namespace und werden beim ersten Zugriff verzögert geladen (oder über hsm_restore vorab geladen); neue/geänderte Dateien werden nach Zeitplan oder bei Bedarf zurück nach S3 exportiert. Das kanonische HPC-Muster ist:

1. Kopieren Sie On-Premises-Datensätze nach S3 (über DataSync oder Storage Gateway).
2. Erstellen Sie ein Lustre-Dateisystem, das mit diesem Bucket verknüpft ist.
3. Mounten Sie es auf allen Spot-Workern; lesen Sie Eingaben und schreiben Sie Ausgaben mit Leitungsgeschwindigkeit.
4. Exportieren Sie die Ergebnisse nach S3, das als dauerhaftes Langzeit-Repository dient.
5. Löschen Sie das Lustre-Dateisystem, wenn der Job beendet ist.

Lustre-Scratch-Bereitstellungen haben keine Replikation und verlieren Daten bei einem Hardwareausfall – sie sind am günstigsten und schnellsten und eignen sich für transiente Job-Daten. Persistent-Bereitstellungen replizieren innerhalb einer AZ für höhere Dauerhaftigkeit. Der Durchsatz wird in MB/s pro TiB (50/125/250/500/1000) provisioniert, was die Kapazität von der Leistung entkoppelt.

FSx for NetApp ONTAP ist die Multiprotokoll-Lösung: NFS, SMB und iSCSI gleichzeitig auf denselben Daten, mit Snapshots, SnapMirror-Replikation, FlexClones und Deduplizierung. Wählen Sie ONTAP, wenn Sie gemischte Linux-NFS- und Windows-SMB-Freigaben konsolidieren, die protokollübergreifenden Zugriff mit Multi-AZ-Redundanz benötigen, oder wenn Sie von On-Premises-NetApp migrieren. FSx for OpenZFS füllt eine Nische für Linux-Workloads, die ZFS-Funktionen (Snapshots, Klone) über NFS benötigen. Verwechseln Sie die Multiprotokoll-Stärke von ONTAP nicht mit den anderen Varianten.

Treffen Sie die falsche Wahl, schlägt der Versuch eindeutig fehl: EBS für einen gemeinsam genutzten Workload, EFS für eine Windows-SMB-Freigabe oder Lustre für eine AD-integrierte Windows-Freigabe sind allesamt unpassend – stimmen Sie zuerst Protokoll und Zugriffsmuster ab.

Storage Gateway: Hybrider Zugriff

Storage Gateway präsentiert Cloud-Speicher, als wäre er lokal. Dies unterscheidet sich von DataSync, das Daten verschiebt.

Für eine Rendering-Anwendung, die ihre Medienbibliothek nach S3 verschoben hat, aber weiterhin On-Premises-Lesevorgänge mit niedriger Latenz benötigt, ist S3 File Gateway die passende Lösung – NFS/SMB-Zugriff, lokaler Cache, kalte Objekte werden bei Bedarf von S3 abgerufen. FSx File Gateway ist die Lösung für Zweigstellen: ein SMB-Cache mit LAN-Geschwindigkeit für eine zentrale FSx-Freigabe in der Cloud, keine Lösung für den gemeinsamen Zugriff zwischen EC2-Instanzen (diese sollten FSx direkt mounten). Volume Gateway kommt zum Einsatz, wenn der Workload Block-iSCSI anstelle von Dateisemantik verwendet. Tape Gateway ersetzt physische Bandbibliotheken unter bestehender Backup-Software.

Datenübertragung und Migration

AWS DataSync ist eine agentenbasierte Online-Migration für NFS-, SMB-, HDFS- und Objektspeicher nach S3, EFS oder FSx – bis zu 10-mal schneller als Open-Source-Tools, mit Verschlüsselung, Integritätsprüfung, Zeitplanung und Beibehaltung von POSIX-Metadaten und NTFS-ACLs. Für eine groß angelegte SMB-Migration mit Millionen kleiner Dateien und tiefen Hierarchien ist die Lösung mit dem geringsten Overhead DataSync nach FSx for Windows: SMB wird beibehalten, ACLs/Zeitstempel bleiben intakt, der Durchsatz bei kleinen Dateien wird durch parallele Übertragungen bewältigt, keine Anwendungsänderungen erforderlich. Die direkte Migration eines solchen Datensatzes nach S3 ist eine Falle – Objektspeicher gehen schlecht mit der Auflistung kleiner Dateien in tiefen Präfixen um, und SMB-Clients können keine Buckets mounten.

AWS Snow Family liefert physische Appliances für die Offline-Übertragung: Snowcone (bis zu 8 TB, Edge-robust), Snowball Edge (bis zu ~80 TB nutzbar, mit Rechenoptionen) und Snowmobile (Exabyte-Bereich). Als Faustregel gilt: Wenn die Netzwerkübertragung länger als eine Woche dauern würde, ist Snowball günstiger und schneller.

AWS Transfer Family stellt SFTP, FTPS, FTP und AS2 bereit, die durch S3 oder EFS unterstützt werden – die richtige Lösung, wenn externe Partner weiterhin Standard-Dateiübertragungsprotokolle verwenden müssen.

AWS Backup, regionsübergreifende Kopie und Vault Lock

AWS Backup zentralisiert Richtlinien für EBS, EFS, FSx, RDS, DynamoDB, S3 und weitere Dienste. Ein Backup-Plan definiert den Zeitplan, die Warm-Aufbewahrung, den Übergang zum Cold Storage sowie Aktionen für regions- und kontoübergreifende Kopien:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

Der Übergang zum Cold Storage erfordert mindestens 90 Tage Warm-Aufbewahrung plus mindestens 90 Tage im Cold Storage; falsch konfigurierte Lebenszyklen werden abgelehnt. Für eine echte mehrjährige, regulatorisch vorgeschriebene Aufbewahrung kombinieren Sie dies mit AWS Backup Vault Lock (WORM), das selbst Administratoren daran hindert, die Aufbewahrungsfrist zu verkürzen – und erfüllt damit SEC 17a-4 und ähnliche Vorschriften. Die regionsübergreifende Kopie dient dem regionalen DR (Disaster Recovery); die kontoübergreifende Kopie schützt vor Ransomware- und Insider-Bedrohungsszenarien, indem sie die Backups vom Blast Radius des Produktivkontos isoliert.

Entscheidungshilfe

← Serverless · Alle Domänen · Datentransfer →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →