# ゾーンサービス [アベイラビリティーゾーンの独立性](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 を使用するときは、コントロールプレーンの障害や親リージョンへのネットワーク接続の中断に対する回復力を高めるために、静的安定性を実装してください。