AWSでも障害は起きるのか？押さえておきたい有効な情報源

ITサービスの提供とシステム障害は切っても切り離せない関係だと考えられます。

この記事には、Amazon Web Services（AWS）での障害発生時に有効な考え方と情報源を記載します。

AWSでも障害は起きるのか？

クラウドサービスプロバイダーとして世界一のシェアを誇るAWSにおいても、障害発生の記録が残っています。

その中でも、AWSの障害情報を有効活用するための考え方を説明する上で適当だと判断した3つの障害事例を紹介します。

2021年2月20日に発生した東京リージョン（ap-northeast-1）内のアベイラビリティゾーン（apne1-az1）で発生したEC2、EBSに影響する障害

2021年2月20日午前0時から5時間半にかけて、東京リージョン（ap-northeast-1）内のアベイラビリティゾーン（apne1-az1）上のEC2、EBSの可用性に影響する障害が発生しました。

この障害は、冷却システムへの電力の喪失によってアベイラビリティゾーン内の一部区画の温度が上昇し、EC2インスタンスのシャットダウンやEBSボリュームのパフォーマンス低下が起きたとされています。

この障害によって、金融系のサービスや気象庁のホームページの閲覧に影響が出たと報じられています。

2021年9月2日に東京リージョン（ap-northeast-1）で発生したAWS Direct Connectに関する障害

2021年9月2日午前7時30分（日本時間）頃から6時間にかけて、AWS Direct Connectサービスが中断される事象が発生しました。

この障害は、Direct Connectで使用するネットワークデバイスのオペレーティングシステム内の潜在的問題と、8カ月前にネットワークの可用性を高めるために導入した新しいプロトコルが原因となって発生したとされています。

この障害によって、大手銀行のスマートフォンアプリや金融系のサービス、航空会社の一部システムに影響が出たと報じられています。

2024年8月29日に発生したAWS Identity and Access Managementに関する障害

2024年8月29日17時30分（日本時間）頃から1時間半にかけて、AWS Identity and Access Management（IAM）の一機能であるAWS Security Token Service（AWS STS）へのリクエストに影響する問題が発生しました。

根本原因はネットワークの問題であり、東京リージョン（ap-northeast-1）を含む国外7リージョンからバージニア北部（us-east-1）リージョンに存在するAWSサービスエンドポイントに接続する際に、一般的な接続の問題を経験した可能性があるとAWSから報告されています。

この障害の発生によって、一部機能が利用できなくなった旨を発表する国内のウェブサービスも見られました。

AWS障害時の影響

AWSには、AWS Fault Isolation Boundaries（AWS障害分離境界）と呼ばれるAWS障害時の影響を最小限に抑えるための考え方があります。

AWSでは、障害分離境界に基づいて、ゾーナル、リージョナル、グローバルという3つのカテゴリのサービスを運用しています。

AWSの障害情報を確認する際に、障害分離境界に基づいたカテゴリ別のサービスの構造を鑑みることで、AWS障害時の影響をスムーズに把握することができると考えます。

ゾーナルサービスへの影響

ゾーナルサービス（Zonal services）は、AWSの各リージョン内のアベイラビリティゾーンで独立して動作するサービスです。

Amazon RDS、Amazon EC2、Amazon EBSなどがゾーナルサービスに該当します。

アベイラビリティゾーンとは、AWSのリージョン内で独立した電源、ネットワークを備えた1つ以上のデータセンターを指します。各アベイラビリティゾーン間は、相関障害を防ぎつつ、同期レプリケーションのレイテンシーが1桁ミリ秒になるような絶妙な距離（約100km）が空けられています。

アベイラビリティゾーン内のサービスは、リソースの作成、読み取り/説明、更新、削除、および一覧表示 (CRUDL) に使用される管理APIを提供するコントロールプレーンとEC2インスタンス自体やEBSボリュームの読み取りと書き込みといったサービスの主な機能を提供するデータプレーンという2つの概念に分けられています。データプレーンは意図的にシンプルになっているため、統計的にコントロールプレーンよりも障害イベントが発生する可能性が低くなるという特徴があります。

データプレーンのリソースがコントロールプレーンによってプロビジョニングされると、コントロールプレーンに依存しなくなるため、コントロールプレーンに障害が発生しても影響を受けなくなります。つまり、コントロールプレーンによるリソースの作成、変更、削除の機能が損なわれても、データプレーン上のリソースは引き続き正常な機能を維持できます。

まとめると、アベイラビリティゾーン内のコントロールプレーンに障害が発生した場合は、Amazon RDS、Amazon EC2、Amazon EBSなどのゾーナルサービスのリソースの作成、変更、削除の機能が損なわれ、データプレーンに障害が発生した場合は、それらのサービスのリソースの利用に影響が出ます。

なお、2021年2月20日に発生した冷却システムへの電力の喪失によるAWS障害は、ゾーナルサービスに影響するものだったと言え、この障害への対策としては、複数のアベイラビリティゾーンに十分なリソース配置をしておくことだと考えられます。

リージョナルサービスへの影響

