AWSの障害で実際にあったトラブルとは？Amazonから補償を受けることはできる？

2023.08.10(公開: 2023.08.10)

はじめまして、エンジニアスタイル編集部です！

コラムページでは、ITフリーランスに向けてお役立ち情報を発信します。Twitterではホットな案件を紹介してまいりますので、ぜひフォローをお願いいたします！
本記事が、皆様の参考になれば幸いです。

経験がまだ少ない方にもわかりやすく説明するために、初歩的な内容も記載しております。記事も長いので、実務経験豊富な方は、ぜひ目次から関心のある項目を選択してください。

エンジニアスタイルは、最高単価390万円、国内最大級のITフリーランス・副業案件検索サービスです。AWSのフリーランス・副業案件一覧を以下からご覧いただけますのであわせてご確認ください。

前提としてAWSでも障害が生じることを考慮した対策が必要

AWS（Amazon Web Services）は、全世界の大手企業やスタートアップなど、多くの組織が依存しているクラウドサービスの一つです。その高い可用性や信頼性により、多くのミッションクリティカルなアプリケーションやサービスがAWS上で稼働しています。しかし、どれだけ大規模で信頼性が高いシステムであっても、完全に障害から逃れることはできません。このような障害の可能性を前提として、適切な対策を講じることが非常に重要となります。以下、その理由と対策の要点について解説します。以下、その理由と対策の要点について解説します。

ビジネスへの影響の最小化

障害が発生すると、多くの場合、ビジネスの運営に影響が出ます。オンラインストアの場合、サイトがダウンすれば売上が損なわれます。また、B2Bサービスの場合、顧客との信頼を失う可能性があります。このようなビジネスへの影響を最小化するためには、障害対応の計画と実施が欠かせません。

データ損失の防止

AWS上で稼働するシステムやデータベースには、重要な情報が詰まっています。障害発生時にこれらのデータが損失すると、ビジネスにとって致命的な打撃となる可能性があります。バックアップや冗長化の設計を前提とした対策を行うことで、データ損失のリスクを低減することができます。

迅速な復旧

障害が発生した場合、いかに迅速に正常な状態に戻すかが重要です。前もって復旧手順を計画・ドキュメント化しておくことで、障害発生時のパニックを防ぎ、システムを迅速に回復させることができます。

顧客への透明なコミュニケーション

障害が発生した際、エンドユーザーや顧客に対して何が起こったのか、どのように対応しているのかを透明に伝えることが大切です。これにより、信頼関係の維持やブランドイメージの保全に寄与します。

コストの最適化

事前に障害への対策を講じていると、障害発生時のコスト増加を防ぐことができます。例えば、データのバックアップや冗長性の確保により、障害からの回復作業が効率的に行え、追加のコストを削減することが期待できます。

AWSのような大規模なクラウドサービスでも障害は避けられないもの。そのため、事前にリスクを考慮し、計画的な対策を講じることが、ビジネスの持続性や信頼性を保つ上で不可欠となります。

過去にあった具体的なAWS障害事例

次に過去にあった実際のAWS障害事例について紹介します。最初の2件が日本における事例、最後の1件がアメリカにおける事例になります。

冷却システムの障害（2021年2月）

2021年2月にAWSの東京リージョンで発生した障害は、冷却システムの問題が原因でした。具体的には、東京リージョンのAWS本体サーバーの冷却システムへの電力供給が正しく行われなくなったことから、サーバールームの1区画の温度が上昇しました。この結果、Amazon Elastic Compute Cloud (EC2)の一部インスタンスの電源が落ち、EC2で利用できるストレージの一部でパフォーマンスの低下が発生しました。この障害の影響で、オンラインゲームの一部動作が遅くなったり、気象庁の公式サイトへのアクセスが一時的にできなくなるなどの問題が生じました。

ネットワークの接続機器の故障（2021年9月）

2021年9月には、サービス利用者と東京リージョンのAWSデータセンターを結ぶネットワークの接続機器のプロトコル処理に潜在的なバグがあったことが原因で、ネットワーク障害が発生しました。この障害の影響は大きく、日本の大手銀行、携帯電話会社、金融機関、通信会社、航空会社のシステムに不具合が生じました。具体的な影響としては、空港でのチェックイン障害、コンテンツ配信サービスの利用困難、データの更新遅延、サイトアクセス困難、スマホ決済の入金困難などが報告されました。

