　今回の障害で、Multi-AZ配置になっていないアプリケーションがかなり多いことが明らかになった。これについて城氏は「オンプレミスからそのままリフト（移行）してAWSに載せた場合は、Single-AZで動かしているものがかなりある。これをMulti-AZ配置に対応させるには、設計変更を行いアプリケーションに手を入れ入ることになりハードルが高い」と説明する。

　またデータウェアハウスのようなシステムでは、1つのAZにリソースを寄せ、シンプルな構成にしてコストパフォーマンスの良い環境を用意することもある。もちろんMulti-AZ配置にすればコストが上がるので、継続性を重視しなければSingle-AZで運用するという判断もある。

　ところで、今回のような障害が発生しても、障害が取り除かれればシステムは障害発生前の状態に復旧される。そのためユーザーは、障害が取り除かれるのを基本的にはただ待っていれば良い。しかし場合によってはデータ破損も起こり得る。また復旧を待っていられないサービスは、早い段階で判断し障害発生したAZを切り離して他のAZで復旧させる措置も必要だ。

　これらに対処するにはバックアップを確実に取得し、さらにバックアップからの復旧が迅速に行えるよう日ごろから訓練しておくことが重要だ。バックアップデータは、最低限他のAZに置く。また他のリージョンに置くことも含め、システムの重要性に応じたバックアップ／リカバリー設計をしなければならない。

　もう1つ、マルチリージョンによる可用性構成が必要との声も上がっている。Single-AZの障害でもMulti-AZ配置のサービスに影響が出ることを考えれば、その必要性があるシステムも多そうだ。実際にマルチリージョンで可用性構成をとる場合は「どうデータの同期をとるかが課題となる」と石田氏。AZ間であれば、データ転送の速度やコストは問題にならないかもしれない。しかしリージョン間になると、大規模データを転送しようとすれば時間もかかりコストも増大する。可用性を維持するために、どのくらいの頻度でデータを転送すべきかは十分な考慮が必要なのだ。

　「AWS Direct Connectを使っていれば、スタンバイ側に移行した際にそれをどうするかも考えなければならない。また、障害発生時には一気に多くのシステムがリージョン間で移行すれば、リソースの取り合いになる。コストを下げるためにアクティブ-スタンバイ構成にしていると、リソースが確保できずうまく動かない可能性もあるだろう。そのため、コストが上がってもアクティブ-アクティブで日常的に動かしておく選択もある。このように運用体制も含め、マルチリージョンで有事の際に確実にシステムが動くようにするのは、かなり大変」（石田氏）

　これがマルチクラウドとなれば、さらに考慮すべきポイントが増え、コストも増大することは容易に想像できるだろう。

サーバレスや第三者のパートナーの存在も有用

　もう1つ、サーバレスならば今回のような障害の対策に有効との声もある。確かにAmazon API GatewayやAWS Lambdaなどのサーバレスで利用される機能の多くは、特定のAZに依存する形で動くものはない。そのため「サーバレスがSingle-AZの障害に強いのは確かだ」と佐藤氏も話す。

　とはいえサーバレスの機能だけで実現できるアプリケーションはまだ少ない。サーバレス技術さえ使っていれば、Single-AZの障害に耐えられるわけでない。アプリケーション全体で障害にどう対処するかは、別途考えておく必要がある。一方でサーバレスを使えば、大きくコストを下げられる。コストのかかる冗長化とうまく組み合わせることで、コスト効率の良い可用性構成を実現できる。アプリケーション全体の可用性向上に、サーバレスは有効な手段だろう。

　また前述のように障害発生時にAWSのリージョン内でネットワーク負荷が上がったためか、AWSマネジメントコンソールから自分が利用しているサービスの状況が見えないこともあったようだ。そのため、障害の状況をTwitterなどのつぶやきなど外部の情報源でしか確認できなかった人もいる。仮にマネジメントコンソールから状況を見ることができたとしても、自分の利用しているサービスの生き死には分かっても障害の全体像をリアルタイムに把握できるとは限らない。

　こういった時にもサーバーワークスのように複数顧客のAWSのシステム運用監視を請け負っている立場なら、情報源が数多くあり障害実態を把握しやすい。サービスの継続性が必須でシステムの重要度が高い場合は、自分たちだけで運用監視を行うのではなく、あえて第三者の立場で情報収集できるパートナーを選んでおく。そうすることが、障害からの迅速な復旧の有用な手段になるのではないか。このあたりも、オンプレミスのようにシステム環境が手元になく、インフラ運用管理の責任をクラウドプロバイダーと分離して運用する場合は、必要な投資になるのだろう。

AWS障害、複数のアベイラビリティゾーン利用でも影響　AWSが説明を修正
AWS東京リージョンの大規模障害について、AWSが追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めた。
AWS障害、“マルチAZ”なら大丈夫だったのか？　インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
AWSの障害に、各社はどのように対応したのか。ITmedia NEWS編集部では問題に直面した企業やエンジニアに聞き取り調査を行った。生の声から、実情が見えてきた。
AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず
2019年8月23日金曜日の午後、AWS東京リージョンで大規模障害が発生した。これについて、AWSが日本語での詳しい報告を発表した。
AWS障害、大部分の復旧完了　原因は「サーバの過熱」
米AWSは午後8時18分、クラウドサーバの復旧がほぼ完了したことを明らかにした。制御システムの障害により、サーバの温度が上がりすぎたことが原因だったという。