ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ マルチAZ冗長設計を正しく理解するAWSアーキテクチャ図例｜Draw.ioで描く障害シナリオ
「構成図を作ったのに、障害発生時に誰もどのサーバーが予備機なのか分からなかった。」インフラ担当者の引き継ぎ場面でこうした状況が起きがちです。マルチAZ冗長設計は概念として理解できていても、アーキテクチャ図に「障害時に何がどう動くか」を正確に表現できているエンジニアは意外に少ないものです。
この記事では、Draw.ioを使ったAWSアーキテクチャ図例を中心に、マルチAZ冗長設計の基本構成図の描き方から障害シナリオの表現方法まで体系的に解説します。想定環境はAWS上の3層Webアプリケーション（ALB + EC2 + RDSマルチAZ）です。
この記事のポイント
・Draw.ioのAWS公式シェイプセットを使えばマルチAZ冗長構成を正確に図示できる
・アーキテクチャ図例は「正常時フロー（実線）」と「障害時フロー（赤破線）」の2層で描く
・VPC・サブネット・セキュリティグループの3層境界を図に含めることが設計の基本
・NATゲートウェイはAZごとに1台ずつ配置しないとAZ障害時にアウトバウンド通信が止まる
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／
詳細はこちら
なぜAWSアーキテクチャ図で障害シナリオを描く必要があるのか
AWSのアーキテクチャ図を「正常系の通信経路だけ」で描いているケースが多く見られます。しかし運用の現場では、障害が発生したときに「どのコンポーネントが切断し、どのルートに切り替わるか」をチームが即座に判断できるかどうかが、復旧時間（MTTR）に直結します。マルチAZ冗長設計の目的は、1つのアベイラビリティゾーン（AZ）に障害が起きても、別のAZのリソースが自動的に引き継ぐことです。この切り替えの仕組みをアーキテクチャ図に落とし込んでおくと、次の3つの効果が得られます。
・障害対応の速度向上：復旧担当者が図を見ながら作業できる
・設計レビューの効率化：単一障害点（SPOF）を視覚的に発見しやすくなる
・引き継ぎドキュメントの品質向上：新担当者がゼロから構成を把握できる
マルチAZ冗長設計の基本概念を整理する
Draw.ioでアーキテクチャ図を描く前に、AWSの冗長設計を構成する主な概念を確認しておきます。1. AZ・VPC・サブネットの階層関係
AWSの冗長設計の土台となるのが、Region・AZ・VPC・サブネットの4層構造です。・Region（ap-northeast-1など）：地理的な拠点。東京リージョンには3つのAZが存在する
・AZ（ap-northeast-1a / 1c など）：独立した物理データセンター。1つのAZが停止しても他のAZには影響がない
・VPC（Virtual Private Cloud）：AWSクラウド上の仮想ネットワーク空間。CIDRブロックで定義する（例：10.0.0.0/16）
・サブネット：VPC内のIPアドレス範囲をAZ単位で分割したもの（例：10.0.1.0/24をAZ-1aに割り当て）
アーキテクチャ図ではRegionを最外周の枠、その中にAZ（1aと1cの2つ）、各AZの中にサブネット、サブネットの中にEC2やRDSを配置するレイアウトが標準的です。
2. パブリック・プライベートサブネットの分離
マルチAZ構成では、サブネットをパブリックとプライベートの2種類に分けるのが基本です。・パブリックサブネット：インターネットゲートウェイ（IGW）に直接ルーティングされる。ALBやNATゲートウェイを配置する
・プライベートサブネット：IGWへの直接ルートを持たない。EC2アプリサーバーやRDSを配置する
Draw.ioのアーキテクチャ図例では、パブリックサブネットを薄い青、プライベートサブネットを薄い緑で色分けするスタイルが視認性に優れています。AWS公式のシェイプセットにはこれらの境界を示すアイコンが揃っています。
AWSアーキテクチャ図例：3層Web構成のマルチAZ設計
ALB + EC2（アプリケーション層）+ RDS（データベース層）の3層構成を例に、Draw.ioでの具体的な描き方を解説します。1. 基本の構成要素
標準的なマルチAZ 3層WebアーキテクチャのAWSアーキテクチャ図例の主な構成要素は次のとおりです。・Internet Gateway（IGW）：VPCとインターネットをつなぐゲートウェイ。VPCに1つ存在する
・Application Load Balancer（ALB）：複数のAZにまたがって配置し、トラフィックをEC2へ振り分ける
・EC2インスタンス（App/Webサーバー）：AZ-1aとAZ-1cのプライベートサブネットにそれぞれ1台以上配置する
・RDS Multi-AZ：プライマリをAZ-1a、スタンバイをAZ-1cのプライベートサブネットに配置する
・NAT Gateway：プライベートサブネットのEC2がインターネットへ出るためのゲートウェイ。各AZのパブリックサブネットに1台ずつ配置する（冗長化の鉄則）
2. Draw.ioでのアーキテクチャ図作成手順
Draw.io（app.diagrams.net）はAWS公式の「AWS Architecture Icons 2023」に対応したシェイプセットを無料で利用できるダイアグラムツールです。キャンバスを開いたら左の検索欄に「AWS」と入力してシェイプライブラリを有効にします。これでALB・EC2・RDS・VPC枠・サブネット枠などのAWSアイコン一式が使えるようになります。配置の順番は次の手順が基本です。
# Draw.io 配置手順（概念ガイド。実際の操作はapp.diagrams.netで行う） 1. 最外枠: 「AWS Cloud」枠を作成し、Region全体を包む 2. 第2層: VPC枠をRegion内に配置（ラベル例: 10.0.0.0/16） 3. 第3層: AZ-1a枠とAZ-1c枠をVPC内に横並びで配置 4. 第4層: 各AZにパブリックサブネット枠とプライベートサブネット枠を配置 パブリック（例: 10.0.1.0/24）: ALB、NAT Gatewayを置く プライベート（例: 10.0.2.0/24）: EC2、RDSを置く 5. 接続矢印: 通常フローを実線矢印で表現（左から右へ） Internet → IGW → ALB → EC2 (AZ-1a) → RDS プライマリ (AZ-1a) → EC2 (AZ-1c) → RDS スタンバイ (AZ-1c) # 出力例（環境により異なります）: 上記の論理構成を矩形ネスト+矢印で可視化した # Draw.ioキャンバスが完成する。サブネット境界の色分けで読みやすさが向上する
障害シナリオをアーキテクチャ図に描く方法
AWSのアーキテクチャ図例として最も価値があるのは、障害時にどのコンポーネントがどう動くかを正確に図示したものです。Draw.ioでは通常の接続線とは別に、障害フローを視覚的に区別して描くことができます。1. AZ障害時のEC2フェイルオーバー
AZ-1aのEC2が障害を起こした場合、ALBのヘルスチェックが異常を検知し、トラフィックをAZ-1cのEC2のみへ振り向けます。この流れをアーキテクチャ図に描く方法は次のとおりです。・障害コンポーネント：赤い背景色または「✕」マークをアイコンに重ねる
・切断された経路：赤い破線（‐ ‐ ‐）で表現する
・フェイルオーバー後の有効経路：青い太矢印で強調する
・注釈テキスト：「ALBヘルスチェック異常→AZ-1a切り離し」のテキストノートをコンポーネント近くに添える
「正常時フロー（実線）」と「障害時フロー（赤破線）」を同一の図に重ねるか、タブを分けて2枚で表現するかは用途次第です。1枚にまとめる場合は図の外側に凡例（「—— 実線：通常経路 ‐ ‐ ‐ 赤破線：障害経路」）を必ず配置します。
2. RDSマルチAZのフェイルオーバー経路
RDS Multi-AZはプライマリとスタンバイ間をAWSが自動同期しており、プライマリのAZ障害時にはDNSエンドポイントがスタンバイに切り替わります。この仕組みをアーキテクチャ図に正確に表現する際のポイントは3つあります。・AZ-1aのRDS（プライマリ）とAZ-1cのRDS（スタンバイ）を同一のRDSアイコンで描き、「Multi-AZ同期（自動）」の両方向矢印でつなぐ
・EC2からの接続先は「RDSエンドポイント（DNS）」と明記し、フェイルオーバー後も同じエンドポイントで接続が継続されることを図に示す
・障害シナリオとして「AZ-1a停止 → DNSエンドポイント切替（約1～2分） → AZ-1cが昇格」の流れをテキストノートで注記する
3. NATゲートウェイの冗長化
NATゲートウェイを1つのAZのパブリックサブネットにしか置かない設計は、そのAZが障害を起こすと他のAZのプライベートサブネットからのアウトバウンド通信（OSパッチ取得・外部APIコール等）もすべて止まる単一障害点になります。冗長化の正しい設計は「各AZのパブリックサブネットにNATゲートウェイを1台ずつ配置し、各AZのプライベートサブネットのルートテーブルを同じAZのNAT Gatewayへ向ける」ことです。アーキテクチャ図では、AZ-1aのプライベートサブネットからAZ-1aのNAT GW、AZ-1cのプライベートサブネットからAZ-1cのNAT GWへそれぞれ矢印を向けることで、AZ間の独立性が一目で伝わります。
よくある設計ミスと確認ポイント
| よくある設計ミス | 確認方法 | 対処方針 |
|---|---|---|
| EC2を1つのAZにしか配置していない | アーキテクチャ図にAZが1つしか描かれていないか | 最低2AZにサブネットとEC2を対称に配置する |
| NAT GWが1台のみ（1AZ集中） | 図でNAT GWが片方のAZにしかないか | 各AZのパブリックサブネットにNAT GWを1台ずつ用意する |
| セキュリティグループの範囲が不明瞭 | どのコンポーネントにどのSGが適用されているか図示されているか | SGラベルをアイコン近くに添えるか、凡例シートを別途作成する |
| RDSスタンバイへの直接接続を描いている | EC2からRDSスタンバイへ直接矢印が引かれていないか | 接続先は常にRDSエンドポイント（DNS）のみ。スタンバイへの直接接続は存在しない |
| 障害時フローが図にない | 正常系の経路しか描かれていないか | 障害時フローを赤破線で追記し、凡例に「赤破線=障害経路」を明示する |
本記事のまとめ
Draw.ioを使ったAWSアーキテクチャ図例と、マルチAZ冗長設計で押さえるべきポイントを整理します。| 設計の観点 | アーキテクチャ図への反映方法 |
|---|---|
| AZ分散配置 | AZ-1aとAZ-1cの2つの枠にEC2・RDS・NAT GWを対称に配置する |
| サブネット分離 | パブリック（青色）・プライベート（緑色）を色分けし、ルーティング方向を矢印で示す |
| フェイルオーバー経路 | 通常経路=実線、障害経路=赤破線で区別し、図の外に凡例を配置する |
| RDS Multi-AZ | プライマリとスタンバイを両方描き、「DNSエンドポイントで接続」と注記する |
| NAT GW冗長化 | 各AZのパブリックサブネットに1台ずつ配置し、同AZのプライベートサブネットから矢印を向ける |
| 障害シナリオ注釈 | 「✕障害」「→切替」のテキストノートをコンポーネント近くに添え、凡例と合わせて明示する |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
AWSのEC2（Amazon Linux）をゼロから構築する手順を解説した入門ガイドを公開しています。
＞＞ AWSとAmazon Linuxの入門ガイドを読む
AWSのEC2（Amazon Linux）をゼロから構築する手順を解説した入門ガイドを公開しています。
＞＞ AWSとAmazon Linuxの入門ガイドを読む
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
Linux無料マニュアル（図解60P）
名前とメールで30秒登録
- 次のページへ：AWS VPC Peeringを活用したマルチAZ構成設計ガイド｜CIDR重複回避と経路制御
- 前のページへ：VPC Lattice読み方と設計思想｜AWSサービスメッシュ導入前に押さえる概念整理
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます