付録 A - パーティションサービスに関するガイダンス

パーティションサービスの場合は、AWS のサービスのコントロールプレーンに障害が発生してもワークロードの回復力を維持するために、静的安定性を実装する必要があります。以下では、パーティションサービスへの依存関係をどのように考慮するかと、コントロールプレーンの障害発生時に何が機能し、何が機能しない可能性があるかについての規範的なガイダンスを示します。

AWS Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) のコントロールプレーンは、IAM のすべてのパブリック API で構成されます (Access Advisor は含みますが、Access Analyzer や IAM Roles Anywhere は含みません)。これには、CreateRole、AttachRolePolicy、ChangePassword、UpdateSAMLProvider、UpdateLoginProfile などのアクションが含まれます。IAM のデータプレーンは、各 AWS リージョンの IAM プリンシパルに対して認証と承認を提供します。コントロールプレーンに障害が発生すると、IAM の CRUDL タイプのオペレーションは機能しない可能性がありますが、既存のプリンシパルの認証と承認は引き続き機能します。STS は、IAM とは別のデータプレーン専用のサービスであり、IAM のコントロールプレーンには依存しません。

つまり、IAM への依存関係を計画する場合、リカバリパスでは IAM のコントロールプレーンに依存すべきではありません。例えば、「ブレークグラス」の管理者ユーザー向けの静的に安定した設計では、適切なアクセス許可をアタッチしたユーザーの作成、パスワードの設定、アクセスキーとシークレットアクセスキーのプロビジョニングを行い、これらの認証情報を物理または仮想のボールトにロックします。緊急時に必要になった場合は、ボールトからユーザー認証情報を取り出し、ニーズに応じて使用します。静的に安定していない設計の場合、障害が発生した時点でユーザーをプロビジョニングするか、事前にユーザーをプロビジョニングしておきますが、管理者ポリシーは必要になったときにのみアタッチします。これらのアプローチは IAM のコントロールプレーンに依存します。

AWS Organizations

AWS Organizations のコントロールプレーンは、Organizations の AcceptHandshake、AttachPolicy、CreateAccount、CreatePolicy、ListAccounts などのすべてのパブリック API で構成されます。AWS Organizations には、データプレーンがありません。これは、他のサービス (IAM など) のデータプレーンをオーケストレーションします。コントロールプレーンに障害が発生すると、Organizations の CRUDL タイプのオペレーションは機能しない可能性がありますが、サービスコントロールポリシー (SCP) やタグポリシーなどのポリシーは引き続き機能し、IAM 承認プロセスの一部として評価されます。Organizations がサポートする、他の AWS のサービスの委任された管理者機能やマルチアカウント機能も引き続き機能します。

つまり、AWS Organizations への依存関係を計画する場合、リカバリパスでは Organizations のコントロールプレーンに依存すべきではありません。代わりに、復旧計画に静的安定性を実装してください。例えば、静的に安定していないアプローチでは、aws:RequestedRegion 条件を介して許可した AWS リージョンに対する制限を削除したり、特定の IAM ロールで管理者アクセス許可を有効にしたりするように SCP を更新します。この更新は、Organizations のコントロールプレーンに依存します。より適切なアプローチは、セッションタグを使用して管理者アクセス許可の使用を許可することです。ID プロバイダー (IdP) には、aws:PrincipalTag 条件に照らして評価できるセッションタグを含めることができます。これにより、SCP を静的なままに維持して、特定のプリンシパルに対するアクセス許可を動的に設定できます。これに伴って、コントロールプレーンへの依存関係がなくなり、データプレーンのアクションのみが使用されます。

AWS Account Management