リージョナルサービス（Regional services）は、AWSが複数のアベイラビリティゾーン上に構築したサービスです。

Amazon S3、Amazon SQS、Amazon DynamoDBなどがリージョナルサービスに該当します。

ゾーナルサービスにおいては、利用者が各アベイラビリティゾーンへのリソースの配置を設計する必要がありましたが、リージョナルサービスにおいてはその必要はありません。

AWSの各リージョンは、他のリージョンから分離され独立しており、リージョン内で障害が発生した場合でも、影響範囲が単一のリージョンに限定されます。

AWSでは、リージョナルサービスまたはゾーナルサービスに依存するマルチAZ（アベイラビリティゾーン）アーキテクチャを使用することで、単一のリージョンで耐障害性の目標を達成できるとされています。

つまり、リージョナルサービスおよび十分な各アベイラビリティゾーンへのリソース配置を行った上でのゾーナルサービスの利用においては、AWS障害の影響を最小限に抑え、動作を継続できると言えます。

ただし、一部のワークロードでは追加の冗長性が必要な場合があり、ビジネス継続性の目的でマルチリージョンアーキテクチャ（複数のリージョンへのシステム配置）を作成することをAWSは説明しています。

また、リージョン間のデータレプリケーションにおいて、AWSは同期的な機能を提供していないため、リージョン間でアプリケーションをフェイルオーバーする場合、データの不整合に対する対策を利用者側で行う必要があることも述べられています。

AWS障害時のリージョナルサービスへの影響は、各アベイラビリティゾーンへのリソース配置を行った上でのゾーナルサービスへの影響と等しく、リージョン内でのリソース配置やコントロールを利用者がしていない分、障害の影響範囲をゾーナルサービスに比べて把握しづらい面があると言うことができます。反対に、利用者側でアベイラビリティゾーンへのリソース配置などの考慮を行う必要がない分、リージョナルサービスはゾーナルサービスに比べて、耐障害性に関する設計コストが少なくなるとも言えます。

なお、2021年9月2日に発生した障害は、東京リージョン（ap-northeast-1）で起きたと報告されており、Direct Connectがリージョナルサービスであるかのようですが、障害分離境界に基づいたカテゴリに当てはめると、グローバルサービスであると考えた方が良さそうです。

なぜなら、Direct Connectの設定を行う管理コンソールのURLがus-east-1（バージニア北部のリージョンコード）から始まるためです。また、Direct Connectの接続点の一方がリージョンではなく、Direct Connectロケーションと呼ばれるデータセンターに存在するためです。

とはいえ、障害分離境界を意識してAWS障害情報を見ることで、障害の影響範囲を把握しやすくなることには変わりないと考えます。

グローバルサービスへの影響

グローバルサービス（Global services）は、コントロールプレーンとデータプレーンが各リージョンに独立して存在しないサービスです。

IAM、Amazon CloudFront、Amazon Route 53、AWS Global Acceleratorなどがグローバルサービスに該当します。

グローバルサービスには、コントロールプレーンが特定のリージョンに存在し、データプレーンが各リージョンに存在するサービス、コントロールプレーンが特定のリージョンに存在し、データプレーンはグローバルPoPインフラストラクチャ（global points of presence infrastructurePoints of presence）と呼ばれるグローバルに分散されたエッジロケーションに存在するサービスがあります。

データプレーンが各リージョンに存在するサービスとしては、IAMやRoute 53 Private DNSなどがあり、データプレーンがグローバルPoPインフラストラクチャに存在するサービスとしては、Amazon CloudFrontやRoute 53 Public DNSなどがあります。

IAMのコントロールプレーンはバージニア北部（us-east-1）リージョンに存在し、コントロールプレーンから各リージョンに存在するデータプレーンに設定を伝達しています。各リージョンのデータプレーンで認証と認可を行っています。

Route 53 Private DNSのコントロールプレーンは機能によって、バージニア北部（us-east-1）リージョンまたはオレゴン（us-west-2）リージョンに存在し、各リージョンに存在するデータプレーンで多くのAWSサービスと同様にサービスの中核的な機能を提供しています。

Amazon CloudFrontのコントロールプレーンはバージニア北部（us-east-1）リージョンに存在し、グローバルPoPインフラストラクチャ上に存在するデータプレーンでは、オリジンコンテンツのリクエスト処理、ルーティング、キャッシュを実行しています。

Route 53 Public DNSのコントロールプレーンもRoute 53 Public DNSと同様に機能によって、バージニア北部（us-east-1）リージョンまたはオレゴン（us-west-2）リージョンに存在し、データプレーンはグローバルPoPインフラストラクチャに分散されています。

グローバルサービスのコントロールプレーンが存在するリージョンに障害が発生した際は、リソースの作成、変更、削除の機能が損なわれ、データプレーンが存在するリージョンに障害が発生した際は、それらのサービスのリソースの利用に影響が出ることは、ゾーナルサービスおよびリージョナルサービスと同様です。グローバルサービスのデータプレーンは、各リージョンやグローバルPoPインフラストラクチャに分散されているため、障害の影響範囲はゾーナルサービスおよびリージョナルサービスに比べて把握しづらい反面、可用性は高いと考えることができます。

