AWS VPC 構成図：サブネット、ルートテーブル、NAT を正しく描く

VPC の構成図の多くは、プロジェクトの最初に一度だけ、コンソールのリソースマップを写す形で描かれます。すべてのリソースが載っていても、実際に図に求められる問いには何ひとつ答えていません。「インターネットからこのデータベースに到達できるのか」「アプリはパッケージをダウンロードできるのに、なぜ接続を受け付けられないのか」「アベイラビリティーゾーンが 1 つ停止したら何が壊れるのか」といった問いです。

このガイドでは、こうした問いに答えられる AWS VPC 構成図の描き方を紹介します。よくある構成として、2 つのアベイラビリティーゾーンにまたがり、パブリック、プライベート、データの各サブネットを持つ VPC を取り上げ、到達性を決める要素であるサブネット、ルートテーブル、ゲートウェイ、エンドポイント、セキュリティグループを順に見ていきます。

VPC 構成図が答えるべき問い

• インターネットから何に到達できるか？ インターネットゲートウェイへのルートを持つパブリックサブネット内のリソースだけです。しかも、セキュリティグループが許可している場合に限ります。
• プライベートなリソースはどうやって外に出るか？ たいていは NAT ゲートウェイ経由、ときには VPC エンドポイント経由です。まったく外に出ないこともあります。
• 層の間でトラフィックはどう流れるか？ ロードバランサーからアプリへ、アプリからデータベースへ。そして、どのポートを使うか。
• AZ に障害が起きたらどうなるか？ 各ゾーンにどのリソースがあり、どれが共有されているか。

これらの問いのどれかに答えにくい図なら、リソースを減らし、構造を増やす必要があります。

構成要素

要素	概要	描き方
VPC	10.0.0.0/16 のような CIDR ブロックを持つプライベートネットワーク	いちばん外側のフレーム。ラベルに CIDR
アベイラビリティーゾーン	リージョン内の分離されたロケーション	VPC 内の列またはフレーム
サブネット	VPC の CIDR のうち、ちょうど 1 つの AZ に属する範囲	所属する AZ 内のフレーム。ラベルに CIDR
ルートテーブル	サブネットからのトラフィックをターゲットへ送るルール	サブネットの層ごとに小さな表
インターネットゲートウェイ	VPC からインターネットへの出入口	VPC の境界上、インターネット側
NAT ゲートウェイ	プライベートサブネットからアウトバウンド接続を開始できるようにする	ゾーン NAT: パブリックサブネット内に AZ ごとに 1 つ。リージョン NAT: 全 AZ で 1 つのゲートウェイ、サブネット不要
VPC エンドポイント	AWS サービスへのプライベートな経路	S3 と DynamoDB はゲートウェイエンドポイント、インターフェイスエンドポイントはサブネット内
セキュリティグループ	各ネットワークインターフェイスに適用されるステートフルなファイアウォール	ポートのルールはボックスではなくエッジのラベルに
ネットワーク ACL	サブネットに適用されるステートレスなフィルター	カスタムルールを使う場合のみ、サブネットにメモ

レイアウト全体を左右する事実が 2 つあります。サブネットは必ず 1 つのアベイラビリティーゾーンに属するため、図の上でサブネットが複数の AZ の列にまたがることはありません。また、標準の（ゾーン）NAT ゲートウェイも 1 つの AZ に属します。唯一の NAT ゲートウェイが AZ a にあると、AZ a に障害が起きたとき、AZ b のプライベートサブネットはアウトバウンドの通信手段を失います。AWS は 2025 年 11 月から、リージョン NAT ゲートウェイも提供しています。これは AZ 間で自動的に拡張され、パブリックサブネットも必要ありません。この例ではゾーン NAT ゲートウェイを使います。

例: 2 つの AZ と 3 つの層

VPC は 10.0.0.0/16 を使い、2 つのアベイラビリティーゾーンにそれぞれ 3 つのサブネットを置きます。

層	AZ a	AZ b	0.0.0.0/0 のルート
パブリック	10.0.0.0/24	10.0.1.0/24	インターネットゲートウェイ
アプリ（プライベート）	10.0.10.0/24	10.0.11.0/24	同じ AZ の NAT ゲートウェイ
データ（プライベート）	10.0.20.0/24	10.0.21.0/24	なし

どのルートテーブルにも 10.0.0.0/16 向けの local ルートがあり、これによって VPC 内のサブネット同士が通信できます。そのうえで、実際に何を許可するかはセキュリティグループが決めます。AWS は各サブネットで 5 つのアドレスを予約するため、/24 で使えるアドレスは 251 個です。

各リソースの配置は次のとおりです。

• Application Load Balancer は両方のパブリックサブネットにノードを持ち、インターネットからの HTTPS を受け付けます。
• アプリサーバー（EC2 インスタンスまたは ECS タスク）は両方のアプリサブネットで動き、ALB のセキュリティグループからのトラフィックだけを受け付けます。
• RDS PostgreSQL のプライマリが一方のデータサブネットで、スタンバイがもう一方で動きます。RDS には、少なくとも 2 つの AZ のサブネットを含む DB サブネットグループが必要です。
• 各パブリックサブネットの NAT ゲートウェイ が、アップデートやサードパーティ API 向けのアウトバウンド通信をアプリサーバーに提供します。
• S3 用のゲートウェイエンドポイント を使うと、アプリサーバーは NAT ゲートウェイを経由せずに S3 にアクセスでき、NAT のデータ処理料金も節約できます。

