REL11-BP04 復原期間需使用資料平面，而非控制平面

控制平面是用來配置資源，資料平面用來提供服務。一般而言，資料平面的可用性設計目標會高於控制平面，且較為簡單。針對有可能影響彈性的事件實作復原或緩解回應時，使用控制平面作業可能會降低架構的整體彈性。例如，您可以使用 Amazon Route 53 資料平面，根據運作狀態檢查可靠地路由 DNS 查詢，但更新 Route 53 路由政策需使用控制平面，所以不要將控制平面用於復原。

Route 53 資料平面回答 DNS 佇列，以及執行並評估運作狀態檢查。它們遍布全球，而且針對 100% 可用性服務水準協議 (SLA) 設計的。 您可在其中建立、更新和刪除 Route 53 資源的 Route 53 管理 API 和主控台，在控制平面上執行，這些控制平面的設計旨在優先考慮您在管理 DNS 時所需的強式一致性和耐久性。為了實現此目標，控制平面位於單一區域 US East (N. Virginia) 中。儘管將這兩個系統建置為非常可靠，但控制平面未包含在 SLA 中。在極少數情況下，資料平面的彈性設計允許它保持可用性，而控制平面則不允許。對於災難復原和容錯移轉機制，使用資料平面功能提供可能最好的可靠性。

如需資料平面、控制平面，以及 AWS 如何建置服務以符合高可用性目標的詳細資計，請參閱 使用可用區域實現靜態穩定性 文件和 Amazon 建置者資料中心。

若未建立此最佳實務，暴露的風險等級： 高

實作指引

資源

相關文件：

相關範例：