S3-Speicherklassen erklärt: Die richtige Option für Kosteneffizienz wählen

Amazon Simple Storage Service (S3) ist der Standard-Objektspeicher für viele AWS-Workloads, da er gut skalierbar ist und mehrere Speicherklassen für verschiedene Zugriffsmuster bietet. Allerdings wird nicht auf alle Daten gleich häufig zugegriffen. Das Speichern häufig abgerufener, geschäftskritischer Daten in derselben Klasse wie selten abgerufene Archivdaten kann zu erheblichen, unnötigen Cloud-Ausgaben führen. Das Verständnis der Nuancen zwischen den verschiedenen S3-Speicherklassen ist entscheidend für die Gestaltung einer kostenoptimierten Architektur.

Grundlegendes zur Haltbarkeit und Verfügbarkeit von S3

Bevor wir auf die Klassen eingehen, ist es wichtig, zwei Kernmetriken für S3 zu definieren:

• Haltbarkeit: Die Wahrscheinlichkeit, dass Ihre Daten im Laufe der Zeit intakt bleiben. S3 ist für eine 99,999999999% (11 Neunen) Haltbarkeit über die für eine bestimmte Klasse verwendete Infrastruktur ausgelegt.
• Verfügbarkeit: Der Prozentsatz der Zeit, in der Ihre Daten für den Abruf zugänglich sind. Dies wird normalerweise jährlich gemessen (z. B. 99,9%).

Diese Metriken variieren je nach gewählter Speicherklasse geringfügig.

Die wichtigsten S3-Speicherklassen: Ein detaillierter Vergleich

AWS bietet mehrere Speicherklassen, die für unterschiedliche Zugriffshäufigkeiten und Toleranzen gegenüber Ausfallzeiten optimiert sind. Hier ist ein detaillierter Blick auf die gängigsten Optionen.

1. S3 Standard

S3 Standard ist die Standard- und Allzweck-Speicherklasse, die sich am besten für häufig abgerufene Daten eignet.

• Anwendungsfall: Aktive Daten, Content Distribution, dynamisch generierte Inhalte sowie Mobile- und Gaming-Anwendungen.
• Haltbarkeit: 11 Neunen.
• Verfügbarkeit: 99,99% (Hohe Verfügbarkeit).
• Abrufzeit: Millisekunden.
• Preisgestaltung: Höchste Speicherkosten unter den häufig abgerufenen Stufen, aber keine Abrufgebühren.

Best Practice: Verwenden Sie dies für Daten, die sofortigen Zugriff mit minimaler Latenz benötigen.

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tiering ist für Daten mit unbekannten oder sich ändernden Zugriffsmustern konzipiert. Es verschiebt Objekte basierend auf der Nutzung automatisch zwischen zwei oder mehr Zugriffsstufen und optimiert so die Speicherkosten ohne betrieblichen Aufwand.

• Anwendungsfall: Data Lakes, Daten mit unvorhersehbaren Zugriffsmustern oder wenn Sie sofortigen Zugriff gewährleisten und gleichzeitig die Kosten im Laufe der Zeit optimieren möchten.
• Funktionsweise: Es überwacht den Zugriff. Wenn auf ein Objekt 30 aufeinanderfolgende Tage nicht zugegriffen wurde, wird es in die Stufe für seltenen Zugriff (IA) verschoben. Wenn erneut darauf zugegriffen wird, wird es zurück in die Stufe für häufigen Zugriff verschoben.
• Enthaltene Stufen: Häufiger Zugriff, Seltener Zugriff, Archiv-Sofortzugriff (optional).
• Kostenfaktor: Beinhaltet eine kleine monatliche Gebühr für Überwachung und Automatisierung pro Objekt, zusätzlich zu den Speicherkosten, die sich je nach Stufe, in der sich das Objekt befindet, ändern.

Handlungsempfehlung: Wenn Sie sich nicht sicher sind, wie oft auf Daten zugegriffen wird, bietet S3 Intelligent-Tiering oft die beste Balance zwischen Kosteneinsparungen und Leistungskonsistenz.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Diese Klasse ist ideal für Daten, auf die selten zugegriffen wird, die aber einen schnellen Abruf erfordern, ähnlich wie S3 Standard-IA, jedoch mit einem wesentlichen Unterschied in der Verfügbarkeit.

