DynoTable
Fortgeschritten6 Min. Lesezeit

So verbindest du dich mit DynamoDB Local und LocalStack

Du hast ein lokales DynamoDB laufen und dein Code spricht problemlos damit — aber du willst die Tabellen sehen, nicht jedes Mal ein scan-Skript schreiben. Einen Client mit einem lokalen Endpoint zu verbinden sind zwei Änderungen: auf die richtige URL richten und ihm Wegwerf- Credentials geben. Die Details unten sind, wo Leute hängenbleiben — Region-Namespacing, die Alphanumerisch-Schlüssel-Regel und die 8000-vs-4566-Port-Aufteilung.

DynamoDB Local vs LocalStack: womit du dich verbindest

Beide geben dir eine DynamoDB-API auf localhost ohne AWS-Konto, aber sie sind verschiedene Dinge:

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

Das Endpoint-plus-Dummy-Credentials-Setup, das jeden stolpern lässt

Die AWS-SDKs und die CLI verlangen einen Access Key und eine Region, selbst wenn man mit einem lokalen Endpoint spricht — aber diese Werte müssen nicht echt sein. AWS' eigene Docs sagen, diese Werte „müssen keine gültigen AWS-Werte sein, um lokal zu laufen" (AWS-Docs).

Zwei nicht offensichtliche Stolperfallen:

  • Die Region/der Access Key namespacet deine Daten stillschweigend. Ohne das -sharedDb-Flag schreibt DynamoDB Local eine separate myaccesskeyid_region.db- Datei pro Access-Key-ID + Region-Kombination — AWS' genaue Benennung. Verbinde dich mit einem anderen Schlüssel oder einer anderen Region als deine App benutzt hat, und deine Tabellen sehen aus, als seien sie verschwunden; sie sind nur in einer anderen Datei. Starte mit -sharedDb (eine shared-local-instance.db für jeden Client) oder match den genauen Schlüssel + die Region, die deine App benutzt.
  • Die Access Key ID muss alphanumerisch sein auf DynamoDB Local — keine Symbole. AWS-Docs besagen, AWS_ACCESS_KEY_ID darf nur A–Z, a–z und 0–9 enthalten; AWS hat das in DynamoDB Local 2.0.0 (und 1.23.0+) eingeführt, sodass ein Schlüssel mit Sonderzeichen, der auf einem früheren Image funktionierte, nun fehlschlägt (AWS re:Post). Siehe den Fehler unten.

Für LocalStack ist der sichere Standard test / test: es ignoriert den Secret Key komplett und validiert den Secret-Wert nie. Echt aussehende AKIA…/ASIA…-Schlüssel werden als Sicherheitsmaßnahme abgelehnt und fallen auf das Dummy-Konto 000000000000 zurück — dasselbe Konto, auf das ein beliebiger Schlüssel wie test aufgelöst wird. Bleib bei test.

Verbinden mit der AWS CLI (Funktionsprüfung)

Bevor du eine GUI darauf richtest, bestätige von der CLI aus, dass der Endpoint lebt. Die CLI kann nicht standardmäßig auf einen lokalen Endpoint zugreifen, also übergibst du --endpoint-url bei jedem Befehl.

DynamoDB Local:

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

LocalStack (gleicher Befehl, anderer Port):

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

Wenn du überhaupt Credentials konfiguriert hast (selbst Fake-Werte in ~/.aws/credentials oder via AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), gibt das deine Tabellenliste zurück. Eine leere Liste ohne Fehler bedeutet, der Endpoint funktioniert, aber du schaust auf einen anderen Schlüssel-/Region-Namespace — siehe die Stolperfalle oben.

DynamoDB-Local-GUI: lokale Tabellen in DynoTable durchsuchen und queryen

Sobald die CLI funktioniert, braucht eine GUI dieselben drei Werte: Endpoint, Region und beliebige 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.

In DynoTable fügst du eine Verbindung hinzu und setzt einen benutzerdefinierten Endpoint:

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

