同僚の Mingxue Zhao がゲストポストを投稿してくれました。これは今後発生する重要な時刻調整についての説明です。
— Jeff;
IERS(The International Earth Rotation and Reference Systems)は、標準時刻に対し2015年6月30日に追加の1秒を挿入するとアナウンスしました。これは、6月30日の最後の1分には61秒目が存在するということです。もし時刻を標準時と同期している場合、この追加の秒が23:59:60として、23:59:59と00:00:00の間に表示されることになります。この追加の1秒をうるう秒と呼びます。このような「うるう秒の挿入」は1972年から25回実施され、最近では2012年6月30日に実施されています。（※補足：これはUTC時間ですので、日本時間では7月1日午前9時になります）
全てのアプリケーションやシステムがこの":60"という秒をハンドリングできるようには作られていません。そのため結果として、いくつかのアプリケーションやシステムが誤動作を起こしたり、予想しづらい間違った動作を起こす可能性があります。サービスを安定的に動かし続けるために、AWSを含む幾つかの組織は":60"のうるう秒を回避するための代替方法を計画しています。これはAWS内のクロックが、少しの期間だけ、ごくわずかに標準時とずれるという事を意味しています。
もしご自身のアプリケーションやシステムが適切にうるう秒をハンドリングできるかどうかを知りたい場合は、それを提供している提供元にまずコンタクトをしてください。そしてもし、時刻に非常に厳密に動くワークロードがあり、そのためにAWSのクロックの挙動について知りたい場合は、このドキュメントを注意深くお読みください。大きく分けて３つのパートに影響がありえます：
- AWSマネジメントコンソールと、バックエンドシステム
- Amazon EC2 インスタンス
- その他のAWSリソース
AWSクロックと、UTCとの比較についての詳細は、以下のAWS調整時刻(AWS Adjusted Time)のセクションで説明しています。
AWSマネジメントコンソールと、バックエンドシステム
AWSマネジメントコンソールとバックエンドシステムは、うるう秒をハンドリングするようには実装されていません。代わりに、２４時間という期間に渡って、各１秒１秒をごくわずかだけ遅くすることで、うるう秒の挿入された標準時(UTC)とのズレが無くなるように調整されます。このためAWSクロックは最大で、標準時から0.5秒遅れ、もしくは0.5秒先行します。（詳しくは以下のAWS調整時刻(AWS Adjusted Time)を読んでください）
この調整の結果、コンソールにおける値（リソースを作成したタイムスタンプ等）の他、CloudFront や CloudTrail のログに":60" といった記録は残りません。同様にビリング（支払い）画面においても、この調整済み時刻で利用料金が計上されます。
Amazon EC2 インスタンス
EC2インスタンスにおける挙動は、それぞれの設定によりますが、AWS 側でインスタンス内部の時刻同期を管理することはありません。つまりインスタンスの時刻の挙動はそのEC2設定や周辺システムによるのですが、一般的には、予期せぬ不具合を避けるため NTP の利用が推奨されます。AWS が提供する AMI（Amazon Linux や Windows等） では、デフォルト設定でLinux は ntp.org、Windows は time.windows.comから同期を行うようになっています。
EC2インスタンスの時刻を調整する必要がある場合には、以下の資料を参照してください。
- Amazon Linux AMIの場合: Linux インスタンスの時刻の設定
- Amazonが提供するWindows AMIの場合: Windowsインスタンスの時刻を設定する
- その他のAMIを利用したインスタンス: AMIの提供元にお問い合わせください
その他のAWSリソース
他のAWSリソースは、それぞれのクロックを持っています。EC2とは異なり、AWS側で対応されるため、ユーザ側で対応する必要はありません。（注：お客様管理下でEC2のインスタンスを起動するサービスを除きます）。
以下のリソースは、ntp.orgと時刻同期しており、うるう秒に対応しています。
- Amazon CloudSearch クラスター
- Amazon EC2 Container Service インスタンス
- Amazon RDS インスタンス
- Amazon Redshift インスタンス
AWS調整時刻(AWS Adjusted Time)
このセクションでは、AWSマネジメントコンソールやバックエンドシステムで、どのようにクロックが動作するかの詳細を説明します。
2015年6月30日 12:00:00PM(お昼の12時)から、AWSクロックが毎秒あたり1/86400秒だけ遅くなります。つまりAWSクロックでの１秒の経過が、実際の時刻では1+1/86400秒の経過になります。この処理が2015年7月１日の12:00:00PM（お昼の１２時）までの24時間にわたって続くことによって、ちょうど１秒分実際の時刻より遅れた状態になります。この調整期間の最中である2015年6月30日の終わりに標準時（UTC）にはうるう秒が挿入され、こちらも１秒だけ時刻が遅くなります。結果として2015年7月1日の12:00:00PM(お昼の12時)には、AWSクロックとUTCは完全に同じ時刻を指すようになります。以下の表でこの変化を説明しましょう。
| UTC | AWS調整時刻 | AWS vs. UTC | 注記 |
11:59:59 AM 2015/06/30 | 11:59:59 AM 2015/06/30 | +0 | AWSクロックはUTCと同期しています。 |
| 12:00:00 PM | 12:00:00 PM | +0 | |
| 12:00:01 | AWSクロックの各1秒が1/86400だけ長くなり、UTCから遅れ始めます。少しづつ差が開いていき、最大で1/2秒の差になります。 | ||
| 12:00:01 | +1/86400 | ||
| 12:00:02 | |||
| 12:00:02 | +2/86400 | ||
| … | … | … | |
| 23:59:59 | |||
| 23:59:59 | +43199/86400 | ||
| 23:59:60 | UTCにうるう秒が挿入されます。 | ||
00:00:00 AM 2015/07/01 | -1/2 | UTCが1秒遅れた結果として、AWSクロックはUTCより1/2秒進んでいる状態になります。 | |
00:00:00 AM 2015/07/01 | AWSクロックは依然速度を落としたままのため、少しづつUTCとのギャップが縮まっていきます。 | ||
| 00:00:01 | -43199/86400 | ||
| 00:00:01 | |||
| 00:00:02 | -43198/86400 | ||
| … | … | … | |
| 11:59:59 AM | -1/86400 | ||
| 11:59:59 AM | |||
12:00:00 PM 2015/07/01 | 12:00:00 PM 2015/07/01 | +0 | ギャップがゼロになりました。この時点でAWSとUTCは同期され、この後は同じ時刻を指すようになります。 |
| 12:00:01 | 12:00:01 | +0 | |
| … | … | … |
この現象についてご質問がある場合はAWSサポートにご連絡いただくか、EC2フォーラムで質問をしてください。
— Mingxue Zhao, シニアプロダクトマネージャー（翻訳：下佐粉 昭）