• Anwendungsfall: Sekundäre Backups, reproduzierbare Daten (z. B. Daten, die aus einer Quelle neu generiert werden können) oder das Speichern von Daten, die nicht geschäftskritisch genug sind, um eine Multi-AZ-Redundanz zu rechtfertigen.
• Haltbarkeit: 11 Neunen.
• Verfügbarkeit: 99,5% (Geringere Verfügbarkeit als Standard).
• Speicherort: Daten werden redundant über eine einzelne AWS Availability Zone (AZ) gespeichert, im Gegensatz zu anderen Klassen, die sich über mehrere AZs erstrecken.
• Kostenfaktor: Deutlich niedrigere Speicherkosten als Standard, aber der Datenabruf verursacht eine Gebühr.

⚠️ Warnung zu One Zone-IA: Da sich die Daten nur in einer AZ befinden, könnten Ihre Daten in dieser Stufe verloren gehen, wenn diese bestimmte AZ ein katastrophales Ereignis erleidet (z. B. einen größeren Stromausfall oder eine Naturkatastrophe). Deshalb ist es nur für nicht kritische, leicht ersetzbare Daten geeignet.

4. S3 Glacier-Speicherklassen (Archivierung)

Glacier-Speicherklassen sind für die langfristige Archivierung optimiert, bei der Abrufzeiten von Minuten bis Stunden akzeptabel sind.

S3 Glacier Instant Retrieval (S3 Glacier IR)

Dies schließt die Lücke zwischen seltenem Zugriff und Tiefenarchivierung.

• Anwendungsfall: Daten, auf die vierteljährlich oder seltener zugegriffen wird, aber bei Bedarf Millisekunden-Abruf erfordern (z. B. medizinische Bilder, Nachrichtenmedienarchive).
• Abrufzeit: Millisekunden (ähnliche Latenz wie IA-Klassen).
• Kostenfaktor: Sehr niedrige Speicherkosten, mit Abrufgebühren.

S3 Glacier Flexible Retrieval (ehemals S3 Glacier)

Dies ist eine Option für die langfristige Archivierung, wenn ein Abruf in Minuten bis Stunden akzeptabel ist.

• Anwendungsfall: Aufbewahrungsarchive für die Einhaltung gesetzlicher Vorschriften, Disaster-Recovery-Daten, die selten, wenn überhaupt, benötigt werden.
• Abrufoptionen (und Latenz):
  • Beschleunigt: 1–5 Minuten
  • Standard: 3–5 Stunden
  • Bulk: 5–12 Stunden
• Kostenfaktor: Extrem niedrige Speicherkosten, aber Abrufgebühren fallen an und benötigen Zeit.

S3 Glacier Deep Archive

Die absolut kostengünstigste Speicheroption in AWS S3.

• Anwendungsfall: Daten, auf die vielleicht nur ein- oder zweimal pro Jahr zugegriffen wird, typischerweise zur Einhaltung von Vorschriften.
• Abrufoptionen (und Latenz):
  • Standard: 12 Stunden
  • Bulk: 48 Stunden
• Kostenfaktor: Niedrigste Speicherrate verfügbar, höchste Abrufgebühren und längste erforderliche Abruffenster.

Wie man wählt: Ein Entscheidungsrahmen

Die Auswahl der richtigen Klasse hängt von der Beantwortung von drei Schlüsselfragen zu Ihrem Datenlebenszyklus ab:

Frage	Primäre Überlegung	Empfohlener Klassenpfad
Wie oft wird darauf zugegriffen?	Zugriffshäufigkeit	Häufig $\rightarrow$ Standard; Selten $\rightarrow$ IA oder Glacier
Welche Ausfallzeit/Verlust ist akzeptabel?	Haltbarkeit/Verfügbarkeit	Kritisch $\rightarrow$ Standard/Intelligent-Tiering; Entbehrlich $\rightarrow$ One Zone-IA
Wie schnell muss ich es abrufen?	Latenzanforderung	Millisekunden $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR; Stunden $\rightarrow$ Glacier Flexible/Deep Archive

Beispielszenario: Medien-Assets eines Unternehmens

Ein Marketing-Team lädt täglich Hunderte von rohen Videodateien hoch:

1. Aktuelle Bearbeitungen/Promos (letzte 30 Tage): S3 Standard (Hoher Zugriff, niedrige Latenz).
2. Ältere Assets, die gelegentlich überprüft werden müssen (30 Tage bis 1 Jahr): S3 Intelligent-Tiering (Um Kosteneinsparungen nach der anfänglichen heißen Phase zu erzielen).
3. Abgeschlossene, geprüfte Endmaster (älter als 1 Jahr): S3 Glacier Deep Archive (Niedrigste Kosten, nur für Compliance-Audits erforderlich).

