グローバルサービス - AWS 障害分離境界

グローバルサービス

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 のコントロールプレーンとデータプレーンの分離を次の図に示します。

この図は、IAM に単一のコントロールプレーンとリージョンごとのデータプレーンがあることを示しています。

IAM には 1 つのコントロールプレーンとリージョンごとのデータプレーンがある

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

  • AWS IAM (us-east-1)

  • AWS Organizations (us-east-1)

  • AWS アカウント管理 (us-east-1)

  • Route 53 Application Recovery Controller (ARC) (us-west-2) - このサービスは aws パーティションにのみ存在する

  • AWS Network Manager (us-west-2)

  • Route 53 Private DNS (us-east-1)

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

レコメンデーション

リカバリパスでは、パーティションサービスのコントロールプレーンに依存しないでください。代わりに、これらのサービスのデータプレーンオペレーションに依存します。パーティションサービスの設計方法の詳細については、「付録 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 パーティション内のグローバルエッジネットワークサービスとそのコントロールプレーンの場所です。

  • Route 53 Public DNS (us-east-1)

  • Amazon CloudFront (us-east-1)

  • AWS WAF Classic for CloudFront (us-east-1)

  • AWS WAF for CloudFront (us-east-1)

  • Amazon Certificate Manager (ACM) for CloudFront (us-east-1)

  • AWS Global Accelerator (AGA) (us-west-2)

  • AWS Shield Advanced (us-east-1)

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

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

レコメンデーション

