AWS macht DynamoDB Bulk Put Items allgemein verfügbar: S3-Dateien landen auf getrennter Kapazität in bestehenden Tabellen, ab 0,10 Dollar pro GB in US East, doch Datensätze ohne Bedingung überschreiben, Stream-Verbraucher sehen die Schreibvorgänge und globale Tabellen werden nicht unterstützt

Am 5. November 2026 gab AWS die allgemeine Verfügbarkeit von Bulk Put Items für Amazon DynamoDB bekannt. Es ist eine verwaltete Funktion, die Daten aus Amazon S3 in eine bestehende Tabelle schreibt. Bisher bedeutete das Laden von Dateien aus anderen Systemen in eine laufende Tabelle meist eine eigene Pipeline, einen Auftrag in AWS Glue oder Amazon EMR und sorgfältiges Verwalten der Tabellenkapazität. Mit Bulk Put Items zeigt man DynamoDB den S3-Ort der Eingabedateien, benennt einen Ausgabeort für einen Bericht und wählt eine Stufe. Die Ankündigung sagt, die Schreibvorgänge beeinträchtigten die bestehende Last nicht, und der Einführungsblog sowie das Entwicklerhandbuch erklären, sie nutzten getrennte Kapazität und verbrauchten keine Lese- oder Schreibkapazität der Tabelle.

Die Eingabedateien sind zeilenweise getrenntes DynamoDB-JSON oder Amazon Ion, optional mit gzip oder zstd komprimiert. Jeder Datensatz kann einen eigenen Bedingungsausdruck mit derselben Syntax wie bei PutItem tragen. Eine Bedingung wie attribute_not_exists auf dem Partitionsschlüssel ergibt reine Einfügeschreibvorgänge, und ein Vergleich auf einem Versionsattribut schreibt ein Element nur, wenn die eingehende Kopie neuer ist. Eine Datei kann unbedingte, reine Einfüge- und versionsgeschützte Datensätze mischen. Zwei Details verdienen Beachtung. Ein Datensatz ohne Bedingung wird unbedingt geschrieben und überschreibt jedes vorhandene Element mit demselben Schlüssel. Und wenn alle Elemente dieselbe Bedingung erfüllen müssen, muss sie in jedem Datensatz der Dateien wiederholt werden. Ein durch seine Bedingung übersprungenes Element ist kein Fehler: Es zählt als verarbeitet und erscheint im Bericht, wenn man Bedingungsfehler anfordert.

Der Vorgang läuft asynchron. Der Startaufruf liefert die ARN des Vorgangs und trägt ein Client-Token, damit ein wiederholter Start keinen Doppelimport auslöst; die ersten Minuten dienen der Bereitstellung, die Zähler können also anfangs bei null stehen. Die startende Identität braucht Berechtigungen auf Konto- und Tabellenebene, Lesezugriff auf den Eingabe-Bucket, Schreibzugriff auf den Berichts-Bucket und Zugriff auf die beteiligten AWS-KMS-Schlüssel. Ein Vorgang endet als COMPLETED, COMPLETED_WITH_ERRORS, FAILED oder CANCELLED. Ein Abbruch macht bereits geschriebene Elemente nicht rückgängig, ein abgebrochener Import hinterlässt die Tabelle also teilweise aktualisiert. Der Bericht listet nicht geschriebene Datensätze mit Quellobjekt, Position im Objekt und Grund auf; bei einer fehlgeschlagenen Bedingung zeigt er das neue und das vorhandene Element. Der Blog rät, COMPLETED_WITH_ERRORS als Normalfall zu behandeln, die fehlerhaften Datensätze zu korrigieren und nur diese erneut zu importieren.

Es gibt zwei Stufen. Standard ist die Voreinstellung und die günstigere, gedacht für Arbeiten mit flexiblem Zeitrahmen wie regelmäßige Anreicherung und Nachfüllungen. Accelerated zielt auf höheren Durchsatz für Arbeiten mit Frist wie Migrationen und Wiederherstellung. Für eine gut skalierte Tabelle, einen gleichmäßig verteilten Partitionsschlüsselraum mit hoher Kardinalität, auf mehrere ähnlich große S3-Objekte aufgeteilte Eingaben und keine Replikation in globale sekundäre Indizes nennt AWS Schätzwerte für Accelerated: unter 10 Minuten für 10 Millionen Elemente à 1 KB, unter einer Stunde für 100 Millionen und 2 bis 4 Stunden für eine Milliarde. AWS nennt diese Werte veranschaulichende Ausgangspunkte. Es warnt auch, frühe Läufe könnten der Skalierung der Tabelle vorauseilen, und die Laufzeiten stabilisierten sich erst nach drei bis fünf Läufen mit gleich geformter Datei.

Abgerechnet wird nach Bytes. In US East (Nord-Virginia) nennt der Blog 0,10 Dollar pro GB für Standard und 0,20 Dollar pro GB für Accelerated, mit mindestens 1 KB pro Element, getrennt für die Tabelle und jeden Index. Eine fehlgeschlagene Bedingungsprüfung wird berechnet, durch die Validierung abgelehnte Elemente nicht. Derselbe Beitrag rechnet 100 Millionen Elemente à 1 KB vor: 10,00 Dollar bei Standard und 20,00 Dollar bei Accelerated. Wir geben diese Zahlen nur für diese Region wieder; für andere Regionen verweist die Ankündigung auf Preisseiten.

Die Grenzen sind konkret. Pro Tabelle kann jeweils nur ein Bulk-Put-Vorgang laufen, und nicht, während ein Index erstellt wird. Jedes Konto kann bis zu fünf Standard- und fünf Accelerated-Vorgänge gleichzeitig haben. Ein Vorgang kann bei Standard bis zu 100 GB und bei Accelerated bis zu 1 TB umfassen, und die Zieltabelle muss aktiv sein. Globale Tabellen werden zum Start nicht unterstützt, und während eines Vorgangs kann kein Replikat hinzugefügt werden. Bei Tabellen mit Vektorindex wird nur Standard unterstützt. Die Funktion schreibt ganze Elemente und aktualisiert keine einzelnen Attribute; dafür bleibt UpdateItem das Werkzeug. Standard ist in allen kommerziellen Regionen und in den AWS-GovCloud-(US)-Regionen verfügbar, Accelerated dagegen nur in den auf einer eigenen Seite genannten Regionen; die Verfügbarkeit von Standard darf man also nicht als die von Accelerated lesen.

Unsere Einschätzung: Die Aussage, es gebe keine Auswirkungen, stimmt für die Tabellenkapazität und die Lese- und Schreibmetriken der Anwendung, doch der Blog nennt selbst weitere Effekte. Importierte Elemente erscheinen in DynamoDB Streams und Kinesis wie Anwendungsschreibvorgänge; ein großer Import kann Stream-Verbraucher daher überlasten, sofern sie nicht für den zusätzlichen Durchsatz ausgelegt sind oder die Schreibrate des Vorgangs mit MaxWriteRequestUnits begrenzt wird. Der Blog warnt, eine zu niedrige Grenze könne den Lauf über sein Zeitlimit hinaus strecken und scheitern lassen, doch keine der gespeicherten Seiten nennt dieses Zeitlimit. Eine laufende Transaktion auf einem Element hat Vorrang vor dem Import. Weil Bulk-Schreibvorgänge nicht in den Metriken des verbrauchten Durchsatzes auftauchen, melden Tabellenalarme keinen Importfehler; das Signal ist der Status des Vorgangs. Für eine Handvoll Elemente bleiben PutItem und BatchWriteItem die richtigen Werkzeuge.