Problem
S3 rejects a signed request with RequestTimeTooSkewed. The request timestamp is too far from the service's current time. Repeated retries from the same drifting clock may keep producing invalid requests.
Diagnose the Signing Host
On a Linux host using systemd, inspect UTC time and synchronization:
date -u
timedatectl statusIf the host uses chrony, inspect its reported synchronization state with chronyc tracking. Not every distribution has the same time service.
For containerized workloads, check the VM or host supplying the clock. A developer VM resumed from sleep is another place to investigate.
Fix
Restore synchronization using the host's configured time service. On a system configured for systemd-managed network time, an administrator can enable it with:
sudo timedatectl set-ntp trueUse the appropriate chrony or platform procedure where that is your existing setup. Confirm the time source is reachable and synchronization has completed. Changing the displayed timezone does not correct an incorrect UTC clock.
Verify
Create a fresh signed request after synchronization. Do not reuse an old failing authorization header. Confirm the original operation succeeds; investigate any remaining credential or permission error separately.
If drift returns, monitor host time synchronization and check VM resume behavior or blocked access to time sources.