AWSは，新しいEC2自動リカバリ機能を，US East(北バージニア)リージョンでリリースした。システム障害の検出時に，サポート対象のインスタンスを自動的に回復することで，インスタンスの可用性を向上するように設計されている。
Elastic Compute Cloud (EC2)の自動リカバリ機能は，AWSのCloudWatch監視サービス状態チェックが，ベースとなっている物理ホストに，EC2インスタンスの実行に影響するような問題を検出した時に起動される。問題として検出される例としては，ネットワーク接続の喪失，システムパワー喪失，物理ホスト上のソフトウェアないしハードウェア的な問題などがある。
自動リカバリ機能は，影響を受けたEC2インスタンスを，新しいハードウェア上で自動的に復帰しようと試みる。これによって，新たなハードウェアへの手作業によるマイグレーションは不要になる。インスタンスは再起動によって回復されるので，メモリ上にあった情報はすべて失われる。回復したインスタンスのインスタンスID，IPアドレス，コンフィギュレーションなどは，オリジナルのものとまったく同じになる。
インスタンスの自動リカバリを有効にするには，AWS CloudWatchアラームを作成した上で，“EC2 Status Check Failed (System)”メトリックを選択し，“Recover this instance”をアクションとして選択する。CloudWatchアラームの生成や修正にIAM(Identity and Access Management)アカウントを使用する場合には，そのアカウントに対して，インスタンスを回復する自動リカバリ機能のための権限として，ec2:DescribeInstanceStatus, ec2:DescribeInstances, ec2:DescribeInstanceRecoveryAttribute, ec2:RecoverInstancesを設定しておく必要がある。
AWS EC2の資料には，EC2自動リカバリアクションのサポート対象として，現在は以下のような制限があると記されている。
- C3, M3, R3, および T2インスタンスタイプであること。
- US Easet(北バージニア)リージョンのインスタンスであること。
- VPC内のインスタンスであること。
- 共有テナンシのインスタンス(インスタンスのテナンシ属性が既定値に設定されている)であること。
- Amazon EBSストレージを排他的に利用するインスタンスであること。
EC2-Classicインスタンス，専用テナンシインスタンス，および何らかのインスタンスストアボリュームを使用するインスタンスでは，リカバリアクションはサポートされない。
自動リカバリのプロセスでは，影響を受けたインスタンスに対して，３つのユニークな障害原因について，最大３回まで回復を試みる。 インスタンスのシステムチェックの失敗が永続的な場合，AWSの資料では，そのインスタンスの起動および停止を手動で実施するように推奨している。自動リカバリに失敗した場合，その起因となったシステムステータスチェック失敗の根本的な原因がハードウェア劣化にあると判明したならば，そのインスタンスは廃棄される場合がある。
AWS自動リカバリの資料には，インスタンスの自動リカバリが失敗する場合の原因として，次のような問題が述べられている。
- 代替ハードウェアの一時的な容量不足。
- 自動インスタンスリカバリではサポート対象外の構成であるインスタンスストアストレージに，インスタンスがアタッチされている。
- 実行中のサービスヘルスダッシュボードのイベントがあり，リカバリプロセスの正常実行を妨げている。最新のサービス可用性情報については，http://status.aws.amazon.comを参照のこと。
- インスタンスが，１日あたりリカバリ試行３回という限界値に達した。
自動リカバリプロセスが完了すると，リカバリの実施状況や以降の指示を含むEメール通知が送信される。
自動リカバリのプロセス中には，EC2インスタンス仮想マシン(VM)の再起動が行われる。従ってこの機能は，Google Compute Engine(GCE) Live MigrateやKVM Migratorの提供するVMライブマイグレーションのように，ゲストVMがダウンタイムを意識しない機能に相当するものではない。
AWS EC2自動リカバリ機能に関する詳しい情報や，本機能を有効にするための完全な手順については，AWSの自動リカバリに関する資料で確認することができる。