# インスタンスの自動復旧
<a name="ec2-instance-recover"></a>

**重要**  
このセクションでは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)

## 自動インスタンス復旧の主な概念
<a name="ec2-automatic-instance-recovery-key-concepts"></a>

自動インスタンスリカバリは基盤となるハードウェアまたはソフトウェアの障害が発生したときにインスタンスの可用性を自動的に復元し、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 アクションベースの復旧の違い
<a name="differences"></a>

次の表は簡易自動復旧と CloudWatch アクションベースの復旧の主な違いを比較したものです。


| 比較ポイント | 簡易自動復旧 | CloudWatch アクションに基づく復旧 | 
| --- | --- | --- | 
| 設定 | サポートされているインスタンスでデフォルトで有効  | CloudWatch アラームとアクションの手動設定が必要です  | 
| 柔軟性 | によって管理される復旧動作を修正しました。 AWS | カスタマイズ可能なアクションと条件  | 
| Notification | Health Dashboard での通知  | SNS によるカスタマイズ可能な通知  | 
| ベアメタルインスタンスサイズ | 除外 | 含まれる | 
| インスタンスストアボリュームはインスタンスの起動時にのみアタッチされます。 | 起動時にインスタンスストアボリュームをアタッチするインスタンスではサポートされていません | 選択したインスタンスタイプでサポートされています。インスタンスストアボリュームのデータはインスタンスの復旧中に失われることに注意してください。 | 
| 復旧時間 | 標準復旧の試行 | 簡易自動復旧よりも高速な復旧の試行 | 
| 移行中のホストの問題の解決 | 移行がキャンセルされ、インスタンスが元のホストに留まる可能性がある | 新しいホストへの移行の継続 | 
| Cost | 追加料金 | CloudWatch 料金が発生する可能性があります | 

## 回復力のあるシステムを構築する
<a name="instance-recovery-build-a-resilient-system"></a>

簡易自動復旧と 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 フレームワークの*正常なリソースにフェイルオーバーする*