この障害は、Snapのショート動画共有サービス「Snapchat」やRobinhood Marketsの証券取引サービス「Robinhood」、McDonald'sのモバイル注文など、数千社のサービスに影響を与えた。AWSと直接契約していない企業も、取引先のSaaSベンダーや決済処理業者、認証サービスを通してダウンタイムを経験した。

　Webサイト監視サービス「StatusCake」を提供するTrafficCakeのCEO、ジェームズ・バーンズ氏は、「今回のAWSの障害は、Webサービスが人々の想像以上に相互接続されていることを示す一例だ」と話す。「企業がAWSを直接利用していなくても、利用中の認証サービスやデータ分析サービス、決済システム、CRM（顧客関係管理）システム、API、CDN（コンテンツ配信ネットワーク）などを通して、AWSのシステム障害の影響を受ける可能性がある」（バーンズ氏）

　クラウドベンダーは、地域的に分散された可用性の高いITインフラを提供することを約束している。しかしここにクラウド依存のジレンマがある。企業が利用するIaaS（Infrastructure as a Service）は、少数のクラウドベンダーに集中している。具体的にはAWSと「Microsoft Azure」のMicrosoft、「Google Cloud」のGoogleがIaaS市場を支配している。この集中化は、単一のデータセンターで発生した障害が、複数の業界に同時に影響を与える可能性を生じさせている。

　「一部クラウドベンダーへの需要の集中は、必ずしも悪いことではない。大手クラウドベンダーにはデータを安全に保ち、障害を防ぐ意義や動機がある」。政策立案のトレーニングプログラムを手掛けるThe Aspen Instituteでエグゼクティブ・ディレクターを務めるベッツィー・クーパー氏はこう説明する。しかし同氏は「障害が発生すると、広範囲にわたる被害を引き起こす可能性がある」とも指摘している。

　調査会社Constellation Researchの副社長で主任アナリストであるチラグ・メータ氏は、AWSのシステム障害の影響がどのように広がるかを説明した。「多くの組織がAWSに依存していることに気付かずに、間接的に影響を受けた」とメータ氏は述べた。「ユーザー企業が利用するSaaSやAPI、認証サービス、データ連携ツールはしばしばインフラとしてAWSを利用している。データ通信の工程のうちの一部が失敗するだけで、その影響がシステム全体に急速に波及する」（メータ氏）

事業継続計画の盲点

　事業継続計画（BCP）や災害復旧計画（DR）は一般的に、サーバやストレージの故障、ネットワークの分断、データセンターの事故など、自社で管理するインフラの故障シナリオに対処できるように策定される。しかしこれらの計画は、故障したインフラに対して自社で制御が可能であることを前提としている。クラウドサービスの障害は、標準的な災害復旧計画では対処しきれない影響をもたらすことがある。

　ITコンサルティング会社Northdoorでクラウドプラクティスリードを務めるドミニク・グリーン氏は、洗練されたIT部門であっても、クラウドベンダーが引き起こす大規模障害に対して準備が不十分な可能性があると指摘する。「CIOはBCPやDRについて考える際、天災やハードウェアの故障、サイバー攻撃、データセンターの喪失に対する緊急対策に焦点を当てる傾向にある。クラウドインフラに存在する単一障害点や未テストのフェイルオーバー戦略によって引き起こされるトラブルを見落としがちだ」（グリーン氏）

可用性指標への誤った信頼

　コンサルティング会社FTI Consultingのサイバーセキュリティプラクティス部門でシニアマネージングディレクターを務めるトッド・レナー氏は、ITリーダーはクラウドベンダーの可用性要件を信頼してクラウド移行を進めている。しかし、これは必ずしもサービスが無停止であることを保証してはいないことに注意すべきだと話す。「AWSの大規模障害は、大手クラウドベンダーが可用性の稼働時間を“6ナイン”（99.9999％）と定義していることを思い起こさせる。これは100％ではなく、しばしばユーザー企業のIT部門が制御可能な範囲の外にある」と同氏は説明する。

　後編はユーザー企業がクラウドサービスの大規模障害に備え、事業への影響をできる限り抑えるためのポイントを説明する。