Versionierung, MFA Delete und Replikation

S3-Versionierung ermöglicht es Ihnen, jede Version jedes in einem Bucket gespeicherten Objekts aufzubewahren, abzurufen und wiederherzustellen. Wenn die Versionierung aktiviert ist, erstellt jedes PUT eine neue Version mit einer eindeutigen Versions-ID; die alte Version wird beibehalten und nicht überschrieben. Wenn ein Objekt gelöscht wird, fügt S3 einen Löschmarker als aktuelle Version hinzu, behält jedoch alle vorherigen Versionen bei. Das schützt vor versehentlichem Überschreiben, versehentlichem Löschen und unbeabsichtigter Datenbeschädigung auf Anwendungsebene, den häufigsten Szenarien für Datenverlust in Produktionsumgebungen.

Ein S3-Bucket kann sich in einem von drei Versionierungszuständen befinden: Unversioned (Standard, keine Versions-IDs), Versioning-enabled (alle neuen Objekte erhalten eindeutige Versions-IDs, jedes Überschreiben erstellt neue Versionen) oder Versioning-suspended (neue Objekte erhalten eine Null-Versions-ID, vorhandene Versionen bleiben jedoch erhalten). Nachdem Sie die Versionierung aktiviert haben, können Sie sie nicht löschen, sondern nur aussetzen. Objekte, die vor der Aktivierung der Versionierung erstellt wurden, haben die Versions-ID null und sind nicht betroffen, bis sie überschrieben oder gelöscht werden.

Um eine ältere Version eines versionierten Objekts wiederherzustellen, haben Sie zwei Möglichkeiten. Option 1: Kopieren Sie die ältere Versions-ID zurück auf denselben Schlüssel. Dadurch wird eine neue Version erstellt, die eine Kopie des älteren Inhalts ist und zur aktuellen Version wird. Option 2: Löschen Sie die aktuelle Version oder den Löschmarker, damit die vorherige Version als aktuell angezeigt wird. Wenn Sie ein Objekt in einem versionierten Bucket über die Konsole „löschen“, ohne eine Versions-ID anzugeben, fügt S3 einen Löschmarker hinzu. Für nicht versionierte Anfragen erscheint das Objekt als gelöscht, aber alle Versionen sind weiterhin vorhanden.

MFA Delete fügt für versionierte Buckets eine zweite Schutzebene hinzu. Wenn es aktiviert ist, müssen Sie beim dauerhaften Löschen einer bestimmten Version oder beim Ändern des Versionierungszustands des Buckets (aktiviert → ausgesetzt) in der API-Anfrage gültige MFA-Anmeldedaten angeben. Das schützt vor einem Angreifer, der Ihre AWS-Anmeldedaten kompromittiert hat und kritische Versionen dauerhaft löscht, vor versehentlichem oder automatisiertem Löschen festgeschriebener Objektversionen sowie vor Insider-Bedrohungen, die Audit-Trails zerstören möchten. MFA Delete kann nur vom Root-Benutzer über die CLI aktiviert und deaktiviert werden.

S3 Object Lock erzwingt für regulatorische Compliance ein Write-Once-Read-Many-Modell (WORM). Mit Object Lock gesperrte Objekte können während eines festgelegten Aufbewahrungszeitraums nicht gelöscht oder überschrieben werden, auch nicht vom Root-Benutzer des Kontos. Es gibt zwei Modi: Governance-Modus (Benutzer mit speziellen Berechtigungen können die Sperre überschreiben oder entfernen) und Compliance-Modus (niemand, nicht einmal AWS, kann das Objekt während des Aufbewahrungszeitraums löschen; dies ist der stärkste Schutz). Object Lock muss bei der Erstellung des Buckets aktiviert werden und erfordert Versionierung.

Cross-Region Replication (CRR) repliziert neue Objekte und Aktualisierungen automatisch von einem Quell-Bucket in einer Region in einen Ziel-Bucket in einer anderen Region. Anwendungsfälle: Compliance (eine Datenkopie in einem bestimmten Land aufbewahren), Disaster Recovery (den RPO für kritische Daten durch eine Kopie in einer zweiten Region reduzieren) und Latenzreduzierung (Objekte aus der Region bereitstellen, die den Benutzern am nächsten liegt). CRR erfordert aktivierte Versionierung sowohl für den Quell- als auch den Ziel-Bucket sowie eine IAM-Rolle mit den erforderlichen Replikationsberechtigungen.

