# インスタンスの自動復旧
**重要**
このセクションではEC2 インスタンスで復旧メカニズムをプロアクティブに設定する方法について説明します。これらの復旧メカニズムは がシステムステータスチェックが失敗する原因となる基盤となるハードウェアまたはソフトウェアの問題AWSを検出したときに、インスタンスの可用性を復元するように設計されています。インスタンスへのアクセスで現在問題が発生している場合は「[EC2 インスタンスのトラブルシューティング](ec2-instance-troubleshoot.md)」を参照してください。
基盤となるハー[ドウェアの障害によりインスタンスが使用できないと AWS により判断された場合、インスタンスの耐障害性を設定して可用性を復元できるメカニズムとして簡易自動復旧または Amazon CloudWatch アクションベ](instance-configuration-recovery.md)スの[復旧のどちらかの方法で行われます](cloudwatch-recovery.md)。インスタンスの可用性の復元は*インスタンスの復旧*とも呼ばれます。
インスタンス復旧プロセス中に、 AWSは基盤となるハードウェアまたはソフトウェアの問題があるホストから別のホストにインスタンスを移動しようとします。インスタンスの復旧が成功すると、インスタンスには予期しない再起動として表示されます。[インスタンスの復旧が発生したかどうかを確認できます](verify-if-automatic-recovery-occurred.md)。
復旧プロセスが失敗した場合、基盤となるハードウェアまたはソフトウェアの問題により、インスタンスがホストで引き続き実行される可能性があります。この場合、手動による介入が必要です。インスタンスのシステムステータスチェック[の失敗が続](Stop_Start.md)く場合はインスタンスを手動で停止および開始することをお勧めします。インスタンスを開始すると、通常、インスタンスは基盤となる新しいホストコンピュータに移行され、新しいパブリック IPv4 アドレスが割り当てられます。ただし、インスタンスがパブリック IPv4 アドレスを保持する自動インスタンスリカバリとは異なり、再起動されたインスタンスはElastic IP アドレスがない限り、新しいパブリック IPv4 アドレスを受け取ります。
自動復旧メカニズムを活用するにはシステムステータスチェックが失敗する前に、インスタンスで事前に設定する必要があります。サポート対象のインスタンスを起動すると、簡易自動復旧がデフォルトで有効になります。オプションで、起動後の Amazon CloudWatch アクションベースの復旧を設定できます。これらのメカニズムのいずれかを設定すると、インスタンスの耐障害性が向上します。
簡易自動復旧と Amazon CloudWatch アクションベースの復旧はサポートされているインスタンスでのみ使用できます。詳細については[簡易自動復旧の要件と制限](instance-configuration-recovery.md#requirements-for-simplified-automatic-recovery)および[CloudWatch アクションベースの復旧の要件と制限](cloudwatch-recovery.md#requirements-for-cloudwatch-action-based-recovery)を参照してください。
**警告**
基盤となるハードウェアまたはソフトウェアの問題により がインスタンスをAWS復旧する場合、次の結果に注意してください。揮発性メモリ (RAM) に保存されているデータは失われ、オペレーティングシステムの稼働時間はゼロから開始されます。さらに、CloudWatch アクションベースの復旧ではインスタンスストアボリュームのデータも失われます。データ損失を防ぐために、重要なデータのバックアップを定期的に作成することをお勧めします。Amazon EC2 インスタンスのバックアップと復旧のベストプラクティスの詳細については「[Amazon EC2 のベストプラクティス](ec2-best-practices.md)」を参照してください。
自動インスタンス復旧メカニズムは*個々のインスタンス*用に設計されています。回復力のある*システム*の構築に関するガイダンスについては「」を参照してください[回復力のあるシステムを構築する](#instance-recovery-build-a-resilient-system)。
**Topics**
+ [自動インスタンス復旧の主な概念](#ec2-automatic-instance-recovery-key-concepts)
+ [簡易自動復旧と CloudWatch アクションベースの復旧の違い](#differences)
+ [回復力のあるシステムを構築する](#instance-recovery-build-a-resilient-system)
+ [自動インスタンス復旧が発生したかどうかを確認する](verify-if-automatic-recovery-occurred.md)
+ [Amazon EC2 インスタンスで簡易自動復旧を設定する](instance-configuration-recovery.md)
+ [EC2 インスタンスでの CloudWatch アクションベースの復旧の設定](cloudwatch-recovery.md)
## 自動インスタンス復旧の主な概念
自動インスタンスリカバリは基盤となるハードウェアまたはソフトウェアの障害が発生したときにインスタンスの可用性を自動的に復元し、Amazon EC2 EC2 機能です。
自動インスタンス復旧の主な概念は次のとおりです。
**設定オプション**
自動インスタンス復旧をサポートするように 2 つのメカニズムを設定できます。
+ [簡素化された自動リカバリ](instance-configuration-recovery.md): サポートされているインスタンスではデフォルトで有効になっています。
+ [CloudWatch アクションベースの復旧](cloudwatch-recovery.md): サポートされているインスタンスで手動設定が必要です。
**システムステータスのチェック**
システムステータスチェックはEC2 インスタンスが実行されるAWSインフラストラクチャを自動的にモニタリングします。
+ システムステータスチェックが失敗すると、 は自動インスタンス復旧AWSを開始し、影響を受けるインスタンスを別のハードウェアに移行しようとします。
+ システムステータスチェックが失敗した場合はホストのハードウェアまたはソフトウェアに問題があることを示し、インスタンス自体に問題がないことを示します。自動インスタンス復旧ではシステムステータスチェックに失敗したインスタンスを復旧できます。ただし、インスタンスステータスチェックのみが失敗した場合、自動インスタンス復旧は動作しません。
+ インスタンスとシステムのステータスチェックの違いについては[「ステータスチェックのタイプ」](monitoring-system-instance-status-check.md#types-of-instance-status-checks)を参照してください。
**基盤となるハードウェアまたはソフトウェアの問題の例**
システムステータスチェックが失敗する原因となるハードウェアまたはソフトウェアの問題にはネットワーク接続の喪失、システム電源の喪失、物理ホスト上のソフトウェアの問題、およびネットワークの到達可能性に影響を与える物理ホスト上のハードウェアの問題が含まれます。
**復旧されたインスタンスの特徴**
復元されたインスタンスは失われた要素を除いて、元のインスタンスと同じです。
保存済み要素：
+ [インスタンス ID]
+ パブリック IP アドレス、プライベート IP アドレス、Elastic IP アドレス
+ インスタンスメタデータ
+ 配置グループ
+ アタッチされた EBS ボリューム
+ アベイラビリティーゾーン (AZ)
失われた要素：
+ 揮発性メモリ (RAM) に保存されるデータ
+ インスタンスストアボリュームに保存されているデータ (CloudWatch アクションベースの復旧にのみ適用）
+ オペレーティングシステムの稼働時間がゼロにリセットされる
**CloudWatch によるシステムステータスチェックのモニタリング**
CloudWatch の [StatusCheckFailed\$1System](viewing_metrics_with_cloudwatch.md#status-check-metrics) メトリクスはシステムステータスチェックが成功したか失敗したかを示します。
メトリクス値
+ **0** – システムステータスチェックに合格しました。
+ **1** – 失敗したシステムステータスチェック
**Health Dashboard でのイベント。**
自動インスタンス復旧の試行中に、 は設定された復旧メカニズムとその結果Health Dashboardに基づいてイベントを AWSに送信します。
+ 簡易自動復旧
+ 成功イベント: `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS`
+ 失敗イベント: `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE`
+ CloudWatch アクションに基づく復旧
+ 成功イベント: `AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS`
+ 失敗イベント: `AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE`
## 簡易自動復旧と CloudWatch アクションベースの復旧の違い
次の表は簡易自動復旧と CloudWatch アクションベースの復旧の主な違いを比較したものです。
| 比較ポイント | 簡易自動復旧 | CloudWatch アクションに基づく復旧 |
| --- | --- | --- |
| 設定 | サポートされているインスタンスでデフォルトで有効 | CloudWatch アラームとアクションの手動設定が必要です |
| 柔軟性 | によって管理される復旧動作を修正しました。 AWS | カスタマイズ可能なアクションと条件 |
| Notification | Health Dashboard での通知 | SNS によるカスタマイズ可能な通知 |
| ベアメタルインスタンスサイズ | 除外 | 含まれる |
| インスタンスストアボリュームはインスタンスの起動時にのみアタッチされます。 | 起動時にインスタンスストアボリュームをアタッチするインスタンスではサポートされていません | 選択したインスタンスタイプでサポートされています。インスタンスストアボリュームのデータはインスタンスの復旧中に失われることに注意してください。 |
| 復旧時間 | 標準復旧の試行 | 簡易自動復旧よりも高速な復旧の試行 |
| 移行中のホストの問題の解決 | 移行がキャンセルされ、インスタンスが元のホストに留まる可能性がある | 新しいホストへの移行の継続 |
| Cost | 追加料金 | CloudWatch 料金が発生する可能性があります |
## 回復力のあるシステムを構築する
簡易自動復旧と CloudWatch アクションベースの復旧は個々のインスタンスの可用性を維持するのに効果的ですが、AWS では正常なインスタンスへのトラフィックのフェイルオーバーを可能にする高可用性アーキテクチャを実装することをお勧めします。
これを実現するにはElastic Load Balancing (受信トラフィックを複数の EC2 インスタンスに分散させる) や Amazon EC2 Auto Scaling (需要と状態に基づいてインスタンス数を自動的に調整する) などの AWS サービスの使用を検討してください。
EC2 インスタンスを使用して回復力と耐障害性を備えたシステムを構築する方法の詳細については以下のリソースを参照してください。
+ *AWS YouTube *[チャンネルの「基本に戻る: EC2 での障害に対する設計](https://www.youtube.com/watch?v=5Hq5YxOrKYs)」
+ [のディザスタリカバリ (DR) アーキテクチャ、AWSパート](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) I: *AWS クラウドにおけるリ*カバリ
+ [Application Load Balancer のユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Amazon EC2 Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [REL11-BP02 信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_failover2good.html)AWS Well-Architected フレームワークの*正常なリソースにフェイルオーバーする*
# 自動インスタンス復旧が発生したかどうかを確認する
インスタンスがオフラインになっていて、予期せず再起動されたように見える場合は基盤となるハードウェアまたはソフトウェアの問題に応じて[、インスタンスが自動復旧](ec2-instance-recover.md#ec2-automatic-instance-recovery-key-concepts)された可能性があります。これを確認するには でインスタンスの自動復旧イベントを確認しますHealth Dashboard。**StatusCheckFailed\$1System** Amazon CloudWatch メトリクスを確認することで、インスタンスの基盤となるハードウェアまたはソフトウェアの問題が検出されたかどうかを確認することもできます。
## でイベントを確認する Health Dashboard
自動インスタンス復旧の試行が発生すると、 AWSはイベントを に送信しますHealth Dashboard。特定のイベントは設定された復旧メカニズムと、試行が成功したか失敗したかによって異なります。
**で自動インスタンス復旧イベントを確認するには Health Dashboard**
1. [https://phd.aws.amazon.com/phd/home\$1/](https://phd.aws.amazon.com/phd/) で 「Health Dashboard」 を開きます。
1. 自動インスタンス復旧に関連するイベントを探します。これらのイベントが存在すると、自動インスタンス復旧の試行が発生したかどうか、およびその結果を確認できます。
+ 簡易自動復旧
+ 成功イベント: `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS`
+ 失敗イベント: `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE`
+ CloudWatch アクションに基づく復旧
+ 成功イベント: `AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS`
+ 失敗イベント: `AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE`
## CloudWatch でシステムステータスチェックをモニタリングする
CloudWatch で [StatusCheckFailed\$1System](viewing_metrics_with_cloudwatch.md#status-check-metrics) メトリクスを確認することで、インスタンスの基盤となるハードウェアまたはソフトウェアの問題が検出されたかどうかを確認できます。メトリクス値はシステムステータスチェックに合格した (ハードウェアまたはソフトウェアの問題がない) か、失敗した (ハードウェアまたはソフトウェアの問題) かを示します。
**基盤となるハードウェアまたはソフトウェアの問題が検出されたかどうかを確認するには**
1. **CloudWatch ** コンソールの [https://console.aws.amazon.com/cloudwatch/home?\$1metricsV2](https://console.aws.amazon.com/cloudwatch/home?#metricsV2) を開いてください。
1. EC2 インスタンスと同じリージョンで操作していることを確認します。
1. メトリクス検索フィールドに次の**メトリクス**を貼り付け、エンター キーを押します。
```
StatusCheckFailed_System
```
1. **EC2 メトリクス**. 、[インスタンス別メトリクス] を選択します。
1. テーブルで、チェックするインスタンスの横にあるチェックボックスをオンにします。
1. クエリ期間を、復旧イベントが発生したと思われる時間に変更します。
1. **グラフ化されたメトリクス**タブを選択し、**StatusCheckFailed\$1System** で次の操作を行います。
1. **統計** で、**平均**、**最大**、**最小**のいずれかを選択してください。
1. **[期間]** は**[1 minute]** を選択してください。
1. **StatusCheckFailed\$1System** の値を確認します。
+ 値 **0**: システムステータスチェックに合格し、基盤となるハードウェアまたはソフトウェアの問題がないことを示します。
+ 値 **1**: システムステータスチェックが失敗し、基盤となるハードウェアまたはソフトウェアの問題が示されます。
詳細については「[インスタンスの自動復旧](ec2-instance-recover.md)」を参照してください。
# Amazon EC2 インスタンスで簡易自動復旧を設定する
**重要**
このセクションではEC2 インスタンスで復旧メカニズムをプロアクティブに設定する方法について説明します。これらの復旧メカニズムは がシステムステータスチェックが失敗する原因となる基盤となるハードウェアまたはソフトウェアの問題AWSを検出したときに、インスタンスの可用性を復元するように設計されています。インスタンスへのアクセスで現在問題が発生している場合は「[EC2 インスタンスのトラブルシューティング](ec2-instance-troubleshoot.md)」を参照してください。
が基盤となるハードウェアまたはソフトウェアの問題によりインスタンスが使用できないことをAWS検出した場合、*簡易自動復旧*は基盤となる問題のあるインスタンスをホストから別のホストに移動することで、インスタンスの可用性を自動的に復元できます。
簡易自動復旧が発生した場合、 AWSは結果に応じてAWS Health Dashboard、次のいずれかのイベントを に送信します。
+ 成功イベント: `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS`
+ 失敗イベント: `AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE`
これらのイベントの通知を受け取るには通知を設定できます。詳細については*AWS User Notifications「ユーザーガイド」*の[ での「最初の通知設定の作成」AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html)を参照してください。[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) ルールを使用して、次のイベントコードを使って簡易自動復旧のイベントをモニタリングすることもできます。
サポート対象のインスタンスを起動すると、簡易自動復旧がデフォルトで有効になります。ただし、インスタンスが `running`状態であり、 にサービスイベントがリストされておらずAWS Health Dashboard、インスタンスタイプに使用可能な容量がある場合にのみ動作できます。大幅な停止などの状況では容量の制約により復旧の試行が失敗する可能性があります。詳細については「[簡易自動復旧障害のトラブルシューティング](#ec2-instance-recover-simplified-auto-recovery-troubleshooting)」を参照してください。
起動中または起動後に簡易自動復旧を無効にし、必要に応じて後で再度有効にすることができます。
**警告**
基盤となるハードウェアまたはソフトウェアの問題により がインスタンスをAWS復旧する場合、次の結果に注意してください。揮発性メモリ (RAM) に保存されているデータは失われ、オペレーティングシステムの稼働時間はゼロから開始されます。データ損失を防ぐために、重要なデータのバックアップを定期的に作成することをお勧めします。Amazon EC2 インスタンスのバックアップと復旧のベストプラクティスの詳細については「[Amazon EC2 のベストプラクティス](ec2-best-practices.md)」を参照してください。
自動インスタンス復旧メカニズムは*個々のインスタンス*用に設計されています。回復力のある*システム*の構築に関するガイダンスについては[回復力のあるシステムを構築する](ec2-instance-recover.md#instance-recovery-build-a-resilient-system)を参照してください。
**Topics**
+ [簡易自動復旧の要件と制限](#requirements-for-simplified-automatic-recovery)
+ [簡易自動復旧を設定する](#set-recovery-behavior)
+ [簡易自動復旧障害のトラブルシューティング](#ec2-instance-recover-simplified-auto-recovery-troubleshooting)
## 簡易自動復旧の要件と制限
簡易自動復旧は次の条件を満たすインスタンスで有効にできます。
**インスタンスのタイプ**
+ **汎用:** A1、M3、M4、M5、M5a、M5n、M5zn、M6a、M6g、M6i、M6in、M7a、M7g、M7i、M7i-flex、M8a、 M8azn、M8g、M8gb、M8gn、M8i、M8i-flex、T1、T2、T3、T3a、T4g
+ **コンピューティング最適化:** C3、C4、C5、C5a、C5n、C6a、C6g、C6gn、C6i、C6in、C7a、C7g、C7gn、C7i、C7i-flex、C8a、C8g、C8gb、C8gn、C8i、C8i-flex
+ **メモリ最適化:** R3、R4、R5、R5a、R5b、R5n、R6a、R6g、R6i、R6in、R7a、R7g、R7i、R7iz、R8a、R8g、R8gb、R8gn、R8i、R8i-flex、U-3tb1、U-6tb1、U-9tb1、U-12tb1、U-18tb1、U-24tb1、U7i-6tb、U7i-8tb、U7i-12tb、U7in-16tb、U7in-24tb、U7in-32tb、U7inh-32tb、X1、X1e、X2iezn、X8g、X8i
+ **高速コンピューティング:** G3、G5g、Inf1、P3、VT1
+ **ハイパフォーマンスコンピューティング: **Hpc6a、Hpc7a、Hpc7g、Hpc8a
**テナンシー**
+ Shared
+ Dedicated Instance
詳細については「[Amazon EC2 ハードウェア専有インスタンス](dedicated-instance.md)」を参照してください。
**制限事項**
以下の特性を持つインスタンスでは、簡易自動復旧はサポートされていません。
+ インスタンスサイズ: `metal`インスタンス
+ テナンシー: 専用ホスト。専用ホスト の場合は代わりに [Dedicated Host Auto Recovery](dedicated-hosts-recovery.md) を使用します。
+ ストレージ: インスタンスストアボリュームを持つインスタンス
+ ネットワーク: エラスティックファブリックアダプタ を使用するインスタンス
+ Auto Scaling: Auto Scaling グループの一部であるインスタンス
+ メンテナンス: スケジュールされたメンテナンスイベントを現在実行しているインスタンス
## 簡易自動復旧を設定する
サポート対象のインスタンスを起動すると、簡易自動復旧がデフォルトで有効になります。インスタンスの起動中または起動後の自動復旧動作を `disabled` に設定できます。
簡易自動復旧をサポートしていないインスタンスタイプではこの機能は`default` 設定で有効化されません。
------
#### [ Console ]
**起動時に簡易自動復旧を無効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、**[Instances]** (インスタンス)、**[Launch instance]** (インスタンスの起動) の順に選択してください。
1. **[Advanced details]** (高度な詳細) セクションの **[Instance auto-recovery]** (インスタンスの自動復旧) で、**[Disabled]** (無効) を選択してください。
1. 必要に応じて残りのインスタンスの起動設定を設定し、インスタンスを起動します。
**起動後に簡易自動復旧を無効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. [**Actions (アクション)**]、[**Instance settings (インスタンスの設定)**]、[**Change shutdown behavior (自動復旧動作を変更)**] の順に選択します 現在の動作が選択されます。
1. **[Off]** (オフ) を選択した上で、**[Save]** (保存) をクリックしてください。
**起動後に簡易自動復旧を有効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. [**Actions (アクション)**]、[**Instance settings (インスタンスの設定)**]、[**Change shutdown behavior (自動復旧動作を変更)**] の順に選択します 現在の動作が選択されます。
1. **[デフォルト]** を選択した上で、**[保存]** をクリックしてください。
------
#### [ AWS CLI ]
**起動時に簡易自動復旧を無効にするには**
`--maintenance-options` オプションで [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instance.html) コマンドを使用します。
```
--maintenance-options AutoRecovery=Disabled
```
**起動後に簡易自動復旧を無効にするには**
[modify-instance-maintenance-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-maintenance-options.html) コマンドを使用します。
```
aws ec2 modify-instance-maintenance-options \
--instance-id i-1234567890abcdef0 \
--auto-recovery disabled
```
**起動後に簡易自動復旧を有効にするには**
[modify-instance-maintenance-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-maintenance-options.html) コマンドを使用します。
```
aws ec2 modify-instance-maintenance-options \
--instance-id i-1234567890abcdef0 \
--auto-recovery default
```
------
#### [ PowerShell ]
**起動時に簡易自動復旧を無効にするには**
[New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) コマンドレットを使用します。
```
-MaintenanceOptions_AutoRecovery Disabled
```
**起動後に簡易自動復旧を無効にするには**
[Edit-EC2InstanceMaintenanceOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMaintenanceOption.html) コマンドレットを使用します。
```
Edit-EC2InstanceMaintenanceOption `
-InstanceId i-1234567890abcdef0 `
-AutoRecovery Disabled
```
**起動後に簡易自動復旧を有効にするには**
[Edit-EC2InstanceMaintenanceOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceMaintenanceOption.html) コマンドレットを使用します。
```
Edit-EC2InstanceMaintenanceOption `
-InstanceId i-1234567890abcdef0 `
-AutoRecovery Enabled
```
------
## 簡易自動復旧障害のトラブルシューティング
次の問題により、インスタンスの自動復旧が失敗する可能性があります。
+ AWS サービスイベントが実行されている
簡易自動復旧は AWS Health Dashboard のサービスイベント中には動作しません。これらのイベントが原因で復旧が失敗しても、その通知を受信しない可能性があります。最新のサービス可用性情報については「[サービスヘルス](https://health.aws.amazon.com/health/status)」のステータスページを参照してください。
+ 容量不足
インスタンスを移行するための代替ハードウェアが一時的に不足しています。
+ 1 日あたりの最大復旧試行回数に達しました
インスタンスが、1 日に許可されている復旧試行の最大数に達しました。自動復旧が失敗し、元のシステムステータスチェックエラーの根本原因がハードウェアの機能低下であると判断された場合、対象のインスタンスが使用停止になることがあります。
複数の復旧試行にもかかわらずインスタンスのシステムステータスチェックエラーが続く場合は[「ステータスチェックに失敗したインスタンスのトラブルシューティング](TroubleshootingInstances.md)」を参照して、追加のガイダンスを確認してください。
# EC2 インスタンスでの CloudWatch アクションベースの復旧の設定
**重要**
このセクションではEC2 インスタンスで復旧メカニズムをプロアクティブに設定する方法について説明します。これらの復旧メカニズムは がシステムステータスチェックが失敗する原因となる基盤となるハードウェアまたはソフトウェアの問題AWSを検出したときに、インスタンスの可用性を復元するように設計されています。インスタンスへのアクセスで現在問題が発生している場合は「[EC2 インスタンスのトラブルシューティング](ec2-instance-troubleshoot.md)」を参照してください。
は基盤となるハードウェアまたはソフトウェアの問題によりインスタンスが使用できないことをAWS検出した場合、*CloudWatch アクションベースのリカバリ*は基盤となる問題のあるホストから別のホストにインスタンスを移動することで、インスタンスの可用性を自動的に復元できます。
CloudWatch アクションベースの復旧が発生した場合、 AWSは結果に応じてAWS Health Dashboard、次のいずれかのイベントを に送信します。
+ 成功イベント: `AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS`
+ 失敗イベント: `AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE`
Amazon CloudWatch アクションベースの復旧を設定して、Amazon CloudWatch アラームに復旧アクションを追加できます。CloudWatch アクションベースの復旧は `StatusCheckFailed_System` メトリクスを使用して機能します。CloudWatch アクションベースの復旧機能は、復旧アクションと結果に関する、最新の復旧応答時間の詳細度と Amazon Simple Notification Service (Amazon SNS) 通知を提供します。これらの設定オプションにより、簡易自動復旧と比較して、システムステータスチェックの障害イベントの応答をより詳細に制御して、より迅速な復旧試行が可能になります。使用可能な CloudWatch オプションの詳細については「[インスタンスのステータスチェック](monitoring-system-instance-status-check.md)」を参照してください。
ただし、CloudWatch アクションベースの復旧はインスタンスが `running`状態にあり、 にサービスイベントがリストされておらずAWS Health Dashboard、インスタンスタイプに使用可能な容量がある場合にのみ動作できます。大幅な停止などの状況では容量の制約により復旧の試行が失敗する可能性があります。詳細については「[CloudWatch アクションベースの復旧障害のトラブルシューティング](#ec2-instance-recover-cloudwatch-troubleshooting)」を参照してください。
**警告**
基盤となるハードウェアまたはソフトウェアの問題により がインスタンスをAWS復旧する場合、次の結果に注意してください。揮発性メモリ (RAM) とインスタンスストアボリュームに保存されているデータは失われ、オペレーティングシステムの稼働時間はゼロから開始されます。データ損失を防ぐために、重要なデータのバックアップを定期的に作成することをお勧めします。Amazon EC2 インスタンスのバックアップと復旧のベストプラクティスの詳細については「[Amazon EC2 のベストプラクティス](ec2-best-practices.md)」を参照してください。
自動インスタンス復旧メカニズムは*個々のインスタンス*用に設計されています。回復力のある*システム*の構築に関するガイダンスについては[回復力のあるシステムを構築する](ec2-instance-recover.md#instance-recovery-build-a-resilient-system)を参照してください。
**Topics**
+ [CloudWatch アクションベースの復旧の要件と制限](#requirements-for-cloudwatch-action-based-recovery)
+ [CloudWatch アクションベースの復旧](#ec2-instance-recover-cloudwatch-configure)
+ [CloudWatch アクションベースの復旧障害のトラブルシューティング](#ec2-instance-recover-cloudwatch-troubleshooting)
## CloudWatch アクションベースの復旧の要件と制限
CloudWatch アクションベースの復旧は次の条件を満たすインスタンスで有効にできます。
**インスタンスのタイプ**
+ **汎用:** A1、M3、M4、M5、M5a、M5n、M5zn、M6a、M6g、M6i、M6in、M7a、M7g、M7i、M7i-flex、M8a、 M8azn、M8g、M8gb、M8gn、M8i、M8i-flex、T1、T2、T3、T3a、T4g
+ **コンピューティング最適化:** C3、C4、C5、C5a、C5n、C6a、C6g、C6gn、C6i、C6in、C7a、C7g、C7gn、C7i、C7i-flex、C8a、C8g、C8gb、C8gn、C8i、C8i-flex
+ **メモリ最適化:** R3、R4、R5、R5a、R5b、R5n、R6a、R6g、R6i、R6in、R7a、R7g、R7i、R7iz、R8a、R8g、R8gb、R8gn、R8i、R8i-flex、U-3tb1、U-6tb1、U-9tb1、U-12tb1、U-18tb1、U-24tb1、U7i-6tb、U7i-8tb、U7i-12tb、U7in-16tb、U7in-24tb、U7in-32tb、U7inh-32tb、X1、X1e、X2idn、X2iedn、X2iezn、X8g、X8i
+ **高速コンピューティング:** G3、G5g、Inf1、P3、VT1
+ **ハイパフォーマンスコンピューティング: **Hpc6a、Hpc7a、Hpc7g、Hpc8a
+ **メタルインスタンス:** メタルインスタンスサイズを持つ上記のインスタンス タイプのいずれか。
+ **起動時にインスタンスストアボリュームが追加された場合：** 次のインスタンス タイプのみがサポートされます: M3、C3、R3、X1、X1e、X2idn、X2iedn
**テナンシー**
+ Shared
+ Dedicated Instance
詳細については「[Amazon EC2 ハードウェア専有インスタンス](dedicated-instance.md)」を参照してください。
**制限事項**
CloudWatch アクションベースの復旧は次の特性を持つインスタンスではサポートされていません。
+ テナンシー: 専用ホスト。専用ホスト の場合は代わりに [Dedicated Host Auto Recovery](dedicated-hosts-recovery.md) を使用します。
+ ネットワーク: エラスティックファブリックアダプタ を使用するインスタンス
+ Auto Scaling: Auto Scaling グループの一部であるインスタンス
+ メンテナンス: スケジュールされたメンテナンスイベントを現在実行しているインスタンス
### サポートされているインスタンスタイプの検索
CloudWatch アクションベースの復旧をサポートする、インスタンスタイプを表示することができます。
------
#### [ Console ]
**Amazon CloudWatch アクションベースの復旧をサポートするインスタンスタイプを表示するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. 左のナビゲーションペインで、**[Instance Types]** (インスタンスタイプ) を選択してください。
1. フィルタバーで、**[自動復旧のサポート] = [true]** をフィルタリングします。**[インスタンスタイプ]** テーブルには、Amazon CloudWatch アクションベースの復旧をサポートするすべてのインスタンスタイプが表示されます。
1. (オプション) フィルターを追加して、対象の、特定のインスタンスタイプをさらに絞り込みます。
------
#### [ AWS CLI ]
**Amazon CloudWatch アクションベースの復旧をサポートするインスタンスタイプを表示するには**
[describe-instance-types](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-types.html) コマンドを `auto-recovery-supported` フィルターと共に使用します。
```
aws ec2 describe-instance-types \
--filters Name=auto-recovery-supported,Values=true \
--query "InstanceTypes[*].[InstanceType]" \
--output text | sort
```
------
#### [ PowerShell ]
**Amazon CloudWatch アクションベースの復旧をサポートするインスタンスタイプを表示するには**
[Get-EC2InstanceType](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceType.html) コマンドレットを `auto-recovery-supported` フィルタと共に使用します。
```
Get-EC2InstanceType `
-Filter @{Name="auto-recovery-supported";Values="true"} | `
Select InstanceType | Sort-Object InstanceType
```
------
## CloudWatch アクションベースの復旧
EC2 インスタンスの CloudWatch アクションベースの復旧を設定するには指定されたインスタンスの `StatusCheckFailed_System`メトリクスをモニタリングする CloudWatch アラームを作成します。メトリクス値が **1** の場合にトリガーされるようにアラームを設定します。これはシステムステータスチェックが失敗したことを示します。トリガーされたときにインスタンスを自動的に復旧するようにアラームアクションを設定します。
Amazon EC2 コンソールまたは CloudWatch コンソールを使用してアラームを作成できます。手順についてはこのユーザーガイドの「[Amazon CloudWatch アラームへの復旧アクションの追加](UsingAlarmActions.md#AddingRecoverActions)」、または「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch アラームへの復旧アクションの追加](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingRecoverActions)」を参照してください。
## CloudWatch アクションベースの復旧障害のトラブルシューティング
次の問題により、CloudWatch アクションベースの復旧によるインスタンスの復旧が失敗する場合があります。
+ AWS サービスイベントが実行されている
CloudWatch アクションベースの復旧はAWS Health Dashboard のサービスイベント中は動作しません。これらのイベントが原因で復旧が失敗しても、その通知を受信しない可能性があります。最新のサービス可用性情報については「[サービスヘルス](https://health.aws.amazon.com/health/status)」のステータスページを参照してください。
+ 容量不足
インスタンスを移行するための代替ハードウェアが一時的に不足しています。
+ 1 日あたりの最大復旧試行回数に達しました
インスタンスが、1 日に許可されている復旧試行の最大数に達しました。自動復旧が失敗し、元のシステムステータスチェックエラーの根本原因がハードウェアの機能低下であると判断された場合、対象のインスタンスが使用停止になることがあります。
複数の復旧試行にもかかわらずインスタンスのシステムステータスチェックエラーが続く場合は[「ステータスチェックに失敗したインスタンスのトラブルシューティング](TroubleshootingInstances.md)」を参照して、追加のガイダンスを確認してください。