図は次のとおりです。

読みやすさを保つレイアウトのルール

AZ は列、層は行に

アベイラビリティーゾーンを横に並べ、層を上から下へ、パブリック、アプリ、データの順に配置します。こうすると到達性を上から下へ読み取れ、ある列にだけ欠けているリソースもすぐに目に入ります。

インターネットゲートウェイは境界に置く

インターネットゲートウェイは、サブネットではなく VPC 全体にアタッチされます。VPC のフレーム上、インターネットとパブリックサブネットの間に描きます。

ルートはすべてを矢印で結ばず、表で示す

すべてのサブネットからすべてのゲートウェイへ矢印を引くと、図はクモの巣のようになります。上の例のような層ごとの小さなルートテーブルなら、同じ内容を正確に伝えられます。矢印は主要なトラフィックの経路だけに引きましょう。

セキュリティグループのルールはエッジに書く

セキュリティグループはサブネットではなくネットワークインターフェイスに属するため、フレームで表すのは適切ではありません。代わりに、エッジに HTTPS 443 from internet、8080 from ALB SG、5432 from app SG のようなラベルを付けます。人が探しているのは、まさにこの情報です。

ピアリングと VPN は境界に置く

トランジットゲートウェイ、ピアリング接続、Site-to-Site VPN は、VPC をほかのネットワークにつなぎます。これらは VPC の境界上に描いて接続先の CIDR をラベルに書き、接続先の側は別の図にまとめます。

よくある間違い

• 2 つの AZ にまたがるサブネット。 そのようなサブネットは存在しえません。双子のように同じ構成でも、AZ ごとに 1 つずつ描きます。
• 1 つのゾーン NAT ゲートウェイを両方の AZ で共有していることを書いていない。意図的なコスト判断かもしれません。ゾーンが互いに独立していると誰かが思い込まないよう、図に書いておきます。
• セキュリティグループを入れ子のボックスで描く。 セキュリティグループは自由に重なり合い、インターフェイスごとに適用されます。入れ子にすると、存在しないルールがあるように見えてしまいます。
• コンソールのリソースマップをそのまま写すこと。すべてのネットワークインターフェイスやルートテーブルの関連付けまで載った図は、監査には役立っても、設計図としては読めません。
• CIDR を書いていない。 後でピアリングを妨げるのは、アドレス範囲の重複です。VPC とサブネットのフレームすべてに CIDR を書きましょう。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. ネットワークパックから VPC フレームを追加し、CIDR を 10.0.0.0/16 に設定します。
3. その中に、2 つの AZ 用に基本パックの フレーム を追加し、各 AZ の中にネットワークパックの サブネット フレームを CIDR 付きで追加します。
4. VPC の外にネットワークパックの インターネット ノードを追加し、インターネットゲートウェイとして VPC の境界上に ルーター を置きます。
5. クラウドパックから、ALB 用に クラウドロードバランサー、アプリサーバー用に コンピューティング ノード、RDS のプライマリとスタンバイ用に マネージドデータベース ノードを追加します。NAT ゲートウェイには、ネットワークパックの ルーター ノードを使います。
6. ポート同士を接続し、エッジにポート番号と送信元のセキュリティグループをラベルとして付けます。
7. ルートテーブルをまとめた基本パックの 表 と、AZ ごとの NAT などの判断を書いた メモ を追加します。

この例をすべて描くと Free プランの上限である 15 ダイアグラムノードを超えるため、ここまで詳細な VPC 構成図には Pro が適しています。マルチリージョン構成については AWS マルチリージョンアーキテクチャ図 を、そのほかのネットワークパターンについては ネットワークのユースケースページ をご覧ください。

よくある質問

すべてのサブネットを図に載せるべきですか？ VPC の設計図なら、載せるべきです。到達性はサブネットとルートテーブルによって決まるからです。アプリケーションの図なら、たいていは層ごとに 1 つのフレームで十分です。

AZ ごとに NAT ゲートウェイが必要ですか？ ゾーン NAT ゲートウェイの場合は、ゾーンの独立性を保つために必要です。ゾーン NAT ゲートウェイを 1 つにすればコストは下がりますが、すべての AZ のアウトバウンド通信が 1 つのゾーンに依存し、AZ 間のデータ転送料金も発生します。リージョン NAT ゲートウェイは、ワークロードのある各 AZ に拡張される 1 つのゲートウェイです。どちらを選んでも、図に書いておきましょう。

VPC エンドポイントはどこに描きますか？ ゲートウェイエンドポイント（S3 と DynamoDB）はルートテーブルのターゲットなので、VPC の境界上に描き、ルートテーブルにも記載します。インターフェイスエンドポイントはサブネット内のネットワークインターフェイスなので、それをホストするサブネットの中に描きます。

セキュリティグループとネットワーク ACL、図に載せるのはどちらですか？ セキュリティグループは、常にエッジのラベルとして載せます。ネットワーク ACL は、デフォルトから変更した場合に限り、サブネットへのメモとして書きます。

AWS アカウントからこの図を生成できますか？ Archboard は AWS アカウントを読み取りません。意図した設計を描き、レビューの際にコンソールのリソースマップと比較してください。

無料で始める — 1 シート、クレジットカード不要。