AWS Account Management のコントロールプレーンは us-east-1 でホストされ、AWS アカウントを管理するためのすべてのパブリック API (GetContactInformation や PutContactInformation など) で構成されます。これには、管理コンソールでの AWS アカウントの新規作成や閉鎖も含まれます。CloseAccount、CreateAccount、CreateGovCloudAccount、DescribeAccount の API は、AWS Organizations のコントロールプレーンの一部です。このコントロールプレーンも us-east-1 でホストされます。さらに、AWS Organizations 外からの GovCloud アカウントの作成は、us-east-1 での AWS アカウント管理のコントロールプレーンに依存します。また、GovCloud アカウントは aws パーティション内の AWS アカウントに 1 対 1 でリンクする必要があります。aws-cn パーティションでのアカウント作成は us-east-1 に依存しません。AWS アカウントのデータプレーンはアカウント自体です。コントロールプレーンに障害が発生すると、AWS アカウントの CRUDL タイプのオペレーション (新しいアカウントの作成や連絡先情報の取得と更新など) は機能しない場合があります。IAM ポリシーでのアカウントへの参照は引き続き機能します。

つまり、AWS Account Management への依存関係を計画する場合、リカバリパスでは Account Management のコントロールプレーンに依存すべきではありません。Account Management のコントロールプレーンには、リカバリ状況で通常使用するような直接的な機能はありませんが、必要になる場合もあります。例えば、静的に安定した設計では、フェイルオーバーに必要なすべての AWS アカウントを事前にプロビジョニングします。静的に安定していない設計では、障害の発生時に DR リソースをホストするために新しい AWS アカウントを作成します。

Route 53 Application Recovery Controller

Route 53 ARC のコントロールプレーンは、Amazon Route 53 Application Recovery Controller のエンドポイントとクォータで示しているように、リカバリコントロールとリカバリの準備のための API で構成されます。コントロールプレーンを使用して、準備状況チェック、ルーティングコントロール、およびクラスターオペレーションを管理します。ARC のデータプレーンはリカバリクラスターであり、Route 53 のヘルスチェックでクエリするルーティングコントロール値を管理し、安全ルールも実装します。Route 53 ARC のデータプレーン機能には、https://aaaaaaaa.route53-recovery-cluster.eu-west-1.amazonaws.com などのリカバリクラスター API を介してアクセスします。

つまり、リカバリパスでは Route 53 ARC のコントロールプレーンに依存すべきではありません。このガイダンスの実装に役立つベストプラクティスが 2 つあります。

AWS Network Manager

AWS Network Manager サービスは、主に us-west-2 でホストされるコントロールプレーン専用のシステムです。その目的は、AWS アカウント、リージョン、オンプレミスのロケーションにまたがる AWS クラウド ワイドエリアネットワーク (WAN) のコアネットワークと AWS Transit Gateway ネットワークの設定を一元管理することです。また、us-west-2 でクラウド WAN メトリクスを集約します。これには、CloudWatch データプレーンを介してアクセスすることもできます。Network Manager に障害が発生しても、それがオーケストレーションするサービスのデータプレーンには影響しません。クラウド WAN の CloudWatch メトリクスは、us-west-2 でも利用できます。us-west-2 に影響する障害の発生時に他のリージョンに移動するトラフィック量を把握するなどの運用上の目的のために、リージョンごとの入出力バイト数などのメトリクスの履歴データが必要な場合は、これらのメトリクスを CloudWatch コンソールから直接 CSV データとしてエクスポートするか、Amazon CloudWatch メトリクスを CSV ファイルに発行することができます。データは AWS/Network Manager 名前空間の下で見つかります。これを、選択したスケジュールで実行し、S3 や別の選択したデータストアにデータを保存できます。静的に安定したリカバリプランを実装するには、AWS Network Manager を使用してネットワークを更新したり、コントロールプレーンオペレーションからのデータにフェイルオーバー入力を依存したりしないでください。

Route 53 のプライベート DNS

Route 53 のプライベートホストゾーンは、パーティションごとにサポートされていますが、Route 53 のプライベートホストゾーンとパブリックホストゾーンの考慮事項は同じです。「付録 B - エッジネットワークのグローバルサービスに関するガイダンス」の「Amazon Route 53」を参照してください。