Von dort aus durchsuchst du Items, führst eine Query oder einen Scan aus und bearbeitest Zeilen visuell statt JSON auf der CLI von Hand zu marshallen. Wenn du Fixtures lädst, verwandelt der DynamoDB-JSON-Konverter reines JSON ins Wire-Format, und Query vs Scan behandelt, zu welchem Read du greifen solltest. Gleiches Vorgehen für einen LocalStack-DynamoDB-Viewer — nur der Port ändert sich auf 4566.

DynoTable ist reine lokale Desktop-Software, sodass es deine Fixtures auf deinem Rechner hält, wenn du es auf localhost richtest. Für einen breiteren Blick auf die GUI-Landschaft siehe den DynamoDB-GUI-Vergleich.

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

  • Connection refused. Falscher Port — 8000 ist DynamoDB Local, 4566 ist LocalStack. Bestätige außerdem, dass der Container den Port tatsächlich veröffentlicht hat (docker run -p 8000:8000 amazon/dynamodb-local). Für LocalStack prüfe, ob der Dienst läuft unter http://localhost:4566/_localstack/health.
  • The Access Key ID or Security Token is Invalid auf DynamoDB Local. Seit dem 2.0.0- (und 1.23.0+)-Image muss die Access Key ID ausschließlich alphanumerisch sein. Ein Schlüssel mit Symbolen, der auf einem früheren Image funktionierte, schlägt nun fehl — ersetze ihn durch Buchstaben/Zahlen (z. B. test) und aktualisiere jedes Tool entsprechend.
  • 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 das --endpoint-url / endpoint_url weggelassen und den echten AWS- Endpoint getroffen, der deinen Dummy-Schlüssel ablehnt. Bestätige, dass der Client tatsächlich auf http://localhost:4566 zeigt.
  • Credential-Fehler vom SDK/der CLI. Selbst lokale Endpoints brauchen irgendwelche Credentials. Setze AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (oder ein Fake-Profil), damit die Credential-Chain des SDK auflöst.
  • http vs https. Lokale Endpoints sind reines http. Eine https://-URL wird den TLS-Handshake fehlschlagen lassen.

Sind DynamoDB-Local-Daten dieselben wie meine echten AWS-Tabellen?

Nein — lokal und Cloud sind komplett getrennte Speicher. DynamoDB Local (und LocalStacks DynamoDB) hält Daten in einer lokalen Datei oder im Speicher; es berührt nie dein AWS-Konto, und AWS-Regionen/-Konten werden auf Client-Ebene nicht unterstützt lokal. Das ist der Sinn: Es ist für Entwicklung und Tests. Wenn du dieselben Fixtures später in der Cloud willst, empfiehlt AWS gültig aussehende Schlüssel-/Region-Werte lokal, sodass du beim Umzug nur den Endpoint tauschst. Um dieses Schema zu modellieren, bevor du es auslieferst, behandeln Single-Table-Design und GSI vs LSI die Entscheidungen, die sich zwischen lokal und Prod nicht ändern.

FAQ

Brauche ich echte AWS-Credentials? Nein. Sowohl DynamoDB Local als auch LocalStack akzeptieren Dummy-Werte. Sie müssen nur vorhanden, alphanumerisch (für DynamoDB Local) und über deine Tools hinweg konsistent sein.

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

Was ist der Unterschied zwischen Port 8000 und 4566? 8000 ist der Standard von standalone DynamoDB Local; 4566 ist LocalStacks einzelner Edge-Port, der all seine emulierten Dienste 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 kostenlos als JAR und Docker-Image — es gibt „keine Provisioned-Throughput-, Datenspeicher- oder Datentransfer-Kosten"; es ist nur für Entwicklung und Tests gedacht, nicht für Produktion.

Kann ich SQL gegen meine lokalen Tabellen ausführen? Lokales DynamoDB spricht dieselbe API wie die Cloud, also gelten dieselben Zugriffsmuster-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 SQL Workbench führt diese analytischen Queries über jede Verbindung aus, lokal inklusive.

Probier DynoTable aus, um dich direkt mit localhost:8000 oder localhost:4566 zu verbinden und deine lokalen Tabellen mit einer GUI zu durchsuchen, zu queryen und zu bearbeiten.

Aktualisiert