DynamoDB vs Amazon S3
DynamoDB und Amazon S3 lösen unterschiedliche Probleme, daher lautet die ehrliche Antwort auf die Frage „welches" meist beide. DynamoDB ist eine Key-Value- und Dokumentdatenbank für strukturierte Datensätze, die du per Key nachschlägst, abfragst und aktualisierst. Amazon S3 ist Object Storage für Dateien und Blobs — Bilder, Backups, Logs, Videos —, die du als Ganzes speicherst und abrufst. Sie ergänzen sich, statt ein Entweder/oder zu sein.
Sollte ich DynamoDB oder S3 verwenden?
Verwende DynamoDB, wenn du viele kleine strukturierte Datensätze hast, die du per Key mit Latenz im einstelligen Millisekundenbereich abfragst, filterst und aktualisierst. Verwende Amazon S3, wenn du ganze Dateien oder Blobs speicherst und auslieferst — Bilder, Backups, Exporte — und sie per Namen abrufst. Sie ergänzen sich: Ein sehr verbreitetes Muster speichert das Objekt in S3 und seine Metadaten in DynamoDB.
DynamoDB vs Amazon S3 auf einen Blick
| Merkmal | DynamoDB | Amazon S3 |
|---|---|---|
| Hauptzweck | NoSQL Key-Value-/Dokumentdatenbank für strukturierte Datensätze | Object Storage für Dateien, Blobs und unstrukturierte Daten |
| Dateneinheit | Item (eine Menge typisierter Attribute), adressiert per Primärschlüssel | Objekt (Bytes + Metadaten), adressiert per Key innerhalb eines Buckets |
| Maximalgröße pro Einheit | 400 KB pro Item (Attributnamen + Werte) | 5 TB pro Objekt (einzelner PUT bis zu 5 GB; größere Uploads nutzen Multipart) |
| Abfrage / Zugriff | GetItem, Query, Scan, BatchGetItem, PartiQL, Sekundärindizes (GSI/LSI) | GET / PUT / DELETE per Key, LIST eines Buckets; In-Place-Abfrage via Amazon Athena (oder S3 Select für Bestandskunden) |
| Latenzprofil | Lese-/Schreibvorgänge im einstelligen Millisekundenbereich für einzelne Items bei jeder Skalierung | Dauerhafter Objektdurchsatz; höhere Latenz pro Anfrage als eine Key-Value-Datenbank, keine Millisekunden-Datensatz-Lookups |
| Konsistenz | Standardmäßig letztendlich konsistent; stark konsistente Lesevorgänge pro Anfrage verfügbar | Starke Read-after-write-Konsistenz für alle Objekte und alle Anfragen (seit 2020) |
| Preismodell | Lese-/Schreibkapazität (RCU/WCU — On-Demand oder Provisioned) + Datenspeicher pro GB-Monat | Speicher pro GB-Monat (nach Storage-Klasse) + Anfragegebühren (PUT/GET/LIST) + Datenabruf / -transfer |
| Am besten geeignet für | Benutzerprofile, Sessions, Warenkörbe, Event-/Statusdatensätze, Metadaten, OLTP-artiger Zugriff mit hohem Durchsatz | Medien, Backups, Data-Lake-Dateien, statische Assets, große Exporte, Archivierung |
Jede Zelle oben stammt aus der offiziellen AWS-Dokumentation (siehe den Provenance-Hinweis am Anfang dieser Datei).
Wann DynamoDB verwenden
Greife zu DynamoDB, wenn deine Daten strukturierte Datensätze sind, auf die du per Key zugreifst:
- Viele kleine Items (jedes unter dem 400-KB-Limit), die du einzeln liest, schreibst und aktualisierst.
- Vorhersehbare Lookups mit niedriger Latenz — DynamoDB zielt auf Lese- und Schreibvorgänge im einstelligen Millisekundenbereich für einzelne Items bei jeder Skalierung ab.
- Zugriffsmuster, die du mit einem Primärschlüssel und Sekundärindizes ausdrücken kannst: Get-by-ID, Abfrage einer Partition, Filtern innerhalb einer Partition.
- Hoher Schreibdurchsatz mit feingranularen Updates (ein Attribut ändern, ohne den ganzen Datensatz neu zu schreiben).
Wenn du dabei bist, eine 5-MB-Datei innerhalb eines Items zu speichern, ist das das Signal, dass du an die Grenze von DynamoDB gestoßen bist — siehe DynamoDB Item-Größenlimit.
Wann S3 verwenden
Greife zu Amazon S3, wenn deine Daten eine ganze Datei oder ein Blob sind, den du per Namen abrufst:
- Bilder, PDFs, Videos, Audio und andere binäre Assets.
- Backups, Datenbankexporte und Data-Lake-Dateien (Parquet, CSV, JSON), die später mit einem Tool wie Amazon Athena abgefragt werden.
- Große Objekte — S3 speichert Objekte bis zu 5 TB pro Stück, weit jenseits jedes einzelnen Datenbankdatensatzes.
- Statische Website-Assets und Inhalte, die direkt an Nutzer ausgeliefert werden.
S3 ist keine Datenbank: Du kannst den Inhalt beliebiger Objekte nicht mit reichhaltigen Indizes abfragen, wie du DynamoDB-Items abfragst. In-Place-SQL-artiges Filtern über ein Objekt ist über Amazon Athena verfügbar (S3 Select bleibt für Bestandskunden verfügbar, wurde aber 2024 für Neukunden geschlossen).
Beide zusammen einsetzen
Die beiden Dienste sind kombiniert am mächtigsten. AWS' eigene Empfehlung für Daten, die zu groß für ein DynamoDB-Item sind, lautet, das Objekt in S3 zu speichern und einen Pointer in DynamoDB zu behalten:
- Speichere die große Datei (Bild, Dokument, Video) als Objekt in S3.
- Speichere ihre Metadaten — den S3-Objekt-Key, Content-Type, Eigentümer, Tags, Zeitstempel — als Item in DynamoDB, wo sie günstig abfragbar sind.
- Schlage den Datensatz in DynamoDB per Key nach und hole dann das Objekt anhand des gespeicherten Identifiers aus S3.
Ein Vorbehalt, den AWS hervorhebt: Es gibt keine Transaktionen, die DynamoDB und S3 umspannen, sodass deine Anwendung Teilausfälle behandelt (zum Beispiel das Aufräumen eines verwaisten S3-Objekts, wenn der DynamoDB-Schreibvorgang fehlschlägt).
Arbeiten mit DynamoDB
Sobald du dich für DynamoDB für die strukturierte Hälfte deiner Daten entschieden hast, ist DynoTable ein Desktop-DynamoDB-Client zum Durchsuchen, Bearbeiten und Abfragen von Tabellen unter macOS, Windows und Linux. Er liest deine standardmäßige AWS-Credential-Chain, sodass es nichts DynamoDB-Spezifisches zu migrieren gibt — richte ihn auf deine Region und Tabellen aus, und deine Daten bleiben in DynamoDB.
Wenn du die GetItem-, Query-, Update- oder Condition-Expressions von Hand bauen musst, die das obige Muster „Metadaten in DynamoDB" untermauern, generiert der kostenlose DynamoDB Expression Builder die Anfrage in den Formen AWS SDK, CLI und boto3. Um ein Item vor der Entscheidung, was nach S3 gehört, gegen das 400-KB-Limit zu dimensionieren, misst der Item-Größenrechner die Byte-Größe eines Datensatzes.
FAQ
Kann DynamoDB Dateien oder Bilder speichern?
Kleine, innerhalb von Grenzen. Ein DynamoDB-Item kann Binärdaten enthalten, aber das gesamte Item — jeder Attributname und -wert — muss unter 400 KB bleiben. Für alles Größere ist AWS' dokumentierte Best Practice, die Datei als Objekt in Amazon S3 zu speichern und den S3-Objekt-Key (plus Metadaten) in einem DynamoDB-Item zu behalten.
Ist S3 günstiger als DynamoDB?
Sie werden unterschiedlich bepreist, es hängt also vom Workload ab statt von einer pauschalen Antwort. S3 berechnet Speicher pro GB-Monat plus Gebühren pro Anfrage und Abruf und ist im Allgemeinen die günstigere Heimat für große Mengen selten abgerufener Bytes. DynamoDB berechnet Lese-/Schreibkapazität plus Speicher und ist auf Zugriff mit hohem Durchsatz und niedriger Latenz auf viele kleine Datensätze ausgelegt. Große Blobs in DynamoDB zu speichern ist sowohl größenbeschränkt als auch vergleichsweise teuer — deshalb ist die Aufteilung S3-Objekt-plus-DynamoDB-Metadaten das Standardmuster.
DynamoDB oder S3 für JSON?
Wenn das JSON ein strukturierter Datensatz ist, den du per Key abfragst und aktualisierst — ein Benutzer, eine Bestellung, eine Session —, passt DynamoDB, und es bildet JSON auf typisierte Attribute ab und unterstützt PartiQL. Wenn das JSON ein ganzes Dokument oder eine Data-Lake-Datei ist, die du speicherst und später in Bulk scannst (zum Beispiel per Abfrage mit Amazon Athena), passt S3. Ein häufiger Hybrid hält die abfragbaren Felder in DynamoDB und den vollständigen JSON-Payload als Objekt in S3.
Verwandt
- Lerne: DynamoDB Item-Größenlimit · Wann man DynamoDB verwendet
- Baue Anfragen visuell mit dem DynamoDB Expression Builder.
- Dimensioniere Datensätze mit dem DynamoDB Item-Größenrechner.
- DynoTable herunterladen, um mit deinen DynamoDB-Tabellen zu arbeiten.
Zuletzt verifiziert am 2026-07-12 anhand der offiziellen AWS-DynamoDB- und Amazon-S3-Dokumentation. Amazon S3, DynamoDB und Athena sind Dienste von Amazon Web Services, hier nur zur Identifikation genannt.