PacketSensei

AWS `RequestTimeTooSkewed`: What It Means and How to Fix It

PacketSensei

RequestTimeTooSkewed is a clock problem wearing the costume of a credentials problem. It comes from All AWS APIs, and the message reads:

The difference between the request time and the current time is too large.

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error RequestTimeTooSkewed
Service All AWS APIs
Message The difference between the request time and the current time is too large.
Most common cause The instance clock has drifted

What it actually means

Every AWS API request is signed with SigV4, and the signature includes a timestamp. AWS rejects any request whose timestamp is more than fifteen minutes away from the server’s own clock, in either direction. This is a replay-attack defence: a captured request cannot be replayed later.

The error names the problem precisely, but it arrives in the middle of what looks like an authentication failure, so it is routinely misread as bad credentials. It is not. The credentials are fine; the machine’s clock is wrong.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 The instance clock has drifted A custom AMI carrying an on-premises NTP configuration cannot reach that server from a VPC and drifts quietly. Repoint chrony at the Amazon Time Sync Service.
2 A container inherited a bad host clock Containers do not keep their own time — they use the host kernel clock. Fix the host, not the image.
3 A laptop or VM resumed from suspend The clock jumps on resume and can take a moment to resynchronise. The most common local development cause.
4 The time zone is right but UTC is wrong SigV4 uses UTC. A machine displaying the correct local time can still have an incorrect UTC offset, which looks correct to a human and wrong to AWS.
5 A CI runner or build container with no NTP Ephemeral build environments sometimes start with an unsynchronised clock and finish before it settles.

How to tell which one you have

# What does this machine think the time is, in UTC?
date -u

# What does chrony think?
chronyc tracking
chronyc sources -v

# Compare against AWS directly: the Date header in any AWS response is authoritative.
curl -sI https://s3.amazonaws.com | grep -i '^date:'

If the curl result and date -u differ by more than a few seconds, that is your answer.

Preventing it

Inside AWS, use the Amazon Time Sync Service at the link-local address 169.254.169.123. It needs no internet gateway, no NAT gateway, and no security group rule, because link-local traffic never touches either.

# /etc/chrony.conf
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

Amazon Linux 2023 and current Ubuntu AMIs ship configured this way. Custom AMIs built from an on-premises golden image usually do not — check yours.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.