グローバルサービス

AWS のリージョンサービスとゾーンサービスに加えて、コントロールプレーンとデータプレーンがリージョン別に独立していない少数のAWS のサービスがあります。これらのリソースはリージョン固有ではないため、一般的にグローバルサービスと呼ばれます。AWS のグローバルサービスは、静的安定性を実現するために、コントロールプレーンとデータプレーンを分離するという AWS の従来の設計パターンに従っています。ほとんどのグローバルサービスの大きな違いは、コントロールプレーンが単一の AWS リージョンでホストされているのに対し、データプレーンはグローバルに分散されていることです。グローバルサービスには 3 つのタイプがあり、選択した設定によってはグローバルに見える一連のサービスもあります。

以下のセクションでは、各タイプのグローバルサービスと、これらのコントロールプレーンとデータプレーンがどのように分離されているかについて説明します。この情報を参考にして、グローバルサービスのコントロールプレーンに依存することなく、信頼性の高い高可用性 (HA) およびディザスタリカバリ (DR) メカニズムを構築できます。このアプローチは、グローバルサービスのコントロールプレーンがホストされているリージョンとは異なるリージョンで運用を行っている場合でも、アーキテクチャ内の単一障害点を排除し、クロスリージョンの潜在的な影響を回避するのに役立ちます。また、グローバルサービスのコントロールプレーンに依存しないフェイルオーバーメカニズムを安全に実装するのにも役立ちます。

パーティション固有のグローバルサービス

AWS の一部のグローバルサービスは、パーティション固有のサービスです (このホワイトペーパーではパーティションサービスと呼びます)。パーティションサービスは、単一の AWS リージョンでコントロールプレーンを提供します。一部のパーティションサービス (AWS Network Manager など) は、コントロールプレーンのみのサービスであり、他のサービスのデータプレーンをオーケストレーションします。他のパーティションサービス (IAM など) は、パーティション内のすべての AWS リージョンに分離および分散された独自のデータプレーンを持っています。パーティションサービスで障害が発生しても、他のパーティションには影響しません。aws パーティションの場合、IAM サービスのコントロールプレーンは us-east-1 リージョン内にあり、データプレーンはパーティション内の各リージョンに分離されています。パーティションサービスの独立したコントロールプレーンとデータプレーンは、aws-us-gov パーティションと aws-cn パーティションにもあります。IAM のコントロールプレーンとデータプレーンの分離を次の図に示します。

aws パーティション内のパーティションサービスとそのコントロールプレーンの場所は次のとおりです。

これらのサービスのコントロールプレーンのいずれかで可用性に影響するイベントが発生した場合、これらのサービスが提供する CRUDL タイプのオペレーションは使用できなくなる可能性があります。したがって、リカバリ戦略がこれらのオペレーションに依存している場合、コントロールプレーンまたはコントロールプレーンをホストしているリージョンの可用性に影響が出ると、リカバリが成功する可能性が低くなります。リカバリ時にグローバルサービスのコントロールプレーンへの依存関係を削除する戦略については、「付録 A - パーティションサービスに関するガイダンス」を参照してください。

エッジネットワークにおけるグローバルサービス

以下の一連の AWS グローバルサービスは、コントロールプレーンを aws パーティション内で運用し、データプレーンをグローバル Point of Presence (POP) インフラストラクチャ (および、場合によっては AWS リージョン) でホストします。PoP でホストされているデータプレーンには、インターネットからだけでなく、任意のパーティションのリソースからもアクセスできます。例えば、Route 53 はコントロールプレーンを us-east-1 リージョン内で運用していますが、そのデータプレーンは世界中の何百という PoP と各 AWS リージョンに (リージョン内の Route 53 Public DNS と Private DNS をサポートするために) 分散されています。Route 53 のヘルスチェックもデータプレーンの一部であり、aws パーティション内の 8 つの AWS リージョンから実行されます。クライアントは、AWS 仮想プライベートクラウド (VPC) からでも、他のパーティション (GovCloud など) を含むインターネット上のどこからでも、Route 53 パブリックホストゾーンを使用して DNS を解決できます。以下は、aws パーティション内のグローバルエッジネットワークサービスとそのコントロールプレーンの場所です。

