The security token included in the request is expired

TL;DR — Deine temporären AWS-Anmeldedaten sind abgelaufen. Das passiert nur mit STS-/SSO-/assumed-role-Anmeldedaten (nicht mit langlebigen IAM-User-Keys). Erneuere die Session — führe aws sso login erneut aus oder nimm die Rolle erneut an —, stelle sicher, dass AWS_SESSION_TOKEN der frische ist, und lösche jeden veralteten Token, der in der Umgebung verblieben ist.

Was es bedeutet

ExpiredTokenException: The security token included in the request is expired

AWS hat deinen Request abgelehnt, weil die temporären Sicherheits-Anmeldedaten, mit denen er signiert war, abgelaufen sind. Temporäre Anmeldedaten von STS (AssumeRole, SSO, GetSessionToken, EC2-/ECS-Instanzrollen) leben für ein begrenztes Zeitfenster — Rollensitzungen laufen von 15 Minuten bis zur maximalen Sitzungsdauer-Einstellung der Rolle (zwischen 1 und 12 Stunden; standardmäßig 1 Stunde), und GetSessionToken-Anmeldedaten für einen IAM-User haben standardmäßig 12 Stunden und können sich auf 36 erstrecken. Sobald dieses Fenster verstreicht, scheitert jeder damit signierte Request mit ExpiredTokenException. Erneutes Senden mit demselben abgelaufenen Token scheitert erneut — es lohnt sich erst nach einer Aktualisierung, es zu wiederholen.

Warum es passiert

  • Die STS-/SSO-Session ist einfach abgelaufen — assumed-role-Anmeldedaten laufen bei der Sitzungsdauer der Rolle ab (standardmäßig 1 Stunde, konfigurierbar bis 12); eine SSO-Session läuft ebenso ab.
  • Ein veraltetes AWS_SESSION_TOKEN in der Umgebung — ein alter Session-Token, der in deine Shell (oder eine .env) exportiert wurde, wird nach seinem Ablauf weiter verwendet; Umgebungsvariablen aktualisieren sich nicht automatisch.
  • Ein langlaufender Prozess, der die Anmeldedaten einmal beim Start abgerufen und nie aktualisiert hat.
  • Gecachte Anmeldedaten in ~/.aws/cli/cache oder einem SDK-Credential-Cache, die ihren Ablauf überlebt haben.
  • Uhr-Abweichung — eine ausreichend falsch gehende Rechneruhr kann gültige Anmeldedaten abgelaufen erscheinen lassen.

So behebst du es

  1. Aktualisiere die Session. Führe aws sso login (für SSO) erneut aus oder nimm die Rolle erneut an (aws sts assume-role …), um einen neuen Access Key, Secret und Session-Token zu erhalten.
  2. Aktualisiere alle drei Werte — Access Key ID, Secret Access Key und den Session-Token zusammen. Ein frischer Schlüssel mit einem veralteten Token scheitert trotzdem.
  3. Lösche veraltete Umgebungsvariablenunset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN, dann lade die frischen Anmeldedaten erneut oder wechsle zu einem Profil, das das SDK selbst aktualisieren kann.
  4. Lass das SDK den Lebenszyklus verwalten — konfiguriere ein Profil / einen Credential-Provider (SSO, assume_role, Instanzrolle), sodass das SDK vor Ablauf automatisch aktualisiert, statt einen Token festzupinnen.
  5. Verifiziere mit aws sts get-caller-identity — wenn das erfolgreich ist, sind deine Anmeldedaten aktuell.
  6. Prüfe die Uhr (NTP), wenn alles frisch aussieht, aber Requests trotzdem einen Ablauf melden.

Aus DynoTable verbinden

DynoTable löst dein Profil bei jeder Verbindung frisch auf — SSO-Sessions und MFA-geschützte Assume-Role eingeschlossen — sodass deine Tabellen nach der Erneuerung der Session ohne Neustart wieder da sind. Der Statuspunkt des Profil-Chips wird rot und zeigt Sign in (SSO) oder Reconnect, sobald temporäre Anmeldedaten ablaufen; klick darauf oder führ eine Query erneut aus, um den In-App-Refresh anzustoßen. Drück ⌘P, um zu bestätigen, dass du auf dem Profil bist, das du im Terminal aktualisiert hast. Der Query Builder ist eine schnelle Kontrolle, ob signierte Lesevorgänge nach der Aktualisierung durchgehen.

FAQ

Wie behebe ich "the security token included in the request is expired"? Deine temporären Anmeldedaten sind abgelaufen. Aktualisiere sie — führe aws sso login erneut aus oder nimm die Rolle erneut an — und aktualisiere Access Key, Secret und AWS_SESSION_TOKEN zusammen. Lösche jeden veralteten Token, der in deiner Shell verblieben ist, damit der alte nicht wiederverwendet wird, und bevorzuge einen SDK-Credential-Provider, der automatisch aktualisiert.

Warum bekomme ich das nur bei temporären Anmeldedaten? ExpiredTokenException gilt für zeitlich begrenzte STS-/SSO-/assumed-role-Anmeldedaten, die einen Ablauf tragen. Langlebige IAM-User-Access-Keys laufen nicht von selbst ab, sodass sie aus anderen Gründen (ungültig/deaktiviert) Credential-Fehler auslösen, nicht aus diesem.

Verwandte Fehler

Quellen

Mit DynamoDB ohne die Console arbeiten

Ein schneller DynamoDB-Desktop-Client, der das echte SQL ausführt, das DynamoDB nicht kann — JOINs, GROUP BY, Aggregationen — mit visueller Bearbeitung und einem KI-Agenten auf deinen eigenen Bedrock-Schlüsseln.

30 Tage kostenlos testen, keine Kreditkarte — danach der Kostenlos-Tarif ohne Zeitlimit.