# AWS のサービスカテゴリ
AWS は、障害分離境界に応じて、ゾーン、リージョン、グローバルという 3 つの異なるカテゴリのサービスを運用しています。このセクションでは、これらの異なるカテゴリのサービスがどのように設計されているかを詳しく説明し、特定のサービスカテゴリに属するサービスで障害が発生した場合に、AWS で実行しているワークロードにどのような影響があるかを判断できるようにします。また、ワークロードをどのように構築すれば、これらのサービスを回復力の高い方法で利用できるかについてもガイダンスの概要を示します。グローバルサービスについては、AWS のサービスのコントロールプレーンで発生した障害の影響がワークロードに及ばないようにするための規範的なガイダンスを、このドキュメントの「[付録 A - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」と「[付録 B - エッジネットワークのグローバルサービスに関するガイダンス](appendix-b---edge-network-global-service-guidance.md)」に記載しています。これは、単一障害点の発生を最小限に抑えながら、グローバルサービスに安全に依存するために役立ちます。
**Topics**
+ [ゾーンサービス](zonal-services.md)
+ [リージョンサービス](regional-services.md)
+ [グローバルサービス](global-services.md)
# ゾーンサービス
[アベイラビリティーゾーンの独立性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI) があることで、AWS は Amazon EC2 や Amazon EBS などのゾーンサービスを提供できます。ゾーンサービスとは、リソースをデプロイする先のアベイラビリティーゾーンを指定できるサービスです。これらのサービスは、リージョン内のアベイラビリティーゾーンごとに独立して動作し、さらに重要な点として、アベイラビリティーゾーンごとに独立して故障します。つまり、あるアベイラビリティーゾーンのサービスのコンポーネントは、他のアベイラビリティーゾーンのコンポーネントに依存しません。これができるのは、ゾーンサービスに**ゾーンデータプレーン**があるためです。一部のサービス (EC2 など) には、ゾーン指定のオペレーション (EC2 インスタンスの起動など) 用にゾーンコントロールプレーンが含まれている場合があります。これらのサービスの場合、AWS は、サービスとのやり取りを容易にするためにリージョンコントロールプレーンのエンドポイントも提供します。リージョンコントロールプレーンは、リージョンにスコープされた機能を提供するとともに、ゾーンコントロールプレーン上の集約レイヤーおよびルーティングレイヤーとしても機能します。このアーキテクチャを次の図に示します。
![\[この図は、ゾーンサービスのコントロールプレーンとデータプレーンはゾーンごとに分離されることを示しています。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png)
複数のアベイラビリティーゾーンを使用すると、お客様は単一のデータセンターを使用した場合よりも、可用性、耐障害性、スケーラビリティが高い本番ワークロードを運用できます。ワークロードで複数のアベイラビリティーゾーンを使用する場合、1 つのアベイラビリティーゾーンの物理インフラストラクチャに影響する問題が発生した場合に、お客様はより適切に隔離して保護できます。これにより、お客様は、複数のアベイラビリティーゾーンにわたって冗長性のあるサービスを構築でき、正しく設計した場合は、1 つのアベイラビリティーゾーンで障害が発生しても運用を続行できます。お客様は AZI を活用して、可用性と耐障害性の高いワークロードを作成できます。アーキテクチャに AZI を実装すると、あるアベイラビリティーゾーンのリソースが他のアベイラビリティーゾーンのリソースとやり取りするのを最小限に抑えるか、完全になくすことができるため、分離されたアベイラビリティーゾーンの障害から迅速に回復できます。これにより、アベイラビリティーゾーン間の依存関係がなくなり、アベイラビリティーゾーンからの退避が簡単になります。アベイラビリティーゾーンからの退避メカニズムの構築の詳細については、「[高度なマルチ AZ レジリエンスパターン](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)」を参照してください。また、アベイラビリティーゾーンをさらに活用して、一度に 1 つのアベイラビリティーゾーンにのみ変更をデプロイしたり、アベイラビリティーゾーンに変更が適切に反映できなかった場合にサービスからアベイラビリティーゾーンを削除したりするなど、AWS が独自のサービスで使用しているのと同じベストプラクティスの一部に従うことができます。
[静的安定性](static-stability.md)も、マルチアベイラビリティーゾーンアーキテクチャにとって重要な概念です。マルチアベイラビリティーゾーンアーキテクチャで計画すべき障害モードの 1 つは、アベイラビリティーゾーンの損失です。この損失に伴って、アベイラビリティーゾーン全体に相当する容量が失われる可能性があります。アベイラビリティーゾーンの損失を処理するのに十分な容量を事前にプロビジョニングしていないと、残存容量が現在の負荷に対応できなくなる場合があります。さらに、失われた容量を補うには、使用しているゾーンサービスのコントロールプレーンに依存する必要があり、静的に安定した設計よりも信頼性が低くなる場合があります。この場合、十分な追加容量を事前にプロビジョニングしておくと、動的な変更を必要とせずに通常の運用を継続できるため、1 つのアベイラビリティーゾーンなどの障害ドメインが失われても静的安定性を維持できます。
複数のアベイラビリティーゾーンにデプロイした EC2 インスタンスの Auto Scaling グループを使用して、ワークロードのニーズに応じて動的にスケールイン/スケールアウトできます。自動スケーリングは、数分から数十分にわたって使用量が徐々に変化する場合に適しています。ただし、新しい EC2 インスタンスの起動には時間がかかります。特に、インスタンスがブートストラップを必要とする場合 (エージェント、アプリケーションバイナリ、設定ファイルをインストールするなど) はそうです。この間、残存容量が現在の負荷に対応できなくなる場合があります。さらに、自動スケーリングによる新しいインスタンスのデプロイは EC2 のコントロールプレーンに依存します。これにはトレードオフがあります。1 つのアベイラビリティーゾーンが失われても静的に安定するには、新しいインスタンスのプロビジョニングを自動スケーリングに頼るのではなく、他のアベイラビリティーゾーンに十分な EC2 インスタンスを事前にプロビジョニングして、障害が発生したアベイラビリティーゾーンから負荷を移動して処理する必要があります。追加容量を事前にプロビジョニングすると、追加コストが発生する可能性があります。
例えば、通常の運用は、顧客トラフィックを処理するために 3 つのアベイラビリティーゾーンにわたって 6 つのインスタンスがワークロードに必要であるとします。1 つのアベイラビリティーゾーンの障害に対して静的に安定するには、アベイラビリティーゾーンごとに 3 つずつ、合計 9 つのインスタンスをデプロイします。1 つのアベイラビリティーゾーンのインスタンスに障害が発生しても、残りのインスタンスが 6 つあるため、障害発生時に新しいインスタンスをプロビジョニングして設定しなくても、引き続き顧客トラフィックを処理できます。EC2 容量の静的安定性を実現するために、この例の場合は実行するインスタンス数が 50% 増えるため、追加コストがかかります。S3 バケットやユーザーの事前プロビジョニングなど、リソースの事前プロビジョニングが可能なすべてのサービスに追加コストが発生するわけではありません。ワークロードの望ましい復旧時間を超えてしまう危険性に対して静的安定性を実装することのトレードオフを検討する必要があります。
AWS Local Zones および Outposts は、限定された AWS のサービスのデータプレーンをエンドユーザーに近づけます。これらのサービスのコントロールプレーンは親リージョンにあります。Local Zones や Outposts のインスタンスには、Local Zones や Outposts サブネットを作成したアベイラビリティーゾーンの EC2 や EBS などのゾーンサービスのコントロールプレーンへの依存関係があります。また、Elastic Load Balancing (ELB)、セキュリティグループ、Amazon Elastic Kubernetes Service ([Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html)) マネージドの Kubernetes コントロールプレーン (EKS を使用している場合) など、リージョンサービスのリージョンコントロールプレーンへの依存関係もあります。Outposts 固有の追加情報については、[関連ドキュメント](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html)と[サポートおよびメンテナンスに関するよくある質問](https://aws.amazon.com/outposts/rack/faqs/)を参照してください。Local Zones や Outposts を使用するときは、コントロールプレーンの障害や親リージョンへのネットワーク接続の中断に対する回復力を高めるために、静的安定性を実装してください。
# リージョンサービス
リージョンサービスは、AWS が複数のアベイラビリティーゾーンの上に構築したサービスであるため、お客様はゾーンサービスを最大限に活用する方法を考え出す必要はありません。複数のアベイラビリティーゾーンにデプロイしたサービスを論理的にグループ化し、単一のリージョンエンドポイントをお客様に提供します。Amazon SQS や [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) は、リージョンサービスの例です。リージョンサービスは、アベイラビリティーゾーンの独立性と冗長性を利用し、可用性と耐久性のリスクの 1 種としてのインフラストラクチャの障害を最小限に抑えます。例えば、Amazon S3 はリクエストとデータを複数のアベイラビリティーゾーンに分散し、1 つのアベイラビリティーゾーンの障害から自動的に回復するように設計されています。ただし、お客様はこのサービスのリージョンエンドポイントとのみやり取りします。
ほとんどのお客様は、リージョンサービス (またはゾーンサービスに依存するマルチ AZ アーキテクチャ) を使用することで、1 つのリージョンで回復力の目標を達成できると AWS は考えています。ただし、ワークロードによっては追加の冗長性を必要とする場合があるため、AWS リージョンの分離を使用して HA やビジネス継続性を目的としたマルチリージョンアーキテクチャを作成できます。AWS リージョン間を物理的および論理的に分離することで、リージョン間の相関する障害を回避できます。言い換えると、EC2 を複数のアベイラビリティーゾーンにデプロイすることでアベイラビリティーゾーンの分離の利点が得られるように、リージョンサービスを複数のリージョンにデプロイすることで同じ利点が得られます。そのためには、アプリケーションにマルチリージョンアーキテクチャを実装する必要があります。これにより、リージョナルサービスの障害に対する回復力を高めることができます。
ただし、マルチリージョンアーキテクチャの利点を実現するのは難しい場合があります。アプリケーションレベルで何も取り消すことなく、リージョンの分離を活用するには、慎重な作業が必要です。例えば、リージョン間でアプリケーションをフェイルオーバーする場合は、各リージョンでアプリケーションスタック間の分離を厳密に維持し、すべてのアプリケーションの依存関係に注意しながら、アプリケーションのすべての部分を一緒にフェイルオーバーする必要があります。これをアプリケーション間の依存関係が多い複雑なマイクロサービスベースのアーキテクチャで実現するには、多くのエンジニアリングチームおよびビジネスチーム間での計画と調整が必要です。個々のワークロードが独自のフェイルオーバー決定を行えるようにすると、調整の複雑さは軽減されますが、単一リージョンの場合と比べて、複数のリージョン間で発生するレイテンシーが大きく異なるため、モーダル動作が発生します。
現時点では、AWS はクロスリージョンの同期レプリケーション機能を提供していません。リージョン間で (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 に単一のコントロールプレーンとリージョンごとのデータプレーンがあることを示しています。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png)
`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 - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」を参照してください。
****レコメンデーション****
リカバリパスでは、パーティションサービスのコントロールプレーンに依存しないでください。代わりに、これらのサービスのデータプレーンオペレーションに依存します。パーティションサービスの設計方法の詳細については、「[付録 A - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」を参照してください。
## エッジネットワークにおけるグローバルサービス
以下の一連の AWS グローバルサービスは、コントロールプレーンを `aws` パーティション内で運用し、データプレーンをグローバル [Point of Presence](points-of-presence.md) (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 - エッジネットワークのグローバルサービスに関するガイダンス](appendix-b---edge-network-global-service-guidance.md)」を参照してください。
## グローバルな単一リージョンのオペレーション
最後のカテゴリは、前のカテゴリのようにサービス全体ではなく、サービス内でグローバルな影響スコープを持つ特定のコントロールプレーンオペレーションで構成されます。ゾーンサービスやリージョンサービスとのやり取りは、指定したリージョンで行いますが、特定のオペレーションはリソースの配置先とは異なる単一リージョンに基盤となる依存関係があります。これらは単一リージョンでのみ提供されるサービスとは異なります。後者のサービスのリストについては、「[付録 C - 単一リージョンのサービス](appendix-c---single-region-services.md)」を参照してください。
基盤となるグローバル依存関係に影響する障害が発生すると、依存オペレーションの 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
+ 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 インスタンスのホスト名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html)の VPC DNS サービスはそれぞれ独立して AWS リージョンに存在し、Route 53の コントロールプレーンには依存しない点に注意することが重要です。AWS が VPC DNS サービス内で EC2 インスタンス用に作成するレコード (`ip-10-0-10.ec2.internal`、`ip-10-0-1-5.compute.us-west-2.compute.internal`、`i-0123456789abcdef.ec2.internal`、`i-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` でのみホストされている](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html)ため、MRAP の作成、更新、または削除のリクエストは、このリージョンに直接送信されます。また、MRAP のコントロールプレーンには、`us-west-2` の AGA、`us-east-1` の Route 53、および各リージョンの ACM への基盤となる依存関係もあり、これらのコンテンツを処理するように MRAP が設定されています。リカバリパスや独自のシステムのデータプレーンでは、MRAP のコントロールプレーンの可用性に依存しないでください。これは、MRAP 内の各バケットをアクティブまたはパッシブのルーティングステータスに指定するために使用される [MRAP フェイルオーバーコントロール](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html)とは異なります。これらの API は [5 つのAWS リージョン](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration)でホストされ、サービスのデータプレーンを使用してトラフィックを効果的にシフトするために使えます。
さらに、Amazon S3 の[バケット名はグローバルに一意](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)であり、名前の一意性を確保するために `CreateBucket` API と `DeleteBucket` API へのすべての呼び出しは `aws` パーティションの `us-east-1` に依存します。これは、API の呼び出しが、バケットを作成する特定のリージョンに向けられる場合でも変わりません。最後に、重要なバケットの作成ワークフローがある場合は、バケット名の特定のスペル、特に識別可能なパターンに従うスペルの可用性に依存するべきではありません。
****レコメンデーション****
リカバリパスの一部として、S3 バケットの削除や新規作成、S3 バケット設定の更新に依存しないでください。変更を加えなくても障害から回復できるように、すべての必要な S3 バケットを必要な設定で事前にプロビジョニングします。このアプローチは MRAP にも当てはまります。
+ **CloudFront**
Amazon API Gateway は、[エッジ最適化 API エンドポイント](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized)を提供します。これらのエンドポイントの作成は、ゲートウェイエンドポイントの前にディストリビューションを作成するために、`us-east-1` の CloudFront のコントロールプレーンに依存します。
****レコメンデーション****
リカバリパスの一部として、新しいエッジ最適化 API ゲートウェイエンドポイントの作成に依存しないでください。すべての必要な API ゲートウェイエンドポイントは、事前にプロビジョニングします。
このセクションで説明する依存関係はすべてコントロールプレーンのアクションであり、データプレーンのアクションではありません。静的に安定するようにワークロードを設定した場合、これらの依存関係はリカバリパスに影響を与えないはずです。なお、静的安定性の実装には追加の作業やサービスが必要であることに留意してください。
## デフォルトのグローバルエンドポイントを使用するサービス
AWS のサービスが、AWS セキュリティトークンサービス ([AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html)) など、デフォルトのグローバルエンドポイントを提供する場合もあります。他のサービスは、このデフォルトのグローバルエンドポイントをデフォルト設定で使用することがあります。つまり、使用しているリージョンサービスが、単一の AWS リージョンにグローバルに依存している場合があるということです。以下では、サービスをリージョンレベルで利用するのに役立つデフォルトのグローバルエンドポイントへの意図しない依存関係を取り除く方法について詳しく説明します。
**AWS STS**: STS は、IAM ユーザーまたは認証するユーザー (フェデレーションユーザー) の一時的な、権限の制限された認証情報をリクエストできるウェブサービスです。AWS Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) からの STS の使用は、デフォルトの場所が `us-east-1` になります。STS サービスはリージョンエンドポイントも提供します。これらのエンドポイントは、デフォルトで有効になっているリージョンにおいて、デフォルトで有効になります。これらのエンドポイントは、SDK または CLI を「[AWS STS のリージョン別のエンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)」の手順に従って設定することで、いつでも利用できます。SigV4A を使用する場合も、[リージョン STS エンドポイントに対して一時的な認証情報をリクエストすることが必要](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions)になります。このオペレーションにグローバル STS エンドポイントを使用することはできません。
****レコメンデーション****
リージョン STS エンドポイントを使用するように SDK と CLI の設定を更新してください。
**Security Assertion Markup Language (SAML) サインイン:** SAML サービスはすべての AWS リージョン で使用できます。このサービスを使用するには、[https://us-west-2.signin.aws.amazon.com/saml](https://us-west-2.signin.aws.amazon.com/saml) などの 適切なリージョンの SAML エンドポイントを選択します。リージョンエンドポイントを使用するには、信頼ポリシーと ID プロバイダー (IdP) の設定を更新する必要があります。具体的な詳細については、[AWS SAML のドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html)を参照してください。
AWS で同じくホストされている IdP を使用している場合は、AWS での障害発生時に、これらも影響を受ける可能性があります。その結果、IdP 設定を更新できなくなったり、フェデレーションが完全にできなくなったりする場合があります。IdP に障害が発生したり、利用できなくなったりした場合に備えて、「ブレークグラス」ユーザーを事前にプロビジョニングする必要があります。静的に安定した方法でブレークグラスユーザーを作成する方法の詳細については、「[付録 A - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」を参照してください。
****レコメンデーション****
複数のリージョンからの SAML ログインを受け入れるように IAM ロールの信頼ポリシーを更新してください。障害が発生して、優先するエンドポイントが損なわれた場合は、別のリージョンの SAML エンドポイントを使用するように IdP 設定を更新します。IdP に障害が発生した場合や利用できない場合に備えて、ブレークグラスのユーザーを作成します。
**AWS IAM Identity Center**: Identity Center は、お客様の AWS アカウントおよびクラウドアプリケーションへのシングルサインオンを一元的に管理しやすくするクラウドベースのサービスです。Identity Center は、選択した単一リージョンにデプロイする必要があります。ただし、サービスのデフォルト動作では、`us-east-1` でホストされているグローバル SAML エンドポイント ([https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)) を使用します。Identity Center を別の AWS リージョンにデプロイした場合は、Identity Center のデプロイと同じリージョンコンソールエンドポイントを対象とするように設定されたすべてのアクセス許可セットの [relaystate](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html) URL を更新する必要があります。例えば、Identity Center を `us-west-2` にデプロイした場合は、[https://us-west-2.console.aws.amazon.com](https://us-west-2.console.aws.amazon.com) を使用するようにアクセス許可セットの relaystate を更新する必要があります。これにより、Identity Center のデプロイから `us-east-1` への依存関係が削除されます。
さらに、IAM Identity Center をデプロイできるのは 1 つのリージョンに限られるため、デプロイに障害が発生した場合に備えて、「ブレークグラス」ユーザーを事前にプロビジョニングしておく必要があります。静的に安定した方法でブレークグラスのユーザーを作成する方法の詳細については、「[付録 A - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」を参照してください。
****レコメンデーション****
IAM Identity Center のアクセス許可セットの relaystate URL を、サービスのデプロイ先のリージョンと一致するように設定します。IAM Identity Center のデプロイが利用できない場合に備えて、ブレークグラスのユーザーを作成します。
**Amazon S3 ストレージレンズ:** ストレージレンズには、default-account-dashboard というデフォルトのダッシュボードがあります。ダッシュボード設定および関連するメトリクスは、`us-east-1` に保存されます。ダッシュボード設定およびメトリクスデータの[ホームリージョン](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region)を指定することで、他のリージョンに追加のダッシュボードを作成できます。
****レコメンデーション****
`us-east-1` でサービスに影響する障害が発生したときに、デフォルトの S3 ストレージレンズダッシュボードからのデータが必要な場合は、代替のホームリージョンに追加のダッシュボードを作成してください。追加のリージョンで作成した他のカスタムダッシュボードを複製することもできます。
## グローバルサービスの概要
グローバルサービスのデータプレーンには、AWS のリージョンサービスと同様の分離と独立性の原則が適用されます。特定のリージョンで IAM のデータプレーンに影響する障害は、別の AWS リージョンでの IAM のデータプレーンオペレーションには影響しません。同様に、特定の PoP で Route 53 のデータプレーンに影響する障害は、他の POP での Route 53 のデータプレーンオペレーションには影響しません。したがって、考慮しなければならないのは、コントロールプレーンが動作しているリージョンまたはコントロールプレーン自体に影響するサービスの可用性イベントです。各グローバルサービスのコントロールプレーンは 1 つのみであるため、そのコントロールプレーンに影響する障害は、リージョンをまたいで CRUDL タイプのオペレーション (サービスを直接使用する場合とは対照的に、サービスのセットアップや設定に通常使用する設定オペレーション) に影響する可能性があります。
グローバルサービスを回復力の高い方法で使用するようにワークロードを設計する最も効果的な方法は、静的安定性を使用することです。障害シナリオでは、コントロールプレーンを変更しなくても影響を軽減したり、別の場所にフェイルオーバーしたりできるようにワークロードを設計します。この種のグローバルサービスを活用してコントロールプレーンへの依存関係を削除し、単一障害点をなくす方法の規範的なガイダンスについては、「[付録 A - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」と「[付録 B - エッジネットワークのグローバルサービスに関するガイダンス](appendix-b---edge-network-global-service-guidance.md)」を参照してください。リカバリのためにコントロールプレーンオペレーションからのデータが必要な場合は、このデータを [AWS Systems Manager](https://aws.amazon.com/systems-manager/) パラメータストア (SSM パラメータストア) のパラメータ、DynamoDB テーブル、S3 バケットなど、データプレーンを介してアクセスできるデータストアにキャッシュします。冗長性を確保するために、データを追加のリージョンに保存することもできます。例えば、Route 53 Application Recovery Controller (ARC) の[ベストプラクティス](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html)に従い、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 - パーティションサービスに関するガイダンス](appendix-a---partitional-service-guidance.md)」を参照してください。
リカバリパスでは、エッジネットワークサービスのコントロールプレーンに依存しません。代わりに、これらのサービスのデータプレーンオペレーションに依存します。エッジネットワークにおけるグローバルサービスの設計方法の詳細については、「[付録 B - エッジネットワークのグローバルサービスに関するガイダンス](appendix-b---edge-network-global-service-guidance.md)」を参照してください。
リカバリパスでは、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 ストレージレンズダッシュボードからのデータが必要な場合は、代替のホームリージョンに追加のダッシュボードを作成します。追加のリージョンで作成した他のカスタムダッシュボードを複製することもできます。