付録 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) ルーティングコントロールを使用して、ヘルスチェックのステータスを手動で変更したり、DNS クエリへの応答を変更したりできます。ARC が提供しているものと同様のパターンがあり、要件に応じて実装できます。これらのパターンの一部については、「Route 53 を使用したディザスタリカバリメカニズムの作成ChangeResourceRecordSets API 経由で Route 53 リソースレコードの値を更新したり、加重レコードの重みを変更したり、新しいレコードを作成してフェイルオーバーを実行したりします。これらのアプローチは、Route 53 のコントロールプレーンに依存します。
Amazon CloudFront
Amazon CloudFront のコントロールプレーンは、ディストリビューションを管理する CloudFront のすべてのパブリックAPI で構成され、us-east-1 でホストされます。データプレーンは、エッジネットワーク内の PoP から提供されるディストリビューション自体です。オリジンコンテンツのリクエスト処理、ルーティング、キャッシュを実行します。コントロールプレーンに障害が発生すると、CloudFront の CRUDL タイプのオペレーション (無効化リクエストを含む) は機能しない場合がありますが、コンテンツは引き続きキャッシュおよび配信され、オリジンフェイルオーバーは引き続き機能します。
つまり、CloudFront への依存関係を計画する場合、リカバリパスでは CloudFront のコントロールプレーンに依存すべきではありません。例えば、静的に安定した設計では、自動オリジンフェイルオーバーを使用して、いずれかのオリジンに対する障害の影響を軽減します。Lamda@Edge を使用してオリジン負荷分散またはフェイルオーバーを構築することもできます。このパターンの詳細については、「Amazon CloudFront を使用した高可用性アプリケーションのための 3 つの高度な設計パターン
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 でマルチリージョンアプリケーションをデプロイする
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 のコントロールプレーンに依存する必要がなくなります。
