EC2 Windows System Time Drifts 8 Hours After Boot

Checo7/3/26About 2 min

EC2 Windows System Time Drifts 8 Hours After Boot

After an EC2 Windows instance boots, the system time is 8 hours behind. W32Time then applies a one-time 8-hour jump on sync, causing log timestamp chaos and Kerberos failures. The root cause is confusion between RTC local time and UTC.

Symptom

After boot, the system time is 8 hours behind. After a while (depending on the NTP poll interval), W32Time synchronizes with the NTP source and applies a one-time 8-hour jump, causing application log timestamp chaos, Kerberos authentication failures, and scheduled task anomalies.

This is common on Windows instances with the timezone set to UTC+8 (China Standard Time), especially after stop/start, reboot, or restore from AMI.

Error Message

System event log (Event ID 1, source Microsoft-Windows-Kernel-General):

System time changed from 2026-06-16T01:52:47Z
to 2026-06-16T09:52:47Z
Delta: 28800135 ms (~8 hours)

RTC time in UTC: false

The key field: RTC time in UTC: false means the hardware RTC clock stores local time, not UTC.

Root Cause

Windows assumes by default that the RTC hardware clock stores local time
The EC2 Nitro platform RTC stores UTC time
When RealTimeIsUniversal is not set, Windows interprets the UTC value in the RTC as local time on boot, then subtracts the timezone offset to get UTC — resulting in 8 hours behind
W32Time then detects the offset and applies a one-time correction (+8h jump)

Solutions

Create an AMI snapshot backup before proceeding.

Option 1: Set RealTimeIsUniversal (recommended)

Tell Windows to treat the RTC hardware clock as UTC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Option 2: Disable VMICTimeProvider

EC2 instances do not need the Hyper-V time sync provider; disable it to avoid interference:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider" /v Enabled /t REG_DWORD /d 0 /f
Restart-Service w32time

Option 3: Use Amazon Time Sync Service

Switch the NTP source to the EC2 link-local time service (169.254.169.123), which has very low latency and does not require internet access:

w32tm /config /manualpeerlist:"169.254.169.123,0x9" /syncfromflags:manual /reliable:no /update
Restart-Service w32time
w32tm /resync /force

Shorten the poll interval:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient" /v SpecialPollInterval /t REG_DWORD /d 900 /f
Restart-Service w32time

Combined recommendation

All three options are compatible and can be applied together. Apply all, reboot, then verify:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal
w32tm /query /status
w32tm /query /peers