障害テストをした後、組織はリスク耐性を見極める必要があるとバートレッティ氏は話す。もし障害が起きた場合、どの程度の時間であれば、ビジネスに支障を来すことなく吸収できるのか。

　組織によってはクラウドの1つのリージョンのみに依存しないアプリケーションの設計を選ぶだろう。そうすれば、たとえ1つのリージョンでサーバがダウンしたとしても、Webサイトが必要とする情報に別のリージョンからアクセスできる。

　「ただしどうやってそれを見つけるかをアプリケーションが知っていなければならない。こうした運用方法は必ずしも高くつくとは限らない。だがアプリケーションの適切なアーキテクチャ構築にかかる時間はやや増えるかもしれない」とバートレッティ氏は述べる。

　耐久性を高めたアプリケーション、すなわちクラウドプロバイダーのデータセンターで障害が起きても運用できるアプリケーションの構築は、本質的に難しいとレオン氏は言う。

　「耐久性の高いアプリケーションの構築は、『複数のデータセンターを利用して、復旧は次のような方法で行いたい』と言い始めた段階で複雑性が増す。いわゆる可用性の5つの9（99.999％）は、1つ9が増すたび急激に高額になる」（レオン氏）

マルチプルは多すぎか

　AWSのクラウド障害を受けて浮上した、複数のクラウドベンダーを使うアプローチは、事態はさらに複雑になり、コストも増す。この方法はアプリケーションのデータをAWSに置き、同じデータを例えば「Microsoft Azure」や「Google Cloud Platform」に保存する。

　だがそれぞれのプロバイダーには違いがあり、機能セットも異なる。

　従って、以下のような問い掛けをする必要が生じるとレオン氏は話す。「自分にとってこの機能は必要なのか。例えばAzureを使うとして、その機能が別のクラウドプロバイダーに存在しない場合はどう対処するのか。その機能は自分で実装できるのか。もしその機能を自分で実装した場合、どの程度のコストが掛かり、どの程度困難なのか。ソリューション全体の安定性は低下するのか」（レオン氏）

　異なるベンダーのクラウドで別々のアプリケーションを運用する企業は珍しくない。だが異なるプロバイダーを横断して1つのアプリケーションを運用するやり方は普通ではない。そうしている企業が何社くらいあるのかという問いに対するレオン氏の答えは「ほぼ皆無」だった。

　バートレッティ氏によると、複数のプロバイダーのクラウドへのアプリケーション複製を検討するのは、特に予算が豊富な大手にとって、常軌を逸した考えではない。だが「それで必ずしもアップタイムが増えるとは限らない」という。

　「他のプロバイダーも、喜々として『AWSが障害を起こした。こちらへどうぞ。当社のストレージの方が優れている』と言ってはいない。なぜならそうした各社のストレージプラットフォームの可用性も、Amazonと同程度に設計されているからだ」（バートレッティ氏）

魔法ではない

　念頭に置くべきこととして、S3の障害はそれほど頻繁には発生しない。AWSのサービスが始まってからの10年で、ダウンしたのはわずか数回にとどまる。

　「S3はAWSで最も古いサービスであり、時の経過に伴い改善されている」とバートレッティ氏は話す。

　大規模な障害はまれであり、今後もそれは変わらないという見方でレオン氏も一致する。それでも今回のAmazonの障害を契機に現実をチェックすることは役に立つと述べ、「クラウドの障害が起きるたび、ユーザーはクラウドが魔法ではないことを思い知らされる。誰もが100％近い可用性に慣れている」と語った。