本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 附錄 B-邊緣網路全球服務指南
對於邊緣網路全球服務，您應該實作靜態穩定性，以便在AWS服務控制平面損壞期間維持工作負載的彈性。
## Route 53
Route 53 控制平面包含所有公用 Route 53 API，涵蓋託管區域、記錄、健康狀態檢查、DNS 查詢記錄、可重複使用的委派集、流量原則和成本分配標記的功能。它託管在 us-east-1。資料平面是權威 DNS 服務，橫跨 200 多個 POP 位置執行AWS 區域，根據託管區域和運作狀態檢查資料回答 DNS 查詢。此外，Route 53 具有用於運行狀態檢查的數據平面，該數據平面也是跨多個全球分佈的服務。AWS 區域此資料平面執行運作狀態檢查、彙整結果，並將其傳遞到 Route 53 公有和私有 DNS 和 AGA 的資料平面。在控制平面障礙期間，Route 53 的 CRUD 類型作業可能無法運作，但 DNS 解析和健康狀態檢查，以及因健康狀態檢查變更而導致的路由更新將繼續運作。
這表示，當您規劃 Route 53 上的相依性時，您不應該依賴復原路徑中的 Route 53 控制平面。例如，靜態穩定的設計是使用健康狀態檢查的狀態在區域之間執行容錯移轉，或撤除可用區域。您可以使用 [Route 53 應用程式復原控制器 (ARC) 路由控制項](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.html)，手動變更健全狀況檢查的狀態，並變更 DNS 查詢的回應。有類似於 ARC 提供的模式，您可以根據您的要求實現。其中一些模式概述在[使用 Route 53 建立災難復原機制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)和[進階異地同步備份復原模式健康狀態檢查斷路器部分](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/pattern-1-health-check-circuit-breaker.html)。如果您選擇使用多區域 DR 計劃，請預先佈建需要建立 DNS 記錄的資源，例如 ELB 和 RDS 執行個體。non-statically-stable設計是透過 `ChangeResourceRecordSets` API 更新 Route 53 資源記錄的值、變更加權記錄的權重，或建立新記錄以執行容錯移轉。這些方法取決於 Route 53 控制平面。
## Amazon CloudFront
Amazon CloudFront 控制平面包含CloudFront用於管理分發的所有公用 API，並在 us-east-1 中託管。資料平面是從邊緣網路中提供的PoPs散佈本身。它會執行來源內容的要求處理、路由和快取。在控制平面受損期間，CloudFront(包括無效驗證要求) 的 CRUD 類型作業可能無法運作，但是您的內容將會繼續快取並提供服務，並且[原始容錯移轉](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)將會繼續運作。
這意味著，當您計劃依賴關係時CloudFront，您不應該依賴恢復路徑中的CloudFront控制平面。例如，靜態穩定的設計是使用自動來源容錯移轉來減輕從損害到您其中一個來源的影響。您也可以選擇使用 Lamda @Edge 建立原始負載平衡或容錯移轉，請參閱使用 Amazon 的[高可用性應用程式的三種進階設計模式和使用 Amazon CloudFront CloudFront 和 Amazon](https://aws.amazon.com/blogs/networking-and-content-delivery/three-advanced-design-patterns-for-high-available-applications-using-amazon-cloudfront/) [S3 建置多區域主動-主動式地理鄰近應用](https://aws.amazon.com/blogs/networking-and-content-delivery/using-amazon-cloudfront-and-amazon-s3-to-build-multi-region-active-active-geo-proximity-applications/)程式，以取得有關該模式的詳細資訊。一種non-statically-stable設計是手動更新發行版的配置以響應原始故障。這種方法將取決於CloudFront控制平面。
### Amazon Certificate Manager
如果您在CloudFront散發中使用自訂憑證，您也會對 ACM 具有相依性。將自訂憑證與 us-east-1 區域CloudFront中的 ACM 控制平面使用 us-east-1 區域中的 ACM 控制平面。在控制平面受損期間，您在發行版中設定的現有憑證將繼續運作，以及自動憑證續約。請勿依賴變更散發的組態或建立新憑證做為復原路徑的一部分。
### AWS網頁應用程式防火牆 (WAF) 和 WAF 典型
如果您AWS WAF與CloudFront發行版一起使用，則會依賴 WAF 控制平面，WAF 控制平面也託管在 us-east-1 區域中。在控制平面受損期間，設定的 Web 存取控制清單 (ACL) 及其相關規則會繼續運作。請勿依賴將 WAF Web ACL 更新為復原路徑的一部分。
## AWS Global Accelerator
AGA 控制平面由所有公開的 AGA API 組成，並託管在美國西部 -2 中。資料平面是 AGA 提供給您註冊端點的任意傳播 IP 位址的網路路由。AGA 還使用 Route 53 運行狀態檢查來確定 AGA 端點的健康狀態，這是 Route 53 數據平面的一部分。在控制平面減損期間，AGA 的 CRUD 型操作可能無法正常工作。路由傳送至您現有的端點，以及用於將流量路由或轉移到其他端點和端點群組的現有運作狀態檢查、流量撥號和端點加權組態，將會繼續運作。
這意味著，當您計劃依賴 AGA 時，您不應該依賴恢復路徑中的 AGA 控制平面。例如，靜態穩定的設計是使用已設定的健全狀況檢查的狀態，以便遠離健康狀態不良的端點。如需此組態的範例，請參閱[AWS使用AWS全域加速器中的〈部署多區域應](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)用程式〉。non-statically-stable設計是在損害期間修改 AGA 流量撥號百分比、編輯端點群組或從端點群組移除端點。這些方法將取決於 AGA 控制平面。
## Amazon Shield
亞馬遜 Shield 進階控制平面由所有公開 Shield 牌進階 API 組成，並託管於美國東部 -1。這包括功能 `CreateProtection``CreateProtectionGroup`，例如`AssociateHealthCheck`，`DesribeDRTAccess`，和`ListProtections`。數據層是由 Shield 高級提供的 DDoS 保護以及 Shield 高級指標的創建。Shield 進階也會使用 Route 53 健康狀態檢查 (這是 Route 53 資料平面的一部分)，如果您已設定這些檢查。在控制面障礙期間，Shield Advanced 的 CRUD 類型作業可能無法運作，但為您的資源設定的 DDoS 保護以及對運作狀態檢查變更的回應仍將繼續運作。
這意味著您不應該依賴恢復路徑中的 Shield 牌高級控制平面。雖然 Shield 進階控制平面無法提供您通常會在復原情況下使用的直接功能，但有時候您可能會這麼做。例如，靜態穩定的設計是將您的 DR 資源設定為保護群組的一部分，並進行與其相關聯的健康狀態檢查，而不是在故障發生後設定該保護。這樣可以防止根據 Shield 牌進階控制平面進行恢復。