本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

REL11-BP04 在復原期間依賴資料平面而非控制平面

控制平面提供APIs用於建立、讀取和描述、更新、刪除和列出 （CRUDL） 資源的管理，而資料平面則處理 day-to-day服務流量。對可能影響彈性的事件實作復原或緩解回應時，請盡量使用最少數量的控制平面操作來復原、重新擴展、還原、修復或容錯移轉服務。資料平面動作應取代這些降級事件期間的任何活動。

例如，以下全都是控制平面動作：啟動新的運算執行個體、建立區塊儲存，以及說明佇列服務。啟動運算執行個體時，控制平面必須執行多項工作，例如尋找具有容量的實體主機、配置網路介面、準備本機區塊儲存磁碟區、產生憑證，以及新增安全規則。控制平面往往是複雜的協同運作。

預期成果：當資源進入受損狀態時，系統能夠將流量從受損資源轉移到健康狀況良好的資源，來自動或手動復原。

常見的反模式：

建立此最佳實務的優勢：提高自動化修復的成功率可減少平均復原時間，並改善工作負載的可用性。

未建立此最佳實務時的風險暴露等級：中。對於某些類型的服務降級，則會影響控制平面。廣泛使用控制平面進行修復的相依性可能會增加復原時間 （RTO） 和平均復原時間 （MTTR）。

實作指引

若要限制資料平面動作，請評估每一項服務還原時所需的動作。

利用 Amazon Application Recovery Controller 來轉移DNS流量。這些功能會持續監控應用程式從故障中復原的能力，並可讓您控制跨多個 AWS 區域、可用區域和內部部署的應用程式復原。

Route 53 路由政策使用控制平面，因此不要依賴它進行復原。Route 53 資料平面會回答DNS查詢，並執行和評估運作狀態檢查。它們是全域分佈的，專為 100% 可用性服務層級協議 （SLA） 而設計。

您建立、更新和刪除 Route 53 資源的 Route 53 管理和APIs主控台，在控制平面上執行，其設計旨在優先考慮管理 時所需的強大一致性和耐用性DNS。為了實現此目標，控制平面位於單一區域中：美國東部 (維吉尼亞北部)。雖然這兩個系統都建置得非常可靠，但 中不包含控制平面SLA。在極少數情況下，資料平面的彈性設計允許它保持可用性，而控制平面則不允許。對於災難復原和容錯移轉機制，使用資料平面功能提供可能最好的可靠性。

將運算基礎設施設計為靜態穩定，以避免在事件期間使用控制平面。例如，如果您使用 Amazon EC2執行個體，請避免手動佈建新執行個體，或指示 Auto Scaling 群組在回應中新增執行個體。為獲得最高層級的彈性，請在用於容錯移轉的叢集中佈建足夠的容量。如果必須限制此容量閾值，請在整體 end-to-end系統上設定限流，以安全地限制到達有限資源集的總流量。

對於 Amazon DynamoDB 、Amazon API Gateway、負載平衡器和無 AWS Lambda 伺服器等服務，使用這些服務會利用資料平面。不過，建立新的函數、負載平衡器、API閘道或 DynamoDB 資料表是控制平面動作，應該在降級之前完成，作為事件的準備和容錯移轉動作的演練。對於 Amazon RDS，資料平面動作允許存取資料。

如需資料平面、控制平面以及如何 AWS 建置服務以滿足高可用性目標的詳細資訊，請參閱使用可用區域 的靜態穩定性。

了解哪些作業位於資料平面，哪些位於控制平面。

實作步驟

針對需要在降級事件之後還原的每個工作負載，評估容錯移轉執行手冊、高可用性設計、自動修復設計，或 HA 資源還原計畫。找出可能視為控制平面動作的每個動作。

考慮將控制動作變更為資料平面動作：

請考慮可讓資料平面動作影響相同修復措施的替代方法。

如果服務具任務關鍵性，請考慮次要區域中的某些服務，以便在未受影響的區域中執行更多控制平面和資料平面動作。

資源

相關的最佳實務：

相關文件：

相關影片：

相關範例：

相關工具：