# 付録 B - エッジネットワークのグローバルサービスに関するガイダンス
エッジネットワークのグローバルサービスでは、AWS のサービスのコントロールプレーンに障害が発生したときにワークロードの回復力を維持するために、静的安定性を実装する必要があります。
## Route 53
Route 53 のコントロールプレーンは、ホストゾーン、レコード、ヘルスチェック、DNS クエリログ、再利用可能な委託セット、トラフィックポリシー、コスト配分タグの各機能にわたる、Route 53 のすべてのパブリック API で構成されます。コントロールプレーンは、us-east-1 でホストされます。データプレーンは権威ある DNS サービスであり、200 を超える PoP ロケーションおよび各 AWS リージョンで実行され、ホストゾーンとヘルスチェックデータに基づいて DNS クエリに応答します。さらに、Route 53 にはヘルスチェック用のデータプレーンがあり、これも複数の AWS リージョンにまたがってグローバルに分散されたサービスです。このデータプレーンは、ヘルスチェックを実行し、結果を集約して、Route 53 のパブリックおよびプライベート DNS と AGA のデータプレーンに配信します。コントロールプレーンに障害が発生すると、Route 53 の CRUDL タイプのオペレーションは機能しない可能性がありますが、DNS 解決とヘルスチェック、およびヘルスチェックでの変更によるルーティングの更新は引き続き機能します。
つまり、Route 53 への依存関係を計画する場合、リカバリパスでは Route 53 のコントロールプレーンに依存すべきではありません。例えば、静的に安定した設計では、ヘルスチェックのステータスを利用してリージョン間でフェイルオーバーを実行したり、アベイラビリティーゾーンから退避したりします。[Route 53 Application Recovery Controller (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/)」と[「高度なマルチ AZ レジリエンスパターン」の「ヘルスチェックサーキットブレーカー」セクション](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/pattern-1-health-check-circuit-breaker.html)で概説しています。マルチリージョン DR プランを使用する場合は、ELB や RDS インスタンスなど、DNS レコードの作成を必要とするリソースを事前にプロビジョニングします。静的に安定していない設計では、`ChangeResourceRecordSets` API 経由で Route 53 リソースレコードの値を更新したり、加重レコードの重みを変更したり、新しいレコードを作成してフェイルオーバーを実行したりします。これらのアプローチは、Route 53 のコントロールプレーンに依存します。
## Amazon CloudFront
Amazon CloudFront のコントロールプレーンは、ディストリビューションを管理する CloudFront のすべてのパブリックAPI で構成され、us-east-1 でホストされます。データプレーンは、エッジネットワーク内の PoP から提供されるディストリビューション自体です。オリジンコンテンツのリクエスト処理、ルーティング、キャッシュを実行します。コントロールプレーンに障害が発生すると、CloudFront の CRUDL タイプのオペレーション (無効化リクエストを含む) は機能しない場合がありますが、コンテンツは引き続きキャッシュおよび配信され、[オリジンフェイルオーバー](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)は引き続き機能します。
つまり、CloudFront への依存関係を計画する場合、リカバリパスでは CloudFront のコントロールプレーンに依存すべきではありません。例えば、静的に安定した設計では、自動オリジンフェイルオーバーを使用して、いずれかのオリジンに対する障害の影響を軽減します。Lamda@Edge を使用してオリジン負荷分散またはフェイルオーバーを構築することもできます。このパターンの詳細については、「[Amazon CloudFront を使用した高可用性アプリケーションのための 3 つの高度な設計パターン](https://aws.amazon.com/blogs/networking-and-content-delivery/three-advanced-design-patterns-for-high-available-applications-using-amazon-cloudfront/)」および「[Amazon CloudFront と Amazon 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/)」を参照してください。静的に安定していない設計では、オリジンの障害に対応してディストリビューションの設定を手動で更新します。このアプローチは、CloudFront のコントロールプレーンに依存します。
### Amazon Certificate Manager
CloudFront ディストリビューションでカスタム証明書を使用している場合は、ACM にも依存します。CloudFront ディストリビューションでのカスタム証明書の使用は、us-east-1 リージョンでの ACM のコントロールプレーンに依存します。コントロールプレーンに障害が発生しても、ディストリビューションで設定されている既存の証明書と、証明書の自動更新は引き続き機能します。リカバリパスの一部として、ディストリビューションの設定の変更や、新しい証明書の作成には依存しないでください。
### AWS Web Application Firewall (WAF) および WAF クラシック
CloudFront ディストリビューションで AWS WAF を使用している場合は、同じく us-east-1 リージョンでホストされている WAF のコントロールプレーンに依存することになります。コントロールプレーンに障害が発生しても、設定済みのウェブアクセスコントロールリスト (ACL) および関連するルールは引き続き機能します。リカバリパスの一部として WAF のウェブ ACL の更新には依存しないでください。
## AWS Global Accelerator
AGA のコントロールプレーンは、AGA のすべてのパブリック API で構成され、us-west-2 でホストされます。データプレーンは、登録済みのエンドポイントに対する AGA が提供するエニーキャスト IP アドレスのネットワークルーティングです。また、AGA は Route 53 ヘルスチェックを利用して、Route 53 のデータプレーンの一部である、AGA エンドポイントのヘルスを判断します。コントロールプレーンに障害が発生すると、AGA の CRUDL タイプのオペレーションは機能しない場合があります。既存のエンドポイントへのルーティングに加えて、他のエンドポイントやエンドポイントグループへのトラフィックのルーティングや移動に使用する既存のヘルスチェック、トラフィックダイヤル、エンドポイントの重み設定は、引き続き機能します。
つまり、AGA への依存関係を計画する場合、リカバリパスでは AGA のコントロールプレーンに依存すべきではありません。例えば、静的に安定した設計では、設定済みのヘルスチェックのステータスを利用して、異常のあるエンドポイントからフェイルアウェイします。この設定の例については、「[AWS Global Accelerator を使用して AWS でマルチリージョンアプリケーションをデプロイする](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/)」を参照してください。静的に安定していない設計では、障害発生時に AGA トラフィックダイヤルのパーセンテージを変更したり、エンドポイントグループを編集したり、エンドポイントグループからエンドポイントを削除したりします。これらのアプローチは、AGA のコントロールプレーンに依存します。
## Amazon Shield Advanced
Amazon Shield Advanced のコントロールプレーンは、Shield Advanced のすべてのパブリック API で構成され、us-east-1 でホストされます。これには、`CreateProtection`、`CreateProtectionGroup`、`AssociateHealthCheck`、`DesribeDRTAccess`、`ListProtections` などの機能が含まれます。データプレーンは、Shield Advanced が提供する DDoS 保護と、Shield Advanced メトリクスの作成です。Shield Advanced は、Route 53 のヘルスチェック (Route 53 のデータプレーンの一部) も利用します (設定している場合)。コントロールプレーンに障害が発生すると、Shield Advanced の CRUDL タイプのオペレーションは機能しない場合があります。ただし、リソースに設定されている DDoS 保護やヘルスチェックでの変更への対応は引き続き機能します。
つまり、リカバリパスでは Shield Advanced のコントロールプレーンに依存すべきではありません。Shield Advanced のコントロールプレーンには、リカバリ状況で通常使用するような直接的な機能はありませんが、必要になる場合があります。例えば、静的に安定した設計では、障害発生後に保護を設定するのではなく、DR リソースを保護グループの一部として事前に設定し、リソースにヘルスチェックを関連付けます。これにより、リカバリを Shield Advanced のコントロールプレーンに依存する必要がなくなります。