## TL;DR

The request's credentials are not accepted: the key is wrong or deleted, the machine clock is skewed, or the request hit an endpoint that does not recognize the credential. Check the key, the clock, and the endpoint in that order.

## Error

```text
"The security token included in the request is invalid" aws error
```

## Steps

1. Verify the access key still exists and is active on the IAM user. Expected: rules out a rotated-away key.
2. Check the machine clock against a time source; AWS rejects requests with timestamps too far off. Expected: skew under a few minutes.
3. Confirm the endpoint and region: some services need the regional endpoint, and global-service quirks reject otherwise-valid credentials. Expected: the request targets the right endpoint.
4. If using temporary credentials, check they have not expired and that all three parts (key, secret, session token) are set together. Expected: complete, fresh session credentials.
5. Retry the failing call. Expected: success once the real cause is fixed.

## When to use

- AWS CLI or SDK calls fail with the invalid-token message.
- After rotations, clock changes, or region moves.

## When not to use

- `AccessDenied` (credentials valid, permission missing).
- `InvalidClientTokenId` specifically naming a deleted key.

## Tool compatibility

- AWS CLI and SDKs; IAM users, roles, and temporary credentials.

## Variant phrasings

### AWS invalid security token

Same triage.

### request signature expired

Clock skew variant; fix NTP.

## Why it happens

AWS validates the credential, the timestamp, and the signature together. Any one of the three being off produces this generic message.

## Edge cases

- VMs that were suspended resume with a stale clock; NTP resync fixes it.
- Copying credentials between machines often drops the session token, breaking temporary creds.
- Some SDKs cache credentials; a rotated key needs a process restart to pick up.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_56Xj5kE90AvRXKPUjSVqXw