Beispielszenario: Protokolle, Backups und Benutzer-Uploads

Ein einzelnes Unternehmen hat oft drei sehr unterschiedliche S3-Muster.

Bei Anwendungsprotokollen sind aktuelle Daten wertvoll, da Ingenieure sie bei Vorfällen durchsuchen. Nach Ablauf des Vorfallfensters werden die meisten Protokolle zu Compliance- oder Trenddaten. Ein sinnvoller Lebenszyklus könnte 30 bis 90 Tage in Standard oder Standard-IA belassen, ältere Protokolle in eine Archivstufe verschieben und minderwertige Debug-Protokolle nach einer festgelegten Aufbewahrungsfrist löschen. Die genauen Zahlen sollten aus Ihrer Aufbewahrungsrichtlinie und der Häufigkeit, mit der Personen wirklich alte Präfixe abfragen, stammen.

Bei Datenbank-Backups sollte die Speicherklasse dem Wiederherstellungsversprechen folgen. Wenn das Team sagt, dass eine Produktionswiederherstellung innerhalb von Minuten beginnen muss, bewahren Sie die neuesten Backups in einer Klasse mit sofortigem Abruf auf. Ältere monatliche oder jährliche Kopien können kälter verschoben werden, wenn sie eher für die Audit-Aufbewahrung als für die schnelle Wiederherstellung gedacht sind. Testen Sie Wiederherstellungen aus der gewählten Klasse; eine Backup-Richtlinie, die noch nie wiederhergestellt wurde, ist meistens eine Abrechnungsregel.

Bei Benutzer-Uploads ist der Zugriff schwerer vorherzusagen. Ein Profilfoto könnte winzig sein, aber ständig abgerufen werden. Ein großes Originalvideo könnte einmal heruntergeladen, transcodiert und dann kaum noch angefasst werden. Speichern Sie abgeleitete Assets und Originale unter separaten Präfixen, damit Lebenszyklusregeln sie unterschiedlich behandeln können. Lassen Sie nicht zu, dass die Miniaturbild-Richtlinie dieselbe Archivregel wie mehr Gigabyte große Originale erbt, es sei denn, das Produkt erfordert dies wirklich.

Fragen vor der Änderung eines Buckets

Bevor Sie eine Lebenszyklusregel hinzufügen, fragen Sie, wer die Daten liest, wie sie gelesen werden und was passiert, wenn der Abruf verzögert wird. Ingenieure kennen oft den Schreibpfad besser als den Lesepfad, da Uploads Teil der Anwendung sind, während Lesevorgänge später durch Analysen, Support-Tools, Compliance-Exporte oder manuelle Incident-Response erfolgen.

Achten Sie auf Batch-Jobs, die alte Präfixe scannen. Ein nächtlicher Job, der jedes Objekt auflistet, Metadaten öffnet oder alte Dateien sampelt, kann einen Teil der Einsparungen aus einer kälteren Klasse zunichtemachen. Wenn der Job nur ein Manifest benötigt, ist S3 Inventory möglicherweise besser geeignet als das wiederholte Auflisten des Buckets. Wenn Analysten Protokolle mit Athena abfragen, berücksichtigen Sie die Partitionsstruktur und Komprimierung, bevor Sie Daten in eine Klasse verschieben, die Wiederherstellungsschritte erfordert.

Achten Sie auf die Objektgröße. Speicherklassen mit minimalen abrechenbaren Objektgrößen können für eine große Anzahl winziger Dateien ungeeignet sein. In solchen Fällen kann das Komprimieren von Daten in größere Objekte, die Verwendung von Parquet für Analysen oder das Löschen unnötiger Objekte besser sein als ein Wechsel der Speicherklasse.

Schreiben Sie Lebenszyklusregeln schließlich so, dass Sie sie während eines Vorfalls erklären können. Eine Präfixregel mit dem Namen archive-old-logs-after-90-days ist einfacher zu durchschauen als eine Bucket-weite Regel, die stillschweigend alles nach 30 Tagen verschiebt. Kostenoptimierung sollte das System billiger machen, ohne die Wiederherstellung rätselhaft zu gestalten.

Eine weitere praktische Überprüfung ist die Eigentümerschaft. In echten Konten sind der Bucket-Besitzer, das hochladende Konto, die Replikationsrolle und das Analyse-Konto nicht immer identisch. Bevor Sie Daten in eine Archivklasse verschieben, bestätigen Sie, wer sie wiederherstellen kann und wer für den Abruf bezahlt. Buckets mit KMS-Verschlüsselung über Konten hinweg können bei der Wiederherstellung fehlschlagen, wenn die Rolle, die das Objekt benötigt, den Bucket auflisten, aber den Schlüssel nicht verwenden kann. Das ist eine böse Überraschung während eines Audits.

