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 (協定世界時) の配信を継続できる構成にしています。さらに、EC2 のプレイスメントグループを precision-time 戦略で作成し、対応するインスタンスタイプを起動すると、拡張版の Amazon Time Sync Service が有効になります。この構成では ENA ドライバーが PTP ハードウェアクロック (PHC) をデバイスとして公開し、NTP を介さずハードウェアクロックを直接参照できます。PHC 経由の同期はマイクロ秒精度で、追加料金はなく、すべての AWS 商用リージョンで利用できます (対応 OS は 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 の範囲にある」という情報をアプリケーションへ提供します。この情報は、分散データベースのトランザクション順序付けに使用できます。2 つのイベントのタイムスタンプの差が不確実性の範囲内であれば、どちらが先に発生したかを確定できません。不確実性の範囲を超えていれば、順序を確定できます。注意点として、PTP ハードウェアクロックへ直接同期する構成では、時刻同期デーモンの chrony が参照クロック側の誤差をゼロと仮定するため、誤差範囲が実際より小さく見積もられます。そのため Nitro System は PHC の誤差上限を phc_error_bound (ナノ秒単位) として /sys/bus/pci/devices/<PCI_SLOT_NAME>/phc_error_bound に公開しており、ClockBound はこの値を取り込んで妥当な誤差範囲を算出します (対応 OS は Linux のみ・2026 年 8 月時点・公式ドキュメント記載値)。Google Spanner の TrueTime API と同様の概念ですが、ClockBound はオープンソースであり、AWS 以外の環境でも使用できます。DynamoDB や Aurora のようなマネージドサービスを使う場合、時刻に起因する整合性の扱いはサービス側に閉じています。一方、ユーザーが自前で分散システムを構築する場合は、ClockBound を活用することで時刻に起因するデータ不整合を防げます。
時刻同期の失敗が引き起こす実際の問題
時刻同期の問題は、症状が分かりにくく、原因の特定が困難です。実際に発生する問題パターンをいくつか紹介します。第 1 に、TLS 証明書の検証失敗です。インスタンスの時刻が未来にずれると、まだ有効な証明書が「期限切れ」と判定されます。過去にずれると、「まだ有効期間に入っていない」と判定されます。HTTPS 通信が突然失敗し始めた場合、時刻のずれが原因であることがあります。第 2 に、AWS API の認証失敗です。SigV4 署名にはタイムスタンプが含まれており、インスタンスの時刻が AWS 側の時刻から一定以上ずれると、署名の有効期間を外れたものとしてリクエストが拒否されます。許容されるずれの幅はサービスや署名の渡し方 (Authorization ヘッダー署名か事前署名 URL か) によって異なるため、特定の分数を前提に運用するのではなく、時刻同期そのものを常時正常に保つことが前提になります。第 3 に、ログの時系列の乱れです。複数のインスタンスのログを集約する際、時刻がずれているインスタンスのログが時系列順に並ばず、障害調査が困難になります。対策として、すべての 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 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。