Mit DynamoDB Local und LocalStack verbinden

Du hast ein lokales DynamoDB laufen und dein Code redet problemlos damit — aber du willst die Tabellen sehen, nicht jedes Mal ein scan-Skript schreiben. Einen Client an einen lokalen Endpoint zu hängen sind zwei Änderungen: auf die richtige URL zeigen und ihm Wegwerf-Credentials geben. Die Details unten sind die Stellen, an denen alle hängen bleiben — Region-Namespacing, die Alphanumerisch-Regel für den Key und der Port-Split zwischen 8000 und 4566.

DynamoDB Local vs LocalStack: womit du dich verbindest

Beide geben dir eine DynamoDB-API auf localhost ohne AWS-Account, sind aber unterschiedliche Dinge:

DynamoDB Local ist die herunterladbare DynamoDB-Engine in einem einzelnen Prozess — AWS liefert sie als JAR und als Docker-Image (amazon/dynamodb-local). Es ist DynamoDB und sonst nichts. Default-Port 8000 (AWS-Docs). Siehe DynamoDB Local mit Docker betreiben.
LocalStack emuliert einen ganzen Stack von AWS-Services hinter einem Endpoint. Sein DynamoDB wird selbst von DynamoDB Local angetrieben, aber alles läuft über LocalStacks einzelnen Edge-Port 4566.

Der einzige praktische Unterschied beim Verbinden ist also die Endpoint-URL: :8000 für standalone DynamoDB Local, :4566 für DynamoDB-über-LocalStack. Alles andere — die API, der Credentials-Trick, die GUI-Config — ist identisch.

Das Endpoint- + Dummy-Credentials-Setup, an dem alle scheitern

Die AWS-SDKs und die CLI verlangen einen Access Key und eine Region, selbst wenn sie mit einem lokalen Endpoint reden — aber diese Werte müssen nicht echt sein. AWS' eigene Docs sagen, sie „don't have to be valid AWS values to run locally" (AWS-Docs).

Zwei nicht offensichtliche Fallen:

Region und Access Key namespacen deine Daten stillschweigend. Ohne das Flag -sharedDb schreibt DynamoDB Local pro Kombination aus Access-Key-ID und Region eine eigene Datei myaccesskeyid_region.db — AWS' exakte Benennung. Verbindest du dich mit einem anderen Key oder einer anderen Region als deine App, sehen deine Tabellen aus, als wären sie verschwunden; sie liegen nur in einer anderen Datei. Starte mit -sharedDb (eine shared-local-instance.db für jeden Client) oder triff exakt Key + Region, die deine App nutzt.
Die Access-Key-ID muss alphanumerisch sein auf DynamoDB Local — keine Symbole. Die AWS-Docs sagen, AWS_ACCESS_KEY_ID darf nur A–Z, a–z und 0–9 enthalten; AWS hat das mit DynamoDB Local 2.0.0 (und 1.23.0+) eingeführt, ein Key mit Sonderzeichen, der auf einem älteren Image lief, scheitert also jetzt (AWS re:Post). Siehe den Fehler weiter unten.

Für LocalStack ist test / test der sichere Default: es ignoriert den Secret Key komplett und validiert den Secret-Wert nie. Echt aussehende AKIA…/ASIA…-Keys werden als Schutzmaßnahme abgelehnt und fallen auf den Dummy-Account 000000000000 zurück — derselbe Account, auf den ein beliebiger Key wie test auflöst. Bleib bei test.

Verbinden mit der AWS CLI (Sanity-Check)

Bevor du eine GUI darauf richtest: bestätige aus der CLI heraus, dass der Endpoint lebt. Die CLI hat keinen eingebauten lokalen Default-Endpoint, also gib entweder --endpoint-url pro Kommando mit oder setze AWS_ENDPOINT_URL_DYNAMODB=http://localhost:8000 (CLI v2.13+).

DynamoDB Local:

aws dynamodb list-tables --endpoint-url http://localhost:8000

LocalStack (gleiches Kommando, anderer Port):

aws dynamodb list-tables --endpoint-url http://localhost:4566

Wenn überhaupt Credentials konfiguriert sind (auch fake in ~/.aws/credentials oder über AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), gibt das deine Tabellenliste zurück. Eine leere Liste ohne Fehler heißt: der Endpoint funktioniert, aber du schaust in einen anderen Key-/Region-Namespace — siehe die Falle oben.

Gib Dummy-Creds für einen einmaligen Check inline mit, ohne dein Profil anzufassen:

AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_REGION=us-east-1 \
  aws dynamodb list-tables --endpoint-url http://localhost:8000

DynamoDB Local GUI: lokale Tabellen in DynoTable browsen und abfragen

Sobald die CLI läuft, braucht eine GUI dieselben drei Werte: Endpoint, Region und irgendwelche Dummy-Credentials. Die CLI gibt DynamoDB-JSON zurück, das du mit dem Auge liest; eine GUI rendert dieselben Daten als Tabelle, die du sortieren, filtern und bearbeiten kannst.

Lege in DynoTable eine Verbindung an und setze einen Custom Endpoint:

Endpoint: http://localhost:8000 (DynamoDB Local) oder http://localhost:4566 (LocalStack)
Region: was auch immer deine App nutzt — z. B. us-east-1. Das ist hier ein Label, keine echte AWS-Region, aber es muss passen, damit du im selben Daten-Namespace landest.
Access Key / Secret: irgendwas (test / test ist üblich). Auf DynamoDB Local für den Access Key nur alphanumerisch.