リカバリパスでは、エッジネットワークサービスのコントロールプレーンに依存しないでください。代わりに、これらのサービスのデータプレーンオペレーションに依存します。エッジネットワークにおけるグローバルサービスの設計方法の詳細については、「付録 B - エッジネットワークのグローバルサービスに関するガイダンス」を参照してください。

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

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

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

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

  • Route 53

    AWS のサービスのいくつかは、リソース固有の DNS 名を提供するリソースを作成します。例えば、Elastic Load Balancing (ELB) をプロビジョニングすると、サービスは ELB 用に Route 53 のパブリック DNS レコードとヘルスチェックを作成します。これは、us-east-1 の Route 53 のコントロールプレーンに依存します。使用する他のサービスでも、コントロールプレーンのワークフローの一部として、ELB のプロビジョニング、パブリック Route 53 DNS レコードの作成、または Route 53 ヘルスチェックの作成が必要になる場合があります。例えば、Amazon API Gateway REST API リソース、Amazon Relational Database Service (Amazon RDS) データベース、Amazon Relational Database Service (Amazon RDS) データベース、または Amazon OpenSearch Service ドメインのプロビジョニングは、いずれも Route 53 での DNS レコードの作成を伴います。以下は、DNS レコードやホストゾーンを作成、更新、削除したり、Route 53 ヘルスチェックを作成したりするために、us-east-1 で Route 53 のコントロールプレーンに依存するコントロールプレーンを持つサービスのリストです。このリストはすべてを網羅しているわけではなく、Route 53 のコントロールプレーンに依存してリソースの作成、更新、または削除のコントロールプレーンアクションを行う、最もよく使用されるサービスのいくつかを紹介しています。

    • Amazon API Gateway REST と HTTP API

    • Amazon RDS インスタンス

    • Amazon Aurora データベース

    • Amazon ELB ロードバランサー

    • AWS PrivateLink VPC エンドポイント

    • AWS Lambda URL

    • Amazon ElastiCache

    • Amazon OpenSearch Service

    • Amazon CloudFront

    • Amazon MemoryDB for Redis

    • Amazon Neptune

    • Amazon DynamoDB Accelerator (DAX)

    • AGA

    • DNS ベースのサービス検出を備えた Amazon Elastic Container Service (Amazon ECS) (AWS Cloud Map API を使用して Route 53 DNS を管理する)

    • Amazon EKS Kubernetes コントロールプレーン

      EC2 インスタンスのホスト名の VPC DNS サービスはそれぞれ独立して AWS リージョンに存在し、Route 53の コントロールプレーンには依存しない点に注意することが重要です。AWS が VPC DNS サービス内で EC2 インスタンス用に作成するレコード (ip-10-0-10.ec2.internalip-10-0-1-5.compute.us-west-2.compute.internali-0123456789abcdef.ec2.internali-0123456789abcdef.us-west-2.compute.internal など) は、us-east-1 の Route 53 のコントロールプレーンには依存しません。

      レコメンデーション

      リカバリパスでは、Route 53 のリソースレコード、ホストゾーン、またはヘルスチェックの作成、更新、または削除を必要とするリソースの作成、更新、または削除に依存しないでください。リカバリパスで Route 53 のコントロールプレーンに依存しないように、これらのリソース (ELB など) は事前にプロビジョニングします。

  • Amazon S3

    以下の Amazon S3 のコントロールプレーンオペレーションには、aws パーティションの us-east-1 への基盤となる依存関係があります。us-east-1 で Amazon S3 やその他のサービスに影響する障害が発生すると、他のリージョンでこれらのコントロールプレーンアクションが機能しなくなる可能性があります。

    PutBucketCors DeleteBucketCors PutAccelerateConfiguration PutBucketRequestPayment PutBucketObjectLockConfiguration PutBucketTagging DeleteBucketTagging PutBucketReplication DeleteBucketReplication PutBucketEncryption DeleteBucketEncryption PutBucketLifecycle DeleteBucketLifecycle PutBucketNotification PutBucketLogging DeleteBucketLogging PutBucketVersioning PutBucketPolicy DeleteBucketPolicy PutBucketOwnershipControls DeleteBucketOwnershipControls PutBucketAcl PutBucketPublicAccessBlock DeleteBucketPublicAccessBlock

    Amazon S3 マルチリージョンアクセスポイント (MRAP) のコントロールプレーンは、us-west-2 でのみホストされているため、MRAP の作成、更新、または削除のリクエストは、このリージョンに直接送信されます。また、MRAP のコントロールプレーンには、us-west-2 の AGA、us-east-1 の Route 53、および各リージョンの ACM への基盤となる依存関係もあり、これらのコンテンツを処理するように MRAP が設定されています。リカバリパスや独自のシステムのデータプレーンでは、MRAP のコントロールプレーンの可用性に依存しないでください。これは、MRAP 内の各バケットをアクティブまたはパッシブのルーティングステータスに指定するために使用される MRAP フェイルオーバーコントロールとは異なります。これらの API は 5 つのAWS リージョンでホストされ、サービスのデータプレーンを使用してトラフィックを効果的にシフトするために使えます。

    さらに、Amazon S3 のバケット名はグローバルに一意であり、名前の一意性を確保するために CreateBucket API と DeleteBucket API へのすべての呼び出しは aws パーティションの us-east-1 に依存します。これは、API の呼び出しが、バケットを作成する特定のリージョンに向けられる場合でも変わりません。最後に、重要なバケットの作成ワークフローがある場合は、バケット名の特定のスペル、特に識別可能なパターンに従うスペルの可用性に依存するべきではありません。

    レコメンデーション

    リカバリパスの一部として、S3 バケットの削除や新規作成、S3 バケット設定の更新に依存しないでください。変更を加えなくても障害から回復できるように、すべての必要な S3 バケットを必要な設定で事前にプロビジョニングします。このアプローチは MRAP にも当てはまります。

  • CloudFront

    Amazon API Gateway は、エッジ最適化 API エンドポイントを提供します。これらのエンドポイントの作成は、ゲートウェイエンドポイントの前にディストリビューションを作成するために、us-east-1 の CloudFront のコントロールプレーンに依存します。

    レコメンデーション

    リカバリパスの一部として、新しいエッジ最適化 API ゲートウェイエンドポイントの作成に依存しないでください。すべての必要な API ゲートウェイエンドポイントは、事前にプロビジョニングします。

    このセクションで説明する依存関係はすべてコントロールプレーンのアクションであり、データプレーンのアクションではありません。静的に安定するようにワークロードを設定した場合、これらの依存関係はリカバリパスに影響を与えないはずです。なお、静的安定性の実装には追加の作業やサービスが必要であることに留意してください。

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

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 エンドポイントを使用することはできません。

レコメンデーション

リージョン STS エンドポイントを使用するように SDK と CLI の設定を更新してください。

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 - パーティションサービスに関するガイダンス」を参照してください。

レコメンデーション

