本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL11-BP02 容錯移轉至健全的資源
如果發生資源失敗，運作良好的資源應繼續處理請求。對於位置受損 （例如可用區域或 AWS 區域），請確定您已備妥系統，無法容錯移轉至未受損位置中的健全資源。
設計服務時，請將負載分散到各個資源、可用區域或區域。因此，可以透過將流量轉移到剩餘運作狀態良好的資源來減輕個別資源故障或損害的影響。請考慮發生故障時，如何找到服務及其路由。
設計服務時，務必考慮故障復原。在 AWS，我們設計 服務，以將從故障和對資料的影響中復原的時間降到最低。我們的服務主要使用的資料存放區，會在請求持久儲存於區域內的多個複本中之後，才確認請求。經過建構後，它們會使用以儲存格為基礎的隔離，以及使用可用區域提供的故障隔離。我們在營運程序中廣泛使用自動化。我們也最佳化功能 replace-and-restart，以快速從中斷中復原。
允許容錯移轉的模式和設計會隨著各 AWS 平台服務而有所不同。許多 AWS 原生受管服務都是原生多個可用區域 （例如 Lambda 或 API Gateway）。其他服務 AWS （例如 EC2和 EKS） 需要特定的最佳實務設計，以支援跨 的資源或資料儲存的容錯移轉AZs。
監控應設定為確認容錯移轉資源是否正常運作、追蹤資源容錯移轉的進度，以及監控業務程序復原。
預期成果：系統能夠自動或手動使用新資源，以從降級恢復。
常見的反模式：
-
故障計畫不是規劃和設計階段的一部分。
-
RTO 未建立 RPO 和 。
-
監控不足，無法偵測出失敗的資源。
-
正確隔離故障網域。
-
未考慮多區域容錯移轉。
-
決定進行容錯移轉時，失敗偵測太過敏感或積極。
-
未測試或驗證容錯移轉設計。
-
進行自動修復自動化，但未通知需要修復。
-
缺少緩衝期，以避免過早容錯恢復。
建立此最佳實務的優勢：您可以建置更具彈性的系統，在發生故障時透過適當降級並快速復原來維持可靠性。
未建立此最佳實務時的曝險等級：高
實作指引
AWS 服務，例如 Elastic Load Balancing 和 Amazon EC2 Auto Scaling ，有助於將負載分散到資源和可用區域。因此，將流量轉移到保持運作狀態良好的資源，可以減輕個別資源 （例如EC2執行個體） 的故障或可用區域受損。
對於多區域工作負載，設計會更複雜。例如，跨區域僅供讀取複本可讓您將資料部署至多個 AWS 區域。不過仍需要容錯移轉，才能將僅供讀取複本提升為主要複本，然後將流量指向新端點。Amazon Route 53、Amazon Application Recovery Controller （ARC）
AWS 服務，例如 Amazon S3、Lambda、APIGateway、Amazon SQS、Amazon SNS、Amazon SES、Amazon 、Amazon Pinpoint 、Amazon ECR AWS Certificate Manager EventBridge、 或 Amazon DynamoDB ，都會由 自動部署到多個可用區域 AWS。發生故障時， AWS 這些服務會自動將流量路由至運作狀態良好的位置。資料以冗餘方式存放在多個可用區域中，並且仍然可用。
對於 Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon EKS或 Amazon ECS，多可用區是組態選項。如果啟動容錯移轉， AWS 可以將流量導向至運作狀態良好的執行個體。此容錯移轉動作可能由 AWS 或客戶要求執行
對於 Amazon EC2執行個體、Amazon Redshift、Amazon ECS任務或 Amazon EKS Pod，您可以選擇要部署的可用區域。對於某些設計，Elastic Load Balancing 會提供解決方案，以偵測運作狀態不佳區域中的執行個體，並將流量路由至運作良好的區域。Elastic Load Balancing 也可將流量路由至內部部署資料中心內的元件。
對於多區域流量容錯移轉，重新路由可以利用 的 Amazon Route 53、Amazon Application Recovery Controller AWS Global Accelerator、Route 53 Private DNS for VPCs或 CloudFront ，提供一種方法來定義網際網路網域和指派路由政策，包括運作狀態檢查，以將流量路由至運作狀態良好的區域。 AWS Global Accelerator 提供作為應用程式固定進入點的靜態 IP 地址，然後使用 AWS 全球網路而不是網際網路路由至 AWS 區域 您選擇的端點，以獲得更好的效能和可靠性。
實作步驟
-
為所有適當的應用程式和服務建立容錯移轉設計。隔離每個架構元件，並RPO針對每個元件建立容錯移轉設計會議 RTO和 。
-
設定較低的環境 (例如開發或測試)，且其中所有服務都需要有容錯移轉計畫。使用基礎設施即程式碼 (IaC) 來部署解決方案，以確保可重複性。
-
設定復原站台 (例如第二個區域)，以實作和測試容錯移轉設計。如有必要，可以臨時設定測試的資源，以限制額外的成本。
-
決定哪些容錯移轉計劃由 自動執行 AWS，哪些計劃可以由 DevOps 程序自動執行，哪些計劃可能是手動的。記錄並測量每個服務的 RTO和 RPO。
-
建立容錯移轉程序手冊，並包括容錯移轉每個資源、應用程式和服務的所有步驟。
-
建立容錯恢復程序手冊，並包括容錯恢復 (含時程) 每個資源、應用程式和服務的所有步驟
-
制定計畫來啟動和演練程序手冊。使用模擬和混亂測試來測試程序手冊的步驟和自動化。
-
對於位置受損 （例如可用區域或 AWS 區域），請確定您已備妥系統，無法容錯移轉至未受損位置中的健全資源。在容錯移轉測試之前，檢查配額、自動擴展層級和執行的資源。
資源
相關 Well-Architected 的最佳實務：
相關文件：
相關範例：