Von da an browst du Items, fährst eine Query oder einen Scan und bearbeitest Zeilen visuell, statt JSON auf der CLI von Hand zu . Wenn du Fixtures lädst, macht der DynamoDB-JSON-Konverter aus plain JSON das Wire-Format, und Query vs Scan klärt, welcher Read der richtige ist. Dieselbe Übung für einen LocalStack-DynamoDB-Viewer — nur der Port wechselt auf 4566.

DynoTable ist reine Local-Only-Desktop-Software; sie auf localhost zu richten hält deine Fixtures auf deiner Maschine. Für einen breiteren Blick auf die GUI-Optionen siehe den DynamoDB-GUI-Vergleich.

Häufige Fehler (Region-Konflikt, Port, Credentials)

Connection refused. Falscher Port — 8000 ist DynamoDB Local, 4566 ist LocalStack. Prüfe außerdem, ob der Container den Port wirklich published hat (docker run -p 8000:8000 amazon/dynamodb-local). Bei LocalStack: prüfe, ob der Service unter http://localhost:4566/_localstack/health antwortet.
The Access Key ID or Security Token is Invalid auf DynamoDB Local. Seit dem Image 2.0.0 (und 1.23.0+) muss die Access-Key-ID rein alphanumerisch sein. Ein Key mit Symbolen, der auf einem älteren Image lief, scheitert jetzt — ersetze ihn durch Buchstaben/Ziffern (z. B. test) und zieh jedes Tool nach.
The security token included in the request is invalid gegen LocalStack. Das ist fast immer ein Endpoint-Problem, kein Credentials-Problem — dein SDK-Client hat --endpoint-url / endpoint_url verloren und ist auf den echten AWS-Endpoint gegangen, der deinen Dummy-Key ablehnt. Prüfe, ob der Client wirklich auf http://localhost:4566 zeigt.
Credential-Fehler aus SDK/CLI. Auch lokale Endpoints brauchen irgendwelche Credentials. Setze AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (oder ein Fake-Profil), damit die Credential-Chain des SDKs auflöst.
http vs https. Lokale Endpoints sind plain http. Eine https://-URL scheitert am TLS-Handshake.

Sind das in DynamoDB Local dieselben Daten wie in meinen echten AWS-Tabellen?

Nein — lokal und Cloud sind vollständig getrennte Stores. DynamoDB Local (und LocalStacks DynamoDB) hält Daten in einer lokalen Datei oder im Speicher; es fasst deinen AWS-Account nie an, und AWS-Regionen/-Accounts werden auf Client-Ebene lokal nicht unterstützt. Genau das ist der Punkt: es ist für Entwicklung und Tests gedacht. Willst du dieselben Fixtures später in der Cloud, schlägt AWS vor, lokal plausibel aussehende Key-/Region-Werte zu nehmen, sodass du beim Umzug nur den Endpoint tauschst. Um dieses Schema zu modellieren, bevor du es ausrollst, decken Single-Table-Design und GSI vs LSI die Entscheidungen ab, die sich zwischen lokal und Prod nicht ändern.

Was lokal dir spart (und was Prod trotzdem abrechnet)

DynamoDB Local metert nichts — keine RCU, keine WCU, keinen Transfer. Dasselbe GetItem gegen managed DynamoDB in us-east-1 on-demand kostet 0,5 RCU eventually consistent oder 1 RCU strongly consistent für ein Item ≤ 4 KB. Sobald du --endpoint-url gegen den echten Endpoint tauschst, kostet jedes Browsen und jede Query wieder. Modelliere den Sprung mit dem Pricing-Rechner und dimensioniere repräsentative Items mit dem Item-Size-Rechner.

FAQ

Brauche ich echte AWS-Credentials? Nein. DynamoDB Local und LocalStack akzeptieren beide Dummy-Werte. Sie müssen nur vorhanden, alphanumerisch (bei DynamoDB Local) und über alle Tools hinweg konsistent sein.

Warum verschwinden meine Tabellen, wenn ich das Tool wechsle? Ohne -sharedDb partitioniert DynamoDB Local die Daten nach Access Key + Region in separate myaccesskeyid_region.db-Dateien. Nutze -sharedDb oder halte diese Werte überall gleich.

Was ist der Unterschied zwischen Port 8000 und 4566? 8000 ist der Default von standalone DynamoDB Local; 4566 ist LocalStacks einzelner Edge-Port, der alle emulierten Services fronted, DynamoDB inklusive.

Kann eine GUI sich mit beiden verbinden? Ja — sie sprechen dieselbe DynamoDB-API. Nur die Endpoint-URL ändert sich (:8000 vs :4566).

Ist DynamoDB Local kostenlos? Ja. AWS verteilt DynamoDB Local kostenfrei als JAR und als Docker-Image — es gibt „no provisioned throughput, data storage, or data transfer costs"; es ist nur für Entwicklung und Tests gedacht, nicht für Production.

Kann ich SQL gegen meine lokalen Tabellen fahren? Lokales DynamoDB spricht dieselbe API wie die Cloud, es gelten also dieselben Access-Pattern-Regeln — und dieselben Limits: DynamoDBs PartiQL-SELECT-Grammatik ist nur SELECT … FROM … WHERE … ORDER BY — kein JOIN, kein GROUP BY und keine gruppierenden Aggregatfunktionen wie COUNT/SUM/AVG (siehe PartiQL vs SQL). DynoTables fährt diese analytischen Queries über jede Verbindung, lokal eingeschlossen.

Probiere DynoTable, um dich direkt mit localhost:8000 oder localhost:4566 zu verbinden und deine lokalen Tabellen mit einer GUI zu browsen, abzufragen und zu bearbeiten.