なお、2024年8月29日に発生したAWS Identity and Access Management（IAM）に関する障害は、グローバルサービスの障害事例として紹介しました。

AWS障害の情報源

ここまで、AWSの障害情報を有効活用するための考え方を説明しました。

ここからは、その考え方を用いる前にインプットする情報源について記載します。

AWS Health Dashboard

AWS Health Dashboardでは、すべてのAWSサービスの現在および過去のステータスを表示するパブリックイベントや、AWSリソースに影響するイベントの情報を表示するアカウント固有のイベントを確認できます。

パブリックイベントは、AWS Health DashboardのService health（サービスの状態）のメニューから確認できます。

例えば、2024年8月29日に発生したグローバルサービスであるAWS Identity and Access Management（IAM）の障害に関しては、Service health（サービスの状態）内のOpen and recent issues（未解決の問題と最近の問題）の画面から問題発生の報告や解決に向けての進捗（しんちょく）、影響範囲などを確認することができました。

また、解決済みの過去の障害情報は、Service history（ステータス履歴）の画面から確認できます。

なお、AWS STSではAWSリソースへの一時的なセキュリティ認証情報が提供されますが、デフォルトのコントロールプレーンがバージニア北部（us-east-1）リージョンであるために、リクエスト元は一時的なセキュリティ認証情報を取得できず、システムの動作に影響を及ぼすことになりました。なお、デフォルト設定ではく、リージョナルAWS STSエンドポイントを使用するように設定を変更しておくことで、この問題の影響を回避することもできました。

同様の障害情報はアカウント固有のイベントとしても表示されるようですが、AWSの公式ドキュメントには、パブリックイベントはアカウントに固有ではないサービスイベントと表記されているため、普段から利用していないリージョンにコントロールプレーンが存在するグローバルサービスの障害情報を把握するためにパブリックイベントは有用であると考えることができます。

アカウント固有のイベントは、AWS Health DashboardのYour account health（アカウントの状態）のメニューから確認できます。

AWSの公式ドキュメントには、「使用しているリージョンの Amazon Elastic Compute Cloud（Amazon EC2）インスタンスタイプに問題がある場合、AWS Healthはイベントに関する情報と影響を受けるリソースの名前を提供する」と、アカウント固有のイベントの説明として記載されています。

アカウント固有のイベントをゾーナルサービスやリージョナルサービスの障害情報を把握するために使用できそうですが、公式ドキュメントのサンプルイメージとして「Account specific（アカウント固有）」が「No」となっている画像を掲載しているところを見るに、必ずしもアカウント固有の障害情報のみが表示されるわけではなさそうです。

Your account health（アカウントの状態）内のScheduled changes（スケジュールされた変更）という画面には、AWSサービスのメンテナンス予定やアクションが必要な計画されたライフサイクルイベントが表示されます。ライフサイクルイベントとは、例えばMySQLなどのオープンソースソフトウェアのサポート終了の予定を指します。Scheduled changes（スケジュールされた変更）には、影響を受けるリソースがARN（AWSリソースを一意に識別するための識別子）の形式で表示されるため、まさにアカウント固有のイベントと言えます。

AWSの障害情報が影響を受けるリソース（Affected resources）とともに、アカウント固有のイベントとして表示されるという情報も目にしますが、AWSの公式ドキュメントや実際の運用の中で確認することはできていません。

しかしながら、AWSの障害分離境界に基づいたゾーナル、リージョナル、グローバルの3つのカテゴリのサービスの構造を鑑みると、影響を受けるリソースの表示がなかったとしても、AWS Health Dashboardに表示される情報は、AWS障害の影響範囲を把握するために有用な情報であることに変わりないと考えます。

X（旧 Twitter）

AWSの障害情報を発信する非公式のXアカウントがあります。全リージョンの障害情報を発信するアカウント（@awsstatusjp_all）と、国内リージョン関連の障害情報を発信するアカウント（@awsstatusjp）の2つが存在しています。

AWS Healthから提供される情報をソースとしているようで、AWS Healthでのイベント追加から約2分後にXに表示されていました。

同様の情報はAWS Health Dashboardからも確認できますが、グローバルなシステムの障害が疑われるにXを参考にしている利用者にとっては、一定の利便性があると考えます。

Downdetector

Downdetectorでは、インターネット、ソーシャルメディア、ウェブホスティングプラットフォームなどのサービスの障害に対する口コミがビジュアライズされています。

AWSが公式に発表していない障害を把握したり、障害の大きさ、期間を簡易的かつ直感的に把握する目的で使用することができそうです。

AWS以外のサービスの情報も把握でき、同時に複数のサービスのチャートがスパイクしている場合は、全国的なネットワーク障害を疑うことができます。

まとめ

この記事では、AWSの障害情報の活用方法やその情報源について記載しました。

AWSにおいても障害は発生しますが、AWSが説明する障害分離境界の考え方を理解し状況に応じて適切な情報源を使い分けることで、障害による影響を最小限に抑えるためのスムーズな状況把握ができると考えます。