AWS 内部时间同步机制 - Amazon Time Sync Service 与闰秒平滑处理的设计
解析 AWS 自主运营的 Amazon Time Sync Service 的工作原理、基于 GPS 和原子钟的高精度时间源、通过平滑处理吸收闰秒的设计决策，以及分布式系统中时间同步的重要性。
为什么时间同步在云中如此重要
在分布式系统中，精确的时间同步比想象中更为重要。CloudTrail 日志、CloudWatch 指标、DynamoDB 条件写入、S3 对象版本控制、TLS 证书有效期验证等，AWS 几乎所有服务都依赖于精确的时间。时间偏差会导致日志时序混乱，使故障排查变得困难。TLS 证书有效期检查可能误判，将正常证书判定为无效。Kerberos 认证 (Active Directory) 在客户端与服务器时间差超过 5 分钟时会拒绝认证。在分布式数据库中，时间偏差直接影响数据一致性。Google 的 Spanner 数据库使用原子钟和 GPS 提供 TrueTime API，正是为了通过时间精度来保证分布式事务的一致性。AWS 针对同样的挑战，提供了 Amazon Time Sync Service 这一自研解决方案。
Amazon Time Sync Service 的工作原理
Amazon Time Sync Service 是部署在各 AWS 区域的高精度时间源。EC2 实例可通过链路本地地址 169.254.169.123 访问 NTP (Network Time Protocol) 服务器。该地址与元数据服务的 169.254.169.254 类似，属于链路本地地址，不依赖网络配置，实例启动后即可使用。在 IPv6 方面，仅限基于 Nitro System 的实例可使用链路本地端点 fd00:ec2::123（截至 2026 年 8 月，官方文档记载值）。这两条路径都不经过互联网网关或 NAT，因此即使是没有出站通信路径的实例也能完成时间同步。Time Sync Service 的时间源是在各区域冗余部署的卫星连接参考时钟和原子钟。卫星侧的时间源同样是原子钟，AWS 将从卫星接收的时间与本地原子钟相结合，即使卫星信号暂时中断也能持续提供 UTC（协调世界时）。此外，以 precision-time 策略创建 EC2 置放群组并启动受支持的实例类型后，即可启用增强版 Amazon Time Sync Service。在该配置下，ENA 驱动程序将 PTP 硬件时钟 (PHC) 作为设备公开，无需经由 NTP 即可直接读取硬件时钟。经由 PHC 的同步可达微秒级精度，无额外费用，并可在所有 AWS 商用区域使用（支持的操作系统仅限 Linux；截至 2026 年 8 月，官方文档记载值）。与使用互联网上公共 NTP 服务器（如 pool.ntp.org）的配置相比，区别在于路径完全在 VPC 内完成，以及可通过该 PHC 直接读取硬件时钟。
闰秒平滑处理 - 不产生 23:59:60 的设计
闰秒是为补偿地球自转速度变化而在 UTC（协调世界时）中插入 1 秒的机制。插入闰秒时，23:59:59 之后会出现通常不存在的 23:59:60。这个 23:59:60 对许多软件来说是意外值，历史上曾成为多起大规模故障的导火索。2012 年插入闰秒时，Linux 内核的缺陷成为问题，已知有接收到该时间的服务器出现 CPU 负载骤增或挂起的案例。Amazon Time Sync Service 的 NTP 路径通过「平滑处理」(smearing) 来处理闰秒。在跨越闰秒的 24 小时内（前后各 12 小时）将 1 秒均匀分散，把每一秒作为 1 + 1/86400 秒（比正常长约 11.6 微秒）来分发。因此 23:59:60 这个时刻不会出现，取而代之的是仅在这 24 小时内 AWS 的时钟与标准民用时间最多偏离 0.5 秒（截至 2026 年 8 月，官方说明记载值）。需要注意的是，这种处理方式因所使用的路径而不同。链路本地 NTP 端点 (169.254.169.123 / fd00:ec2::123) 和公共端点 time.aws.com 返回经过平滑处理的时间，而 PTP 硬件时钟 (PHC) 路径不做平滑处理，按 UTC 规定原样插入闰秒。AWS 不建议在闰秒事件期间将经过平滑处理与未经平滑处理的时间源混用于同一时间客户端配置。其他厂商的公共 NTP 服务器也可能采用平滑处理，但 1 秒的分散方式未必相同，混用方式不同的时间源可能导致时间不一致。另外，闰秒本身已由第 27 届国际计量大会决定在 2035 年前废止，AWS 在官方文档中明确表示全力支持这一决定（截至 2026 年 8 月）。废止后平滑处理这一概念本身将不再需要，但在此之前，需要了解自己所使用的时间源是否属于会做平滑处理的路径。
ClockBound - 可视化时间的不确定性
AWS 开源发布的 ClockBound 是用于处理当前时间「不确定性范围」的守护进程和库。通过 NTP 同步的时间包含网络延迟和时钟漂移带来的误差。ClockBound 计算该误差的上下限（时钟误差界），向应用程序提供「当前真实时间在 X ± Y 范围内」的信息。该信息可用于分布式数据库的事务排序。如果两个事件时间戳的差值在不确定性范围内，则无法确定哪个先发生；超出不确定性范围则可以确定顺序。需要注意的是，在直接同步到 PTP 硬件时钟的配置中，时间同步守护进程 chrony 会假定参考时钟侧的误差为零，因此误差范围会被估计得比实际更小。为此，Nitro System 将 PHC 的误差上限以 phc_error_bound（纳秒单位）的形式公开在 /sys/bus/pci/devices/<PCI_SLOT_NAME>/phc_error_bound，ClockBound 读取该值来计算合理的误差范围（支持的操作系统仅限 Linux；截至 2026 年 8 月，官方文档记载值）。这与 Google Spanner 的 TrueTime API 概念类似，但 ClockBound 是开源的，可在 AWS 以外的环境使用。使用 DynamoDB 和 Aurora 等托管服务时，与时间相关的一致性处理封闭在服务侧。而用户自建分布式系统时，可利用 ClockBound 防止因时间导致的数据不一致。
时间同步失败引发的实际问题
时间同步问题的症状不明显，原因难以定位。以下介绍几种实际发生的问题模式。第一，TLS 证书验证失败。实例时间偏向未来时，仍有效的证书会被判定为「已过期」；偏向过去时，会被判定为「尚未生效」。HTTPS 通信突然失败时，时间偏差可能是原因。第二，AWS API 认证失败。SigV4 签名包含时间戳，当实例时间与 AWS 侧时间偏离超过一定幅度时，请求会因超出签名有效期而被拒绝。允许的偏差幅度因服务和签名的传递方式（Authorization 标头签名还是预签名 URL）而不同，因此不应以特定分钟数为前提进行运维，而应以始终保持时间同步本身正常为前提。第三，日志时序混乱。汇聚多个实例的日志时，时间偏差的实例日志无法按时间顺序排列，使故障排查变得困难。对策是在所有 EC2 实例上配置 chrony (NTP 客户端)，将 Amazon Time Sync Service (169.254.169.123 或 fd00:ec2::123) 作为时间源。在 Amazon Linux 2023 和近期的 Amazon Linux 2 中，使用 IPv4 端点的配置已默认启用（截至 2026 年 8 月，官方文档记载）。对于需要微秒级精度的工作负载，可考虑将 precision-time 置放群组与 PTP 硬件时钟结合使用。但需要事先确定时间源的配置，避免在闰秒事件期间混用做平滑处理的 NTP 路径和不做平滑处理的 PHC 路径。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。