Alle Items aus DynamoDB mit der AWS CLI holen

Die AWS CLI versteckt die Pagination. aws dynamodb scan macht so viele 1-MB-Service-Aufrufe, wie die Tabelle braucht, und gibt ein einziges zusammengesetztes Ergebnis aus — der Befehl, der zehn Items liest, und der Befehl, der zehn Millionen liest, sind derselbe Befehl.

Das ist der Komfort und die Falle. Anzahl der Aufrufe, Speicherverbrauch und Rechnung skalieren mit der Tabelle, während die Zeile eine Zeile bleibt.

Code

aws dynamodb scan --table-name 'Music'

Die zusammengesetzte Ausgabe enthält jedes Item der Tabelle:

{
    "Items": [
        {"Artist": {"S": "Arturo Sandoval"}, "SongTitle": {"S": "Cubano Chant"}, ...}
    ],
    "Count": 1287,
    "ScannedCount": 1287
}

Erklärung

• --no-paginate ist der Schalter für einen einzigen Aufruf — er hält die CLI davon ab, dem Cursor zu folgen, du bekommst also die erste Seite und sonst nichts. Gut für einen Blick, falsch für einen vollständigen Read (wie der Cursor funktioniert).
• --page-size ändert die Anzahl der Aufrufe, nicht die Ausgabe — AWS sagt es klar: "Changing the page size doesn't affect the output; it affects only the number of API calls that need to be made to generate the output." Greif danach, wenn eine große Seite in einen Timeout läuft, nie um Geld zu sparen. Die Lesekosten sind so oder so identisch.
• --max-items ist die Stelle, an der die Ausgabe endet und NextToken beginnt — es gibt so viele Items aus plus ein Fortsetzungs-Token für --starting-token. Setze es und --page-size auf dieselbe Zahl: AWS warnt, dass unterschiedliche Werte "can get unexpected results with missing or duplicated items".
• --query läuft auf deinem Rechner — es ist JMESPath über dem ausgegebenen Ergebnis, angewendet, nachdem jedes Item gelesen und abgerechnet wurde. --projection-expression (plus --expression-attribute-names für reservierte Wörter) ist das, was DynamoDB sieht, und es verkleinert die Antwort, nicht die Rechnung. Auch eine --filter-expression verwirft Items erst, nachdem sie berechnet wurden (Scan mit Filter).
• Alles wird gepuffert und trifft dann auf einen Pager — die CLI sammelt jede Seite, bevor sie ausgibt, und CLI v2 schickt das Ergebnis standardmäßig durch less auf macOS und Linux oder more unter Windows. Bei einer großen Tabelle ist das eine Speicherspitze und ein blockiertes Terminal zugleich. Ergänze --no-cli-pager oder setze AWS_PAGER auf einen leeren String und schneide mit --max-items.
• Parallel Scan funktioniert auch aus der Shell — starte N Kopien mit --segment i --total-segments N, von denen jede ihr eigenes Segment automatisch paginiert. Gleiche Gesamtkosten, deutlich kürzere Laufzeit (wann es sich lohnt).

Mach es visuell

Ein einzeiliger Befehl kann ein teurer Befehl sein. Der DynamoDB-Preisrechner beziffert einen vollständigen Read deiner Tabelle, bevor du ihn ausführst.

DynoTable blättert durch die Tabelle in einem Grid statt in einem Terminal-Puffer und exportiert den Scan hinter diesem Grid wieder als aws dynamodb-Befehl. Lade DynoTable herunter.

Verwandte Beispiele

• Alle Items in Node.js holen — derselbe vollständige Read mit einer expliziten Schleife.
• Alle Items in Python holen — derselbe vollständige Read mit boto3s Paginator.
• DynamoDB Scan mit der AWS CLI — scannen mit einer --filter-expression.
• Parallel Scans — Segment/TotalSegments, Worker-Anzahl und wann sich der Aufwand lohnt.
• Warum ist mein DynamoDB-Scan langsam und teuer? — das Kostenmodell und wie du es vermeidest.
• DynamoDB ProvisionedThroughputExceededException — die ganze Tabelle zu lesen ist der klassische Weg, ihn auszulösen.
• „The provided starting key is invalid" — ein verstümmelter Fortsetzungs-Key in der Pagination-Schleife.

Referenzen

• Scan — Amazon DynamoDB API Reference
• scan — AWS CLI Command Reference
• Using AWS CLI pagination options — AWS CLI User Guide
• DynamoDB read and write operations (capacity unit consumption) — Amazon DynamoDB Developer Guide

Zuletzt verifiziert am 2026-07-28 gegen die oben verlinkte offizielle AWS-Dokumentation.