AWS S3大規模障害（2017年2月）

2017年2月28日、AWSの主要ストレージサービスであるAmazon S3が北バージニアのUS-EAST-1リージョンで数時間の大規模障害を経験しました。この障害は、システムの定期保守中に誤って多くのサーバをオフラインにしたことが原因で、数多くのウェブサービスやアプリケーションに影響を及ぼしました。AWSは後に詳細な事後報告を発表し、顧客に対して補償を行いました。この事件は、クラウドサービスの脆弱性とその広範な影響を浮き彫りにしました。

これらの事例から、AWSの障害はサービスの停止やパフォーマンスの低下など、サービス利用に大きな影響を及ぼす可能性があることが明らかになりました。そのため、AWSを利用する際は、Multi-AZ運用やマルチリージョン運用、障害発生シミュレーションなどの対策を検討することが重要です。

AWSの障害をいち早く認識するにはどうすれば良いか

AWS（Amazon Web Services）を利用する多くの企業や開発者にとって、サービスの障害はビジネスに大きな影響を及ぼす可能性があります。そのため、障害や異常をいち早く認識し、迅速に対応することが重要です。しかし、多種多様なAWSサービスを監視し、その状態を迅速に把握するのは容易ではありません。以下に、AWSの障害を素早く検知するための方法をいくつか紹介します。

監視システムによるアラート

AWSには「Amazon CloudWatch」という監視サービスがあり、リソースやアプリケーションのパフォーマンスを監視できます。指定したメトリクスが一定のしきい値を超えた場合や異常な動きを検知した際にアラートを発することができます。これにより、異常が発生した際にすぐに気付くことができます。

リリースノート

AWSは定期的に新機能や更新をリリースします。これらのリリースノートには、既知の問題や制限事項が記載されていることがあります。障害が発生する可能性がある場合、その情報がリリースノートに記載されることがあります。

Dashboardで表示

AWS Management Consoleには「Personal Health Dashboard」というものがあり、自身のAWSリソースの健康状態や障害情報を一覧で確認することができます。これを定期的にチェックすることで、異常や障害の情報を素早く入手することができます。

SNS

Twitterの障害アカウントを利用する

AWSのサービス障害や状態を報告する非公式アカウントが存在します。これらをフォローすることで、障害情報をリアルタイムで入手することができます。

AWS公式アカウントやサービスアカウントをフォローする

AWSの公式アカウントや各サービスのアカウントは、重要な情報や更新、障害情報を発信することがあります。

リアルタイム情報を受け取るための通知設定

Twitterやその他のSNSの通知機能を有効にすることで、リアルタイムでの障害情報を入手することができます。

ユーザーからの問い合わせ

時にはエンドユーザーやクライアントからのフィードバックや問い合わせが、障害の初期の兆候となることがあります。ユーザーからの報告を真摯に受け止め、障害の可能性を迅速に調査することが大切です。

AWSの障害をいち早く認識するには、多角的な情報収集とシステムの監視が必要です。様々な方法やツールを組み合わせることで、障害のリスクを最小限に抑え、迅速な対応を実現することができます。

AWSの障害を検知する前と後の対応で必要なこととは

AWSを使用する企業の数が増加する中、そのサービスへの依存度も高まっています。そのため、障害が発生したときの対応が非常に重要となります。しかし、障害対応はその発生後だけではありません。実際には、障害発生前の準備や、発生後のフォローアップも含めたトータルでの対応が求められます。

障害を検知する前の対応

AWSのサポートサービスを活用する

AWSは様々なサポートプランを提供しており、中でも「Enterprise Support」は最も充実したサポートを提供します。このプランを利用することで、予め可能性のある問題点や最適化の提案を受けることができるので、障害のリスクを低減することが期待できます。

あらかじめ社内で対応チーム・担当を決める

クリティカルな状況での決断の遅れは大きなダメージに繋がりかねません。それを防ぐためにも、あらかじめ誰が何の役割を果たすのか、という役割分担を明確にしておくことは不可欠です。

意図的に障害を発生させて対応フローを確認

