Amazonは最近、EC2インスタンスが、ハードウェアの問題のために到達不能になった場合に自動的に回復するようになったことを発表した。自動リカバリでは、インスタンスを別のハードウェアに移行しつつ、インスタンスID、プライベートIPアドレス、Elastic IPアドレス、メタデータを保持する。
インスタンスのリカバリをトリガーできるさまざまなシナリオがある。ネットワーク接続の切断、システム電源のダウン、物理ホスト上のソフトウェアやハードウェアの問題である。インスタンスのリカバリ中に、対象のインスタンスはインスタンスの再起動の一部として移行され、メモリ内にあるデータはすべて失われる。障害のあるインスタンスにパブリックIPv4アドレスがある場合、インスタンスはそのアドレスを保持する。同様に、プレースメントグループにある場合、リカバリされたインスタンスは同じグループで実行されます。
AWSのプリンシパルソリューションアーキテクトのMani Chandrasekaran氏は、次のように書いている。
これは小さな発表かもしれませんが、顧客にプラスの影響を与えるでしょう。これは以前から利用できましたが、ここでは「デフォルト」がキーワードです。
この機能の最初のイテレーションは数年前にリリースされた。CloudWatchアラームを自動的に設定するインスタンスをリカバリすることも可能であった。Redditの人気のスレッドで、ユーザのbruin116は次のように書いている。
ついに！この機能ができて本当にうれしいです。これは、Azureが2015年から自動的に行ったことです。AWSの対応から外れていたことは奇妙だといつも思っていました。
新しい動作では、ハードウェア障害の影響を受けたときにインスタンスの回復を高速化するように設計されている。しかし、顧客はその機能を無効にすることを選択できる。自動リカバリが開始されない場合がある。それは、インスタンスがヘルスチェックが有効になっている自動スケーリンググループの一部で、インスタンスがネイティブの自動スケーリング機能を使って置き換えられている場合である。
クラウドプロバイダーは、インスタンスの自動リカバリが高可用性ソリューションを意図したものではないことを強調している。アベイラビリティーゾーンの容量が不十分な場合、インスタンスがすでに1日3回のリカバリの試みに達した場合、リカバリプロセスに影響を与える問題がある場合に失敗する可能性があるためである。
Amazonは、いくつか最初に挙がりそうな質問をカバーするようにドキュメントを更新した。しかし、疑問が残っている。ユーザのMowglisDadのコメントしている。
更新されたドキュメントに従って、リカバリのカスタム処理をするための新しいCloudwatchイベントが追加されました。解決できていない質問は、情報取得の目的でサブスクライブすると、デフォルトの動作が上書きされるかどうかです。
現在、すべてのEC2インスタンスクラスが自動リカバリをサポートしているわけではない。EFAネットワークインターフェイスを備えたインスタンス、インスタンスストアボリュームおよびメタルインスタンスタイプを備えたインスタンスはサポートしていない。CLIのdescribe-instance-typesコマンドを使って、実行中のインスタンスのうち、シンプルな自動リカバリをサポートするものを確認できる。
aws ec2 describe-instance-types --filters Name=auto-recovery-supported,Values=true
--query "InstanceTypes[*].[InstanceType]" --output text | sort
新機能の発表は、自動回復されたサーバで操作を再開できるまでにかかる時間を保証あるいは示唆するものではない。