Auch die Versionierung ändert die Berechnung. Lebenszyklusregeln können aktuelle und nicht aktuelle Versionen unterschiedlich überführen oder ablaufen lassen. Wenn eine Anwendung denselben Schlüssel jede Stunde überschreibt, können nicht aktuelle Versionen zum größten Teil des Buckets werden. Überprüfen Sie diese separat, anstatt anzunehmen, dass die aktuelle Objektanzahl die ganze Geschichte erzählt.

Implementierung von Lebenszyklusrichtlinien

Das manuelle Verschieben von Objekten zwischen Klassen ist ineffizient. Der effektivste Weg, Kosten über diese Stufen hinweg zu verwalten, ist die Verwendung von S3-Lebenszyklusrichtlinien.

Lebenszyklusrichtlinien ermöglichen es Ihnen, Regeln zu definieren, die Objekte automatisch in kältere Speicherstufen überführen oder nach einer definierten Anzahl von Tagen endgültig löschen.

Beispiel für eine Lebenszyklusregel (Überführung):

<Rule>
    <ID>Move_to_IA_After_30_Days</ID>
    <Status>Enabled</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

Diese Konfiguration verschiebt automatisch jedes Objekt im Präfix logs/ 30 Tage nach der Erstellung in Glacier Instant Retrieval, wodurch die langfristigen Speicherkosten erheblich gesenkt werden, während bei Bedarf schnelle Abruffähigkeiten erhalten bleiben.

Kostenfallen, die übersehen werden

Die Entscheidung für eine Speicherklasse ist nicht nur ein monatlicher Vergleich pro GB. Abrufgebühren, Anforderungsgebühren, Mindestspeicherdauer, minimale abrechenbare Objektgröße, Replikation, Lebenszyklus-Überführungsanfragen und Überwachungsgebühren können die Antwort ändern. Ein winziges Objektarchiv mit Millionen von Schlüsseln kann sich ganz anders verhalten als eine kleine Anzahl großer Backup-Dateien.

Beispielsweise werden Anwendungsprotokolle oft einmal geschrieben und selten gelesen, daher kann eine Lebenszyklusregel von Standard zu Glacier Instant Retrieval oder Glacier Flexible Retrieval sinnvoll sein. Wenn Ihr Incident-Prozess jedoch häufig alte Protokolle mit Athena scannt, kann eine aggressive Archivierung zu langsamen Wiederherstellungen und überraschenden Abrufkosten führen. In diesem Fall kann das Partitionieren von Protokollen nach Datum, das Löschen von lauten, minderwertigen Präfixen und das Aufbewahren aktueller Monate in einer abfragefreundlichen Klasse mehr Geld sparen, als blindlings alles nach 30 Tagen kalt zu stellen.

Backups haben eine andere Form. Ein Datenbank-Dump, den Sie einmal im Monat testen, benötigt ein vorhersagbares Wiederherstellungsverhalten. Wenn Ihr Recovery Time Objective in Minuten gemessen wird, ist Deep Archive wahrscheinlich der falsche Ort für die einzige wiederherstellbare Kopie, selbst wenn es im Ruhezustand billig ist. Wenn derselbe Dump die dritte Kopie ist, die nur für die Audit-Aufbewahrung aufbewahrt wird, kann Deep Archive angemessen sein.

Medienteams benötigen oft unvorhersehbar alte Assets. Intelligent-Tiering kann eine gute Standardeinstellung für diese unbekannten Muster sein, insbesondere wenn die Objekte groß genug sind, dass die Überwachungsgebühr nicht der entscheidende Faktor ist. Bei einer großen Anzahl winziger Miniaturbilder verdienen die Gebühr und das Verhalten der Mindestobjektgröße eine genauere Betrachtung, bevor Sie es überall aktivieren.

Ein praktischer Weg zur Auswahl besteht darin, einen Bucket zu sampeln, S3 Inventory zu exportieren, nach Präfix, Objektanzahl, Gesamtbytes, letztem Änderungsdatum und bekanntem Zugriffsmuster zu gruppieren und dann Lebenszyklusregeln pro Präfix zu schreiben. Vermeiden Sie eine Bucket-weite Regel, es sei denn, der Bucket enthält wirklich eine Art von Daten.