“Chaos Engineering”という考え方があり、これは意図的に障害を引き起こして、システムの耐障害性を試すものです。この手法を取り入れることで、実際の障害時に即座の対応が可能かを確認することができます。

AWSで障害が起きた際のトラブルを想定して対応をドキュメントにしておく

想定される障害とその対応策をドキュメント化しておくことは、実際の障害時に混乱を避ける上で大切です。このドキュメントは定期的に見直しを行い、常に最新の情報が反映されている状態を保つことが求められます。

マルチリージョン・マルチAZの利用

AWSのデータセンターは、世界中の複数の地域（リージョン）に分散して配置されています。各リージョン内には複数のアベイラビリティーゾーン（AZ）が存在します。これを利用して、データやアプリケーションを複数のリージョンやAZに分散させることで、一部リージョンやAZで障害が発生した場合でもサービスを継続できるようにすることが可能です。

障害を検知した後の対応

社内関係者・ユーザーへのお知らせ

障害が確認されると、最も重要なのは情報の透明性です。関係者や顧客に対して障害情報を迅速に伝えることで、理解と協力を得ることができます。

障害の原因を特定し、修復に取り組む

障害の原因究明は、復旧への第一歩です。AWSの提供する監視ツールやログ管理サービスを活用して、障害の根本原因を迅速に特定し、修復に向けたアクションを取ることが必要です。

事後分析を行い、再発防止策を検討

障害が解消された後もその対応は終わりではありません。障害が発生した理由や、それを防ぐための策を再評価することで、将来的なサービスの信頼性向上を目指す必要があります。

障害対応は、前後の取り組みを通じて、企業のビジネス価値や信頼性を保護する重要なプロセスと言えるでしょう。

AWSでトラブルが起きて損害が生じた場合、Amazonから補償を受けることはできるのか

AWS（Amazon Web Services）は、そのサービスの可用性や品質を保つために、多大な努力をしています。しかし、どのシステムにも100%の可用性を保証することは難しく、障害が発生する可能性は完全には排除できません。そういった障害が生じたとき、ユーザーがAmazonから補償を受けることができるのかについて解説します。

サービスレベルアグリーメント (SLA)

AWSは多くのサービスに対してサービスレベルアグリーメント（SLA）を提供しています。このSLAは、サービスの品質や可用性に関する約束を明示的にしており、これを満たさなかった場合の補償内容も明記されています。例えば、Amazon S3やAmazon EC2などの主要なサービスには、月平均可用時間の保証があります。もし、これを下回った場合、顧客はサービス料金の一部をサービスクレジットとして受け取ることができます。ただし、クレジットの取得には、AWSサポートへの適切な申請や通知が必要です。

補償の制限

補償額

SLAに基づく補償は、大抵の場合、該当月のサービス使用料金の一部としてサービスクレジットの形で提供されます。直接的な現金での返金や、実際に被った損害額を超えるような補償は原則としてありません。

補償の対象

SLAの違反に関連するものだけが補償の対象となります。AWSの使用によるビジネス上の機会損失や、第三者からの請求などは補償の対象外です。

申請期限

SLAに基づく補償を受け取るための申請には期限が設定されていることが多く、障害が発生してから一定期間を過ぎると補償を受け取れなくなる可能性があります。

結論

AWSで障害が発生し、損害が生じた場合、サービスレベルアグリーメント（SLA）に基づいてサービスクレジットとしての補償を受けることが可能です。しかし、その補償には一定の条件や制限が付帯しています。実際の運用時には、SLAの内容を十分に理解し、障害が発生した際の手続きや対応策をあらかじめ準備しておくことが重要です。

まとめ

AWSのサービスは高い可用性を目指していますが、完全に障害を避けることは不可能です。障害が生じた際、ユーザーが受け取れる補償は、サービスレベルアグリーメント（SLA）に基づくもので、主にサービスクレジットの形をとります。この補償を受け取るためには、AWSサポートへの特定の申請や通知が必要です。補償は直接的な現金返金ではなく、サービス使用料金の一部として返される点を理解することが重要です。また、補償には一定の制限や条件があるため、実際の運用時にはSLAをしっかりと確認し、必要な手続きを理解しておくことが求められます。