EC2 インスタンスまたは Elastic IP アドレスで AGA ヘルスチェックを使用する場合、これらは Route 53 ヘルスチェックを使用します。AGA ヘルスチェックの作成または更新は、us-east-1 の Route 53 のコントロールプレーンに依存します。AGA ヘルスチェックの実行には、Route 53 ヘルスチェックデータプレーンを利用します。

これらのサービスのコントロールプレーンをホストするリージョンに影響する障害が発生するか、コントロールプレーン自体に影響する障害が発生した場合、これらのサービスが提供する CRUDL タイプのオペレーションは使用できない可能性があります。これらのオペレーションに依存するリカバリ戦略は、これらのサービスのデータプレーンにのみ依存する戦略と比べて、成功する可能性が低くなる可能性があります。

グローバルな単一リージョンのオペレーション

最後のカテゴリは、前のカテゴリのようにサービス全体ではなく、サービス内でグローバルな影響スコープを持つ特定のコントロールプレーンオペレーションで構成されます。ゾーンサービスやリージョンサービスとのやり取りは、指定したリージョンで行いますが、特定のオペレーションはリソースの配置先とは異なる単一リージョンに基盤となる依存関係があります。これらは単一リージョンでのみ提供されるサービスとは異なります。後者のサービスのリストについては、「付録 C - 単一リージョンのサービス」を参照してください。

基盤となるグローバル依存関係に影響する障害が発生すると、依存オペレーションの CRUDL タイプのアクションは使用できなくなる場合があります。これらのオペレーションに依存するリカバリ戦略は、これらのサービスのデータプレーンにのみ依存する戦略と比べて、成功する可能性が低くなる場合があります。リカバリ戦略では、これらのオペレーションに依存しないようにする必要があります。

以下は、他のサービスが依存する可能性がある、グローバルなスコープを持つサービスのリストです。

デフォルトのグローバルエンドポイントを使用するサービス

AWS のサービスが、AWS セキュリティトークンサービス (AWS STS) など、デフォルトのグローバルエンドポイントを提供する場合もあります。他のサービスは、このデフォルトのグローバルエンドポイントをデフォルト設定で使用することがあります。つまり、使用しているリージョンサービスが、単一の AWS リージョンにグローバルに依存している場合があるということです。以下では、サービスをリージョンレベルで利用するのに役立つデフォルトのグローバルエンドポイントへの意図しない依存関係を取り除く方法について詳しく説明します。

AWS STS: STS は、IAM ユーザーまたは認証するユーザー (フェデレーションユーザー) の一時的な、権限の制限された認証情報をリクエストできるウェブサービスです。AWS Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) からの STS の使用は、デフォルトの場所が us-east-1 になります。STS サービスはリージョンエンドポイントも提供します。これらのエンドポイントは、デフォルトで有効になっているリージョンにおいて、デフォルトで有効になります。これらのエンドポイントは、SDK または CLI を「AWS STS のリージョン別のエンドポイント」の手順に従って設定することで、いつでも利用できます。SigV4A を使用する場合も、リージョン STS エンドポイントに対して一時的な認証情報をリクエストすることが必要になります。このオペレーションにグローバル STS エンドポイントを使用することはできません。

Security Assertion Markup Language (SAML) サインイン: SAML サービスはすべての AWS リージョン で使用できます。このサービスを使用するには、https://us-west-2.signin.aws.amazon.com/saml などの 適切なリージョンの SAML エンドポイントを選択します。リージョンエンドポイントを使用するには、信頼ポリシーと ID プロバイダー (IdP) の設定を更新する必要があります。具体的な詳細については、AWS SAML のドキュメントを参照してください。

AWS で同じくホストされている IdP を使用している場合は、AWS での障害発生時に、これらも影響を受ける可能性があります。その結果、IdP 設定を更新できなくなったり、フェデレーションが完全にできなくなったりする場合があります。IdP に障害が発生したり、利用できなくなったりした場合に備えて、「ブレークグラス」ユーザーを事前にプロビジョニングする必要があります。静的に安定した方法でブレークグラスユーザーを作成する方法の詳細については、「付録 A - パーティションサービスに関するガイダンス」を参照してください。