複数のリージョンからの SAML ログインを受け入れるように IAM ロールの信頼ポリシーを更新してください。障害が発生して、優先するエンドポイントが損なわれた場合は、別のリージョンの SAML エンドポイントを使用するように IdP 設定を更新します。IdP に障害が発生した場合や利用できない場合に備えて、ブレークグラスのユーザーを作成します。

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 - パーティションサービスに関するガイダンス」を参照してください。

レコメンデーション

IAM Identity Center のアクセス許可セットの relaystate  URL を、サービスのデプロイ先のリージョンと一致するように設定します。IAM Identity Center のデプロイが利用できない場合に備えて、ブレークグラスのユーザーを作成します。

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

レコメンデーション

us-east-1 でサービスに影響する障害が発生したときに、デフォルトの S3 ストレージレンズダッシュボードからのデータが必要な場合は、代替のホームリージョンに追加のダッシュボードを作成してください。追加のリージョンで作成した他のカスタムダッシュボードを複製することもできます。

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

グローバルサービスのデータプレーンには、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 クラスターのエンドポイントを一覧表示できます。

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

  • フェイルオーバーを実行するために Route 53 レコードを変更する (A レコードの値を更新したり、加重レコードセットの重みを変更するなど)。

  • フェイルオーバー中に IAM ロールやポリシーなどの IAM リソースを作成または更新する。これは通常、意図的なものではありませんが、テストされていないフェイルオーバープランの結果である可能性があります。

  • 障害イベントの発生時にオペレーターが本番環境にアクセスするために IAM Identity Center に依存する。

  • IAM Identity Center を別のリージョンにデプロイしている場合に、us-east-1 でコンソールを使用するために Identity Center のデフォルト設定に依存する。

  • リージョンフェイルオーバーを手動で実行するために AGA トラフィックダイヤルの重みを変更する。

  • 障害が発生したオリジンからフェイルアウェイするように CloudFront ディストリビューションのオリジン設定を更新する。

  • Route 53 の DNS レコードの作成に依存するディザスタリカバリ (DR) リソース (障害発生時の ELB や RDS インスタンスなど) をプロビジョニングする。

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

レコメンデーションのまとめ

リカバリパスでは、パーティションサービスのコントロールプレーンに依存しません。代わりに、これらのサービスのデータプレーンオペレーションに依存します。パーティションサービスの設計方法の詳細については、「付録 A - パーティションサービスに関するガイダンス」を参照してください。

リカバリパスでは、エッジネットワークサービスのコントロールプレーンに依存しません。代わりに、これらのサービスのデータプレーンオペレーションに依存します。エッジネットワークにおけるグローバルサービスの設計方法の詳細については、「付録 B - エッジネットワークのグローバルサービスに関するガイダンス」を参照してください。

リカバリパスでは、Route 53 のリソースレコード、ホストゾーン、またはヘルスチェックの作成、更新、削除を必要とするリソースの作成、更新、または削除に依存しません。リカバリパスでは、Route 53 のコントロールプレーンへの依存関係を防ぐために、これらのリソース (ELB など) を事前にプロビジョニングします。

リカバリパスの一部として、S3 バケットの削除や新規作成、S3 バケット設定の更新に依存しません。変更を加えなくても障害から回復できるように、すべての必要な S3 バケットを必要な設定で事前にプロビジョニングします。このアプローチは MRAP にも当てはまります。

リカバリパスの一部として、新しいエッジ最適化 API ゲートウェイエンドポイントの作成に依存しません。すべての必要な API Gateway エンドポイントを事前にプロビジョニングします。

リージョン STS エンドポイントを使用するように SDK と CLI の設定を更新します。

複数のリージョンからの SAML ログインを受け入れるように IAM ロールの信頼ポリシーを更新します。障害が発生して、優先するエンドポイントが損なわれた場合は、別のリージョンの SAML エンドポイントを使用するように IdP 設定を更新します。IdP に障害が発生した場合や利用できない場合に備えて、break-glass ユーザーを作成します。

IAM Identity Center のアクセス許可セットの relaystate  URL を、サービスのデプロイ先のリージョンと一致するように設定します。IAM Identity Center のデプロイが利用できない場合に備えて、ブレークグラスのユーザーを作成します。

us-east-1 でサービスに影響する障害が発生したときに、デフォルトの S3 ストレージレンズダッシュボードからのデータが必要な場合は、代替のホームリージョンに追加のダッシュボードを作成します。追加のリージョンで作成した他のカスタムダッシュボードを複製することもできます。