前の記事では、AWSのリージョン（Region）と アベイラビリティゾーン（Availability Zone / AZ）について学びました。
重要だったのは、 1つのリージョンの中に複数のAZが存在する という構造です。
では、なぜAWSは1つのリージョン内に複数のAZを用意しているのでしょうか。
複数のAZへ分けて配置する場合では何が違う？
ここで登場するのが、 シングルAZとマルチAZ という考え方です。
この違いを理解すると、 AWSで障害に強いシステムをどのように設計するのか が見えてきます。
シングルAZとマルチAZの違いを理解し、 なぜ複数AZを利用することで可用性を高められるのか を説明できる状態を目指します。
まずはAZについて復習しよう
AWSでは、世界各地にリージョンが存在します。
そして1つのリージョンの中には、 複数のアベイラビリティゾーン（AZ）が存在します。
今回の記事では、 この複数のAZをどのように利用するのか を考えていきます。
シングルAZとは？
シングルAZ（Single-AZ）とは、 システムを構成するリソースを 1つのAZに配置する構成です。
たとえば、WebサーバーとしてEC2を2台使用するとします。
2台のEC2があっても、 どちらも同じAZに存在しているため、 AZという単位で見ると1か所に集中している ことになります。
シングルAZでAZ障害が発生するとどうなる？
では、このAZに大きな障害が発生した場合を考えてみましょう。
2台のEC2を用意していても、 同じAZへ配置している場合、 そのAZ全体に影響する障害では両方のサーバーが影響を受ける可能性 があります。
冗長化では台数だけでなく、 どこへ配置するか も重要です。
マルチAZとは？
マルチAZ（Multi-AZ）とは、 複数のアベイラビリティゾーンを利用して リソースを配置する構成です。
先ほどのWebサーバー2台を、 今度は別々のAZへ配置してみましょう。
この構成では、 Web Server 1とWeb Server 2が 異なるAZに分散されています。
これがマルチAZ構成の基本的な考え方です。
マルチAZでAZ障害が発生するとどうなる？
先ほどと同じように、 AZ-Aで障害が発生した場合を考えてみます。
AZ-Aに障害が発生しても、 AZ-B自体がその障害の影響を受けていなければ、 AZ-B側のリソースを利用できる可能性があります。
このように障害の影響範囲を分散することが、 マルチAZを利用する大きな目的です。
マルチAZにすれば自動的に切り替わる？
ここは非常に重要です。
たとえばEC2をAZ-AとAZ-Bへ1台ずつ配置しただけでは、 利用者からの通信を自動的に正常なEC2へ振り分ける仕組みまでは完成していません。
Webシステムであれば、 Elastic Load Balancing（ELB）などを組み合わせて、 複数AZのEC2へ通信を分散する構成が考えられます。
このように、 複数AZへの配置＋AWSサービスの機能 を組み合わせて、 障害に強い構成を設計していきます。
マルチAZと「可用性」の関係
AWSを学習していると、 可用性（Availability） という言葉が頻繁に登場します。
システムやサービスを、 必要なときに継続して利用できる性質。
たとえばWebサイトが24時間動いているとしても、 障害が発生するたびに長時間停止してしまえば、 可用性が高いとは言えません。
AZ-Aに障害が発生すると、 システム全体へ影響する可能性がある
複数AZへ分散することで、 1つのAZ障害による影響を抑えやすい
AWSではサービスの特性に合わせて、 複数AZを利用した構成を設計することが重要です。
シングルAZとマルチAZの違いを整理しよう
マルチAZなら常に正解というわけではない
ここまで読むと、 「それならすべてマルチAZにすればよいのでは？」 と思うかもしれません。
しかし、システム設計では 可用性だけでなくコストや要件も考える必要があります。
たとえば、 停止しても大きな問題にならない検証環境であれば、 シンプルな構成を選択することもあります。
一方で、 多くの利用者が使う本番システムなどでは、 障害による停止時間を減らすために マルチAZ構成を検討することがあります。
必要な可用性とコストを考え、 システムの要件に合った構成を選択することが重要です。
AWSサービスによってマルチAZの実現方法は異なる
もう1つ覚えておきたいのが、 AWSサービスによってマルチAZの使い方が異なる ということです。
ELBやAuto Scalingなどと組み合わせ、 複数AZを利用した構成を設計できます。
Multi-AZの機能を利用することで、 高可用性を目的とした構成を利用できます。
今の段階ですべてのサービスの仕組みを覚える必要はありません。
障害シミュレーション：どちらの構成が強い？
ここまでの内容を使って、 実際に構成を選んでみましょう。
AZ障害に備えるならどちらを選ぶ？
Webサーバーを2台構築します。 1つのAZで障害が発生しても、 別AZのWebサーバーを利用できる構成にしたいとします。
AZ-A全体に障害が発生した場合を考えてみましょう。
もう一段階考えてみよう：AZ-Aで障害が発生
次は実際に、 AZ-Aで障害が発生したと仮定します。
AZ-Aで障害を発生させてみよう
ボタンを押して、AZ障害時に何が起きるか確認してみましょう。
初心者が間違えやすいポイント
① EC2を2台にすればマルチAZになる
EC2の台数だけでは判断できません。
EC2 ＋ EC2
EC2 ＋ EC2
重要なのは、 複数のAZへ分散されているか です。
② マルチAZならすべて自動で切り替わる
これも誤解しやすいポイントです。
AWSサービスによって高可用性を実現する仕組みは異なります。 単純にリソースを別AZへ配置することと、 障害発生時にサービスを継続できる仕組みを構築すること は分けて考えましょう。
③ マルチAZとマルチリージョンは同じ
マルチAZは、 1つのリージョン内で複数AZを利用する構成 です。
AZ-A ＋ AZ-B
複数Regionを利用
マルチリージョンはさらに大きな地理的範囲で システムを分散する考え方です。
確認問題：シングルAZとマルチAZを理解できたか確認しよう
マルチAZについて正しい説明はどれですか？
マルチAZでは、1つのリージョン内にある複数のAZを利用します。
マルチAZ構成を利用する主な目的として適切なものはどれですか？
複数AZへリソースを分散することで、 特定AZの障害による影響を抑えやすくなります。
EC2をAZ-AとAZ-Bへ1台ずつ配置しました。 この説明として最も適切なものはどれですか？
EC2を複数AZへ配置するだけで、 自動的な通信切り替えなどがすべて実現されるわけではありません。
3問に挑戦してみましょう。
まとめ
シングルAZは、 1つのAZを利用する構成
マルチAZは、 複数のAZを利用してリソースを分散する構成
複数AZへ分散することで、 特定AZの障害による影響を抑えやすくなる
マルチAZは 高可用性を実現するための重要な考え方 の1つ
複数AZへ配置しただけで 必ず自動フェイルオーバーするわけではない
可用性・コスト・システム要件を考えて 適切な構成を選択する ことが重要
次は「AWSと利用者の責任範囲」を理解しよう
ここまでで、 AWSが用意しているリージョンやAZを利用して、 障害に強いシステムを設計する基本的な考え方を学びました。
では、AWSを利用してシステムを構築した場合、 セキュリティやシステム管理はすべてAWSが行ってくれるのでしょうか？
実際には、AWSと利用者それぞれに セキュリティや管理についての責任範囲 があります。
この考え方を AWS責任共有モデル（Shared Responsibility Model） と呼びます。
次は「AWS責任共有モデルを理解する」を学びましょう
AWSを利用すると、 すべてのセキュリティ管理をAWSへ任せられるわけではありません。
AWSが担当する範囲と 利用者が担当する範囲を整理して、 クラウドにおけるセキュリティの基本を理解していきます。
AWS責任共有モデルを理解する →