How AWS Keeps Time Internally - Amazon Time Sync Service and Leap Second Smearing Design
Learn how Amazon Time Sync Service works, how GPS and atomic clocks provide high-precision time sources, the design decision to absorb leap seconds through smearing, and why time synchronization matters in distributed systems.
Why Time Synchronization Matters in the Cloud
In distributed systems, accurate time synchronization is more important than you might think. CloudTrail logs, CloudWatch metrics, DynamoDB conditional writes, S3 object versioning, TLS certificate expiration validation - nearly every AWS service depends on accurate time. When clocks drift, log timelines become disordered, making incident investigation difficult. TLS certificate expiration checks can malfunction, causing valid certificates to be rejected as expired. Kerberos authentication (Active Directory) rejects authentication when the time difference between client and server exceeds 5 minutes. In distributed databases, clock drift directly impacts data consistency. Google's Spanner database uses atomic clocks and GPS to provide the TrueTime API precisely because it guarantees distributed transaction consistency through clock precision. AWS addresses the same challenge with its own solution: Amazon Time Sync Service.
How Amazon Time Sync Service Works
Amazon Time Sync Service is a high-precision time source deployed in each AWS Region. EC2 instances can access the NTP (Network Time Protocol) server at the link-local address 169.254.169.123. Like the metadata service at 169.254.169.254, this link-local address works independently of network configuration and is available immediately after instance launch. For IPv6, a link-local endpoint at fd00:ec2::123 is available only on instances built on the Nitro System (as of August 2026; per the official documentation). Neither path traverses an internet gateway or NAT, so time synchronization completes even on instances with no outbound network path. The time sources for Time Sync Service are satellite-connected reference clocks and atomic clocks deployed redundantly in each Region. The satellite-side time source is also an atomic clock, and AWS combines the time received from satellites with local atomic clocks so that delivery of UTC (Coordinated Universal Time) continues even if the satellite signal is temporarily lost. In addition, creating an EC2 placement group with the precision-time strategy and launching a supported instance type enables the enhanced Amazon Time Sync Service. In this configuration, the ENA driver exposes a PTP Hardware Clock (PHC) as a device, allowing the hardware clock to be referenced directly without going through NTP. Synchronization via the PHC offers microsecond precision, incurs no additional charge, and is available in all AWS commercial Regions (supported OS is Linux only; as of August 2026; per the official documentation). Compared with a configuration that uses public NTP servers on the internet (such as pool.ntp.org), the differences are that the path stays entirely within the VPC and that this PHC allows the hardware clock to be referenced directly.
Leap Second Smearing - Avoiding 23:59:60
A leap second is a mechanism that inserts one second into UTC (Coordinated Universal Time) to compensate for variations in Earth's rotation speed. When a leap second is inserted, the normally nonexistent time 23:59:60 appears after 23:59:59. This 23:59:60 is an unexpected value for many software systems and has triggered multiple large-scale outages in the past. During the 2012 leap second insertion, a Linux kernel defect became a problem, and there are known cases in which servers that received the time experienced CPU load spikes or hangs. The NTP path of Amazon Time Sync Service handles leap seconds through "smearing." Over the 24 hours spanning the leap second (12 hours on either side), the one second is evenly distributed, and each second is served as 1 + 1/86400 seconds (about 11.6 microseconds longer than usual). As a result, 23:59:60 never appears; instead, only during this 24-hour window, AWS clocks deviate from standard civil time by up to 0.5 seconds (as of August 2026; per the official explanation). What matters is that this handling differs depending on the path you use. The link-local NTP endpoints (169.254.169.123 / fd00:ec2::123) and the public endpoint time.aws.com return smeared time, whereas the PTP Hardware Clock (PHC) path does not smear and inserts the leap second as-is, as UTC specifies. AWS does not recommend mixing smeared and non-smeared time sources in the same time client configuration during a leap second event. Other providers' public NTP servers may also use smearing, but how the one second is distributed is not necessarily identical, so mixing time sources with different methods can cause time inconsistencies. Note that the leap second itself is set to be abolished by 2035 under a decision of the 27th General Conference on Weights and Measures, and AWS states in its official documentation that it fully supports this decision (as of August 2026). Once abolished, the concept of smearing itself will no longer be needed, but until then you need to know whether the time source you use is a path that smears.
ClockBound - Visualizing Time Uncertainty
ClockBound, which AWS publishes as open source, is a daemon and library for working with the "uncertainty range" of the current time. Time synchronized via NTP contains errors due to network latency and clock drift. ClockBound calculates the upper and lower bounds of this error (the clock error bound) and provides applications with information like "the true current time is within X plus or minus Y." This information can be used for transaction ordering in distributed databases. If the difference between two event timestamps falls within the uncertainty range, you cannot determine which occurred first. If it exceeds the uncertainty range, the order can be determined. One caveat: in a configuration that synchronizes directly to the PTP Hardware Clock, the chrony time synchronization daemon assumes the reference clock's error to be zero, so the error range is estimated smaller than it actually is. For this reason, the Nitro System exposes the PHC's error bound as phc_error_bound (in nanoseconds) at /sys/bus/pci/devices/<PCI_SLOT_NAME>/phc_error_bound, and ClockBound incorporates this value to compute a reasonable error range (supported OS is Linux only; as of August 2026; per the official documentation). It's a similar concept to Google Spanner's TrueTime API, but ClockBound is open source and can be used outside AWS environments. When you use managed services like DynamoDB and Aurora, the handling of time-related consistency is contained on the service side. When you build your own distributed systems, on the other hand, leveraging ClockBound can prevent data inconsistencies caused by time.
Real Problems Caused by Time Synchronization Failures
Time synchronization problems are difficult to diagnose because the symptoms are subtle and the root cause is hard to identify. Here are some actual problem patterns. First, TLS certificate validation failures. When an instance's clock drifts into the future, still-valid certificates are judged as "expired." When it drifts into the past, they're judged as "not yet valid." If HTTPS connections suddenly start failing, clock drift may be the cause. Second, AWS API authentication failures. SigV4 signatures include a timestamp, and when an instance's clock drifts from AWS's time beyond a certain amount, the request is rejected as falling outside the signature's validity window. Because the tolerated drift varies by service and by how the signature is passed (Authorization header signing versus a presigned URL), the premise is to keep time synchronization itself healthy at all times rather than operating on the assumption of a specific number of minutes. Third, disordered log timelines. When aggregating logs from multiple instances, logs from instances with clock drift don't sort in chronological order, making incident investigation difficult. As a countermeasure, configure chrony (NTP client) on all EC2 instances and use Amazon Time Sync Service (169.254.169.123 or fd00:ec2::123) as the time source. On Amazon Linux 2023 and recent versions of Amazon Linux 2, the configuration using the IPv4 endpoint is enabled by default (as of August 2026; per the official documentation). For workloads that require microsecond precision, consider combining a precision-time placement group with the PTP Hardware Clock. However, decide your time source configuration in advance so that the smearing NTP path and the non-smearing PHC path are not mixed during a leap second event.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.