本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
自動執行個體復原功能
重要
本節說明如何在 EC2 執行個體上主動設定復原機制。當 偵測到導致系統狀態檢查失敗的基礎硬體或軟體問題時 AWS ，這些復原機制旨在還原執行個體可用性。如果您目前在存取執行個體時遇到問題，請參閱對 EC2 執行個體進行故障診斷。
如果 AWS 偵測到執行個體因基礎硬體或軟體問題而無法使用，有兩種機制可以自動還原執行個體可用性：簡化的自動復原和 Amazon CloudWatch 動作型復原。還原執行個體可用性也稱為執行個體復原。
在執行個體復原程序期間， AWS 會嘗試將您的執行個體從具有基礎硬體或軟體問題的主機移至不同的主機。如果成功，執行個體復原程序會在執行個體上顯示為意外重新啟動。您可以驗證執行個體復原是否已發生。
如果復原程序失敗，執行個體可能會在主機上繼續執行，並出現基礎硬體或軟體問題。在這種情況下，需要手動介入。如果執行個體變得無法連線或系統狀態檢查持續失敗，建議您手動停止並啟動執行個體。當您啟動執行個體時，它通常會遷移到新的基礎主機電腦。不過，與執行個體保留其公有 IPv4 地址的自動執行個體復原不同，重新啟動的執行個體會收到新的公有 IPv4 地址，除非有彈性 IP 地址。
若要受益於自動復原機制，必須在 執行個體上預先設定，系統狀態檢查才會失敗。根據預設，執行個體啟動期間會啟用簡化的自動復原。您可以在啟動後選擇性地設定 Amazon CloudWatch 動作型復原。設定其中一個機制可讓您的執行個體更具彈性。
簡化的自動復原和 Amazon CloudWatch 動作型復原僅適用於支援的執行個體。如需詳細資訊，請參閱啟用簡化自動復原的需求及啟用 CloudWatch 動作型復原的需求。
警告
當 因基礎硬體或軟體問題而 AWS 復原執行個體時，請注意下列後果：儲存在揮發性記憶體 (RAM) 中的資料將會遺失，而且作業系統的執行時間會從零開始。此外，透過 CloudWatch 動作型復原，執行個體儲存體磁碟區上的資料也會遺失。為協助防範資料遺失，建議您定期建立重要資料的備份。如需 EC2 執行個體的備份和復原最佳實務的詳細資訊，請參閱 Amazon EC2 的最佳實務。
自動執行個體復原機制是專為個別執行個體所設計。如需建置彈性系統的指引，請參閱 建置彈性系統。
主題
自動執行個體復原的重要概念
自動執行個體復原是一項 Amazon EC2 功能，可在基礎硬體或軟體故障時自動還原執行個體可用性，進而增強 EC2 執行個體的彈性和可靠性。
以下是自動執行個體復原的重要概念：
- 組態選項
-
可以設定兩種機制來支援自動執行個體復原：
-
簡化的自動復原：在支援的執行個體上預設啟用。
-
CloudWatch 動作型復原：在支援的執行個體上需要手動設定。
-
- 系統狀態檢查
-
系統狀態檢查會自動監控 EC2 執行個體執行所在的 AWS 基礎設施。
-
如果系統狀態檢查失敗， 會 AWS 啟動自動執行個體復原，嘗試將受影響的執行個體遷移到不同的硬體。
-
失敗的系統狀態檢查表示主機的硬體或軟體有問題，而不是執行個體本身的問題。自動執行個體復原可以復原未通過系統狀態檢查的執行個體。不過，如果只有執行個體狀態檢查失敗，則自動執行個體復原不會運作。
-
如需執行個體和系統狀態檢查之間的差異，請參閱狀態檢查的類型。
-
- 基礎硬體或軟體問題的範例
-
可能導致系統狀態檢查失敗的硬體或軟體問題包括網路連線中斷、系統電源中斷、實體主機上的軟體問題，以及實體主機上會影響網路連線能力的硬體問題。
- 復原執行個體的特性
-
復原的執行個體與原始執行個體相同，但遺失的元素除外。
保留的元素：
-
執行個體 ID
-
公有、私有和彈性 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 | 可自訂的動作和條件 |
| 通知 | 透過 的基本通知 AWS Health Dashboard | 透過 SNS 自訂通知 |
| 金屬執行個體大小 | 已排除 | 包含 |
| 啟動時連接的執行個體存放區磁碟區 | 不支援在啟動時連接執行個體存放磁碟區的執行個體 | 在選取的執行個體類型上受支援。請注意，執行個體儲存體磁碟區上的資料會在執行個體復原期間遺失。 |
| 復原時間 | 標準復原嘗試 | 比簡化的自動復原更快的復原嘗試 |
| 主機問題會在遷移期間解決 | 遷移可能會取消，且執行個體會保留在原始主機上 | 遷移會繼續遷移至新的主機 |
| 費用 | 無需額外費用 | 可能會產生 CloudWatch 費用 |
建置彈性系統
雖然簡化的自動復原和 CloudWatch 動作型復原可有效維持個別執行個體的可用性，但 AWS 建議實作高可用性架構，以允許流量容錯移轉至運作狀態良好的執行個體。
若要達成此目的，請考慮使用 Elastic Load Balancing （將傳入流量分配到多個 EC2 執行個體） 和 Amazon EC2 Auto Scaling （根據需求和運作狀態自動調整執行個體數量） 等 AWS 服務。
如需使用 EC2 執行個體建置彈性、容錯系統的詳細資訊，請參閱下列資源：