Same-Region Replication (SRR) repliziert Objekte innerhalb derselben Region. Anwendungsfälle: Log-Aggregation (Logs aus mehreren Quell-Buckets in einen zentralen Bucket replizieren), Synchronisierung der Testumgebung (eine Kopie der Produktionsdaten in einem Dev-Bucket innerhalb derselben Region beibehalten) und Compliance mit Datensouveränität innerhalb eines einzelnen Landes mit mehreren AWS-AZs. Wie CRR erfordert auch SRR Versionierung für beide Buckets und eine IAM-Rolle. Nur neue Objekte, die nach der Aktivierung der Replikation erstellt werden, werden automatisch repliziert. Verwenden Sie S3 Batch Replication, um vorhandene Objekte zu replizieren.

S3-Replikation repliziert Folgendes: neue Objekte, Metadaten, Tags, ACLs und Verschlüsselungsstatus. Standardmäßig repliziert die Replikation Folgendes nicht: Objekte, die bereits vor der Aktivierung der Replikation vorhanden waren (verwenden Sie dafür S3 Batch Replication), Löschmarker (außer wenn Sie Delete Marker Replication aktivieren), Objekte in Glacier (nicht replizierbar, stellen Sie sie zuerst wieder her) und replizierte Objekte (keine kaskadierende Replikation zwischen drei Buckets). Diese Grenzen zu verstehen, ist wichtig, um vollständige DR-Strategien zu entwerfen, bei denen auch historische Daten und Löschereignisse repliziert werden müssen.

Replication Time Control (RTC) ist eine optionale Erweiterung für CRR mit einem Service Level Agreement: 99,99 % der Objekte werden innerhalb von 15 Minuten repliziert, einschließlich Replikationsmetriken und Benachrichtigungen in CloudWatch. Ohne RTC gibt es keine Zeitgarantie für die Replikation. Die meisten Objekte werden schnell repliziert, Ausreißer können jedoch Stunden dauern. RTC ist unverzichtbar, wenn Ihre Anforderungen an DR oder Compliance ein maximales Recovery Point Objective (RPO) für Daten in S3 festlegen. Zusätzlich zu den Standardkosten für die Datenübertragung bei der Replikation fällt eine Replikationsgebühr pro GB an.

Das Aktivieren der Versionierung erhöht die Speicherkosten, da S3 jede Version jedes Objekts aufbewahrt, bis sie ausdrücklich gelöscht wird. Eine 100 MB große Datei, die zehnmal überschrieben wird, belegt dann 1.000 MB Speicher. Sie können dies mit Lifecycle-Regeln vermeiden, die nicht aktuellen Versionen nach einer festgelegten Anzahl von Tagen automatisch ablaufen lassen (z. B. nicht aktuelle Versionen löschen, die älter als 30 Tage sind), oder indem Sie nicht aktuelle Versionen in günstigere Speicherklassen wie Glacier verschieben. Kombinieren Sie die Versionierung in Produktionsumgebungen immer mit Lifecycle-Regeln, um die Speicherkosten zu kontrollieren.

Die Kombination aus S3-Versionierung und Object Lock (Compliance-Modus) bietet einen starken Schutz vor Ransomware. Wenn ein Angreifer Ihre Objekte verschlüsselt oder löscht, stellt die Versionierung sicher, dass frühere Versionen erhalten bleiben (es sei denn, der Angreifer löscht sie dauerhaft – genau deshalb verhindert Object Lock während des Aufbewahrungszeitraums das dauerhafte Löschen). Für maximalen Schutz aktivieren Sie die Versionierung und MFA Delete, wenden Sie Object Lock im Compliance-Modus auf kritische Daten an und replizieren Sie die Daten in eine zweite Region mit separaten IAM-Anmeldedaten. So kann die Kompromittierung eines einzelnen Kontos nicht alle Kopien zerstören.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Die Versionierung bewahrt alle Versionen jedes Objekts auf und schützt vor versehentlichem Löschen, MFA Delete und Object Lock sorgen für zusätzliche Unveränderbarkeit zur Einhaltung von Compliance-Anforderungen und zum Schutz vor Ransomware und CRR und SRR replizieren Objekte in andere Buckets, um Anforderungen an Disaster Recovery und Compliance zu erfüllen. Als Nächstes sehen wir uns die S3-Speicherklassen und Lifecycle-Richtlinien zur Kostenoptimierung an.