AWS IAM Identity Center: Identity Center は、お客様の AWS アカウントおよびクラウドアプリケーションへのシングルサインオンを一元的に管理しやすくするクラウドベースのサービスです。Identity Center は、選択した単一リージョンにデプロイする必要があります。ただし、サービスのデフォルト動作では、us-east-1 でホストされているグローバル SAML エンドポイント (https://signin.aws.amazon.com/saml) を使用します。Identity Center を別の AWS リージョンにデプロイした場合は、Identity Center のデプロイと同じリージョンコンソールエンドポイントを対象とするように設定されたすべてのアクセス許可セットの relaystate URL を更新する必要があります。例えば、Identity Center を us-west-2 にデプロイした場合は、https://us-west-2.console.aws.amazon.com を使用するようにアクセス許可セットの relaystate を更新する必要があります。これにより、Identity Center のデプロイから us-east-1 への依存関係が削除されます。

さらに、IAM Identity Center をデプロイできるのは 1 つのリージョンに限られるため、デプロイに障害が発生した場合に備えて、「ブレークグラス」ユーザーを事前にプロビジョニングしておく必要があります。静的に安定した方法でブレークグラスのユーザーを作成する方法の詳細については、「付録 A - パーティションサービスに関するガイダンス」を参照してください。

Amazon S3 ストレージレンズ: ストレージレンズには、default-account-dashboard というデフォルトのダッシュボードがあります。ダッシュボード設定および関連するメトリクスは、us-east-1 に保存されます。ダッシュボード設定およびメトリクスデータのホームリージョンを指定することで、他のリージョンに追加のダッシュボードを作成できます。

グローバルサービスの概要

グローバルサービスのデータプレーンには、AWS のリージョンサービスと同様の分離と独立性の原則が適用されます。特定のリージョンで IAM のデータプレーンに影響する障害は、別の AWS リージョンでの IAM のデータプレーンオペレーションには影響しません。同様に、特定の PoP で Route 53 のデータプレーンに影響する障害は、他の POP での Route 53 のデータプレーンオペレーションには影響しません。したがって、考慮しなければならないのは、コントロールプレーンが動作しているリージョンまたはコントロールプレーン自体に影響するサービスの可用性イベントです。各グローバルサービスのコントロールプレーンは 1 つのみであるため、そのコントロールプレーンに影響する障害は、リージョンをまたいで CRUDL タイプのオペレーション (サービスを直接使用する場合とは対照的に、サービスのセットアップや設定に通常使用する設定オペレーション) に影響する可能性があります。

グローバルサービスを回復力の高い方法で使用するようにワークロードを設計する最も効果的な方法は、静的安定性を使用することです。障害シナリオでは、コントロールプレーンを変更しなくても影響を軽減したり、別の場所にフェイルオーバーしたりできるようにワークロードを設計します。この種のグローバルサービスを活用してコントロールプレーンへの依存関係を削除し、単一障害点をなくす方法の規範的なガイダンスについては、「付録 A - パーティションサービスに関するガイダンス」と「付録 B - エッジネットワークのグローバルサービスに関するガイダンス」を参照してください。リカバリのためにコントロールプレーンオペレーションからのデータが必要な場合は、このデータを AWS Systems Manager パラメータストア (SSM パラメータストア) のパラメータ、DynamoDB テーブル、S3 バケットなど、データプレーンを介してアクセスできるデータストアにキャッシュします。冗長性を確保するために、データを追加のリージョンに保存することもできます。例えば、Route 53 Application Recovery Controller (ARC) のベストプラクティスに従い、5 つのリージョンクラスターエンドポイントをハードコーディングするか、ブックマークする必要があります。障害イベントが発生すると、信頼性が非常に高いデータプレーンクラスターでホストされていない Route 53 ARC API オペレーションなど、一部の API オペレーションにアクセスできなくなることがあります。DescribeCluster API オペレーションを使用して Route 53 ARC クラスターのエンドポイントを一覧表示できます。

以下は、グローバルサービスのコントロールプレーンへの依存関係を引き起こす、最も一般的な設定ミスまたはアンチパターンのいくつかをまとめたものです。

以下は、以上の一般的なアンチパターンを防ぐために役立つグローバルサービスを回復力の高い方法で使用するために、このセクションで紹介したレコメンデーションのまとめです。