Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

インスタンスの自動復旧

フォーカスモード
インスタンスの自動復旧 - Amazon Elastic Compute Cloud
重要

このセクションではEC2 インスタンスで復旧メカニズムをプロアクティブに設定する方法について説明します。これらの復旧メカニズムは がシステムステータスチェックが失敗する原因となる基盤となるハードウェアまたはソフトウェアの問題AWSを検出したときに、インスタンスの可用性を復元するように設計されています。インスタンスへのアクセスで現在問題が発生している場合は「EC2 インスタンスのトラブルシューティング」を参照してください。

基盤となるハードウェアの障害によりインスタンスが使用できないと AWS により判断された場合、インスタンスの耐障害性を設定して可用性を復元できるメカニズムとして簡易自動復旧または Amazon CloudWatch アクションベスの復旧のどちらかの方法で行われます。インスタンスの可用性の復元はインスタンスの復旧とも呼ばれます。

インスタンス復旧プロセス中に、 AWSは基盤となるハードウェアまたはソフトウェアの問題があるホストから別のホストにインスタンスを移動しようとします。インスタンスの復旧が成功すると、インスタンスには予期しない再起動として表示されます。インスタンスの復旧が発生したかどうかを確認できます

復旧プロセスが失敗した場合、基盤となるハードウェアまたはソフトウェアの問題により、インスタンスがホストで引き続き実行される可能性があります。この場合、手動による介入が必要です。インスタンスのシステムステータスチェックの失敗が続く場合はインスタンスを手動で停止および開始することをお勧めします。インスタンスを起動すると、通常、インスタンスは基盤となる新しいホストコンピュータに移行され、新しいパブリック IPv4 アドレスが割り当てられます。ただし、インスタンスがパブリック IPv4 アドレスを保持する自動インスタンスリカバリとは異なり、再起動されたインスタンスはElastic IP アドレスがない限り、新しいパブリック IPv4 アドレスを受け取ります。

自動復旧メカニズムを活用するにはシステムステータスチェックが失敗する前に、インスタンスで事前に設定する必要があります。サポート対象のインスタンスを起動すると、簡易自動復旧がデフォルトで有効になります。オプションで、起動後の Amazon CloudWatch アクションベースの復旧を設定できます。これらのメカニズムのいずれかを設定すると、インスタンスの耐障害性が向上します。

簡易自動復旧と Amazon CloudWatch アクションベースの復旧はサポートされているインスタンスでのみ使用できます。詳細については簡易自動復旧の要件と制限およびCloudWatch アクションベースの復旧の要件と制限を参照してください。

警告

基盤となるハードウェアまたはソフトウェアの問題により がインスタンスをAWS復旧する場合、次の結果に注意してください。揮発性メモリ (RAM) に保存されているデータは失われ、オペレーティングシステムの稼働時間はゼロから開始されます。さらに、CloudWatch アクションベースの復旧ではインスタンスストアボリュームのデータも失われます。データ損失を防ぐために、重要なデータのバックアップを定期的に作成することをお勧めします。Amazon EC2 インスタンスのバックアップと復旧のベストプラクティスの詳細については「Amazon EC2 のベストプラクティス」を参照してください。

自動インスタンス復旧メカニズムは個々のインスタンス用に設計されています。回復力のあるシステムの構築に関するガイダンスについては「」を参照してください回復力のあるシステムを構築する

自動インスタンス復旧の主な概念

自動インスタンスリカバリは基盤となるハードウェアまたはソフトウェアの障害が発生したときにインスタンスの可用性を自動的に復元し、Amazon EC2 EC2 機能です。

自動インスタンス復旧の主な概念は次のとおりです。

設定オプション

自動インスタンス復旧をサポートするように 2 つのメカニズムを設定できます。

システムステータスのチェック

システムステータスチェックはEC2 インスタンスが実行されるAWSインフラストラクチャを自動的にモニタリングします。

  • システムステータスチェックが失敗すると、 は自動インスタンス復旧AWSを開始し、影響を受けるインスタンスを別のハードウェアに移行しようとします。

  • システムステータスチェックが失敗した場合はホストのハードウェアまたはソフトウェアに問題があることを示し、インスタンス自体に問題がないことを示します。自動インスタンス復旧ではシステムステータスチェックに失敗したインスタンスを復旧できます。ただし、インスタンスステータスチェックのみが失敗した場合、自動インスタンス復旧は動作しません。

  • インスタンスとシステムのステータスチェックの違いについては「ステータスチェックのタイプ」を参照してください。

基盤となるハードウェアまたはソフトウェアの問題の例

システムステータスチェックが失敗する原因となるハードウェアまたはソフトウェアの問題にはネットワーク接続の喪失、システム電源の喪失、物理ホスト上のソフトウェアの問題、およびネットワークの到達可能性に影響を与える物理ホスト上のハードウェアの問題が含まれます。

復旧されたインスタンスの特徴

復元されたインスタンスは失われた要素を除いて、元のインスタンスと同じです。

保存済み要素:

  • [インスタンス ID]

  • パブリック IP アドレス、プライベート IP アドレス、Elastic IP アドレス

  • インスタンスメタデータ

  • 配置グループ

  • アタッチされた EBS ボリューム

  • アベイラビリティーゾーン

失われた要素:

  • 揮発性メモリ (RAM) に保存されるデータ

  • インスタンスストアボリュームに保存されているデータ (CloudWatch アクションベースの復旧にのみ適用)

  • オペレーティングシステムの稼働時間がゼロにリセットされる

CloudWatch によるシステムステータスチェックのモニタリング

CloudWatch の StatusCheckFailed_System メトリクスはシステムステータスチェックが成功したか失敗したかを示します。

メトリクス値

  • 0 – システムステータスチェックに合格しました。

  • 1 – 失敗したシステムステータスチェック

AWS Health Dashboard でのイベント。

自動インスタンス復旧の試行中に、 は設定された復旧メカニズムとその結果AWS 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 AWS Health Dashboard での通知 SNS によるカスタマイズ可能な通知
ベアメタルインスタンスサイズ 除外 含まれる
インスタンスストアボリュームはインスタンスの起動時にのみアタッチされます。 起動時にインスタンスストアボリュームをアタッチするインスタンスではサポートされていません 選択したインスタンスタイプでサポートされています。インスタンスストアボリュームのデータはインスタンスの復旧中に失われることに注意してください。
復旧時間 標準復旧の試行 簡易自動復旧よりも高速な復旧の試行
コスト 追加料金 CloudWatch 料金が発生する可能性があります

回復力のあるシステムを構築する

簡易自動復旧と CloudWatch アクションベースの復旧は個々のインスタンスの可用性を維持するのに効果的ですが、 では正常なインスタンスへのトラフィックのフェイルオーバーを可能にする高可用性アーキテクチャを実装AWSすることをお勧めします。

これを実現するにはElastic Load Balancing (受信トラフィックを複数の EC2 インスタンスに分散させる) や Amazon EC2 Auto Scaling (需要と状態に基づいてインスタンス数を自動的に調整する) などのAWSサービスの使用を検討してください。

EC2 インスタンスを使用して回復力と耐障害性を備えたシステムを構築する方法の詳細については以下のリソースを参照してください。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.