ネットワーク設計の基礎 ― VPC/サブネット/CIDR ― 生成AI時代のアーキテクチャ超入門

他システムとの接続時にIP帯が重複すれば接続できず、後から変えようとすれば全リソースの再構築コースに入ります。新設のVPCに適当な 10.0.0.0/16 を割り当てて進めた結果、3ヶ月後に社内オンプレと同じレンジを使っていたことが判明し、VPCごと作り直しになった。という事例は業界でよく聞く失敗パターンです。

ネットワーク設計は、プロジェクト1週目に確定させる領域です。ここを仮決めで進めると、本格構築に入った段階で全てが崩れます。「とりあえず動かしてから考える」が最も通用しない層だと考えておくべきです。

ネットワークは「一度決めたら変えられない間取り図」です。最初の設計がすべてになります。

基本用語

ネットワーク設計でよく出てくる用語を整理しておきます。AWSを例に挙げていますが、AzureやGCPでもほぼ同じ概念があります。

用語	意味
VPC	Virtual Private Cloud、仮想的な自社専用ネットワーク
サブネット	VPC内を小さなIPレンジに分けたもの
CIDR	`10.0.0.0/16` 形式のIPアドレス範囲表記
ルートテーブル	通信の経路（次にどこへ送るか）を定義
IGW	Internet Gateway、インターネットとの接続点
NAT GW	プライベートサブネットから外向き通信を代行
セキュリティグループ	リソース単位のファイアウォール

これらを組み合わせて「外部と通信できる区画」と「できない区画」を作り分けるのが基本です。

CIDRの設計原則

CIDR（Classless Inter-Domain Routing）は、IPアドレスの範囲指定表記です。/16・/24 などの数字は「ネットワーク部のビット数」を示し、数字が小さいほど広いアドレス範囲を持ちます。

VPC全体は /16（65,536アドレス）で広く確保するのが鉄板です。これをサブネット /24（256アドレス）単位で分割していきます。

VPC           10.0.0.0/16   ← 65,536アドレス（全体）
├─ Public-a   10.0.0.0/24   ← 256アドレス
├─ Public-c   10.0.1.0/24
├─ Private-a  10.0.10.0/24
├─ Private-c  10.0.11.0/24
├─ DB-a       10.0.20.0/24
└─ DB-c       10.0.21.0/24

他社・他拠点・社内他システムとのCIDR重複は厳禁です。VPN接続やVPCピアリングで繋ぐ際にIPが重複していると接続できません。社内で使うIP帯の標準がある場合は必ず従い、個人判断で 10.0.0.0/16 を使うのは地雷です。

CIDRは広めに（/16 相当）、社内標準と矛盾しないか確認してから確定します。

サブネットの3層構造

サブネットは、VPC内を用途別の区画に分けるための単位です。Public（公開）・Private（非公開）・Isolated（隔離）の3層構造で設計するのが現代の標準です。

flowchart TB
    NET([インターネット]) --> PUB
    subgraph VPC["VPC"]
        subgraph PUB["Public Subnet"]
            ALB[ALB / NAT GW / 踏み台]
        end
        subgraph PRIV["Private Subnet"]
            APP[アプリサーバ / ワーカー]
        end
        subgraph ISO["Isolated Subnet"]
            DB[(DB / 内部バッチ)]
        end
        ALB --> APP
        APP --> DB
        APP -.NAT経由のみ.-> NET
    end
    classDef pub fill:#fee2e2,stroke:#dc2626;
    classDef priv fill:#fef3c7,stroke:#d97706;
    classDef iso fill:#dbeafe,stroke:#2563eb;
    class PUB,ALB pub;
    class PRIV,APP priv;
    class ISO,DB iso;

分類	用途	インターネット接続
Public Subnet	ALB・NAT GW・踏み台サーバー	直接接続可
Private Subnet	アプリサーバー・ワーカー	NAT経由で外向きのみ
Isolated Subnet	DB・内部バッチ	外部接続一切なし

この3層構造により、「DBはインターネットから到達不能」という基本を守ります。DBを直接インターネットに晒すのは、あらゆるセキュリティ基準が禁じる行為です。これを破ると大規模情報漏洩の温床になります。

DBはIsolatedサブネット。外部から直接アクセスできない構造が基本です。

マルチAZ構成

AZ（Availability Zone）とは、同一リージョン内で物理的に分離されたデータセンターのことです。AZ単位で停電・ネットワーク障害が起きる可能性があるため、複数のAZに同じ構成を配置して冗長化するのがマルチAZ設計です。

Region: ap-northeast-1（東京）
├─ AZ-a: Public-a / Private-a / DB-a
└─ AZ-c: Public-c / Private-c / DB-c

ALB（Application Load Balancer、AWSのアプリ層ロードバランサー）はマルチAZで自動的にトラフィックを振り分け、RDS（AWSのマネージドDB）のMulti-AZ構成はプライマリとスタンバイを別AZに配置して数十秒で自動フェイルオーバーします。本番は原則マルチAZ。ここを惜しむと1つのAZ障害でサービス全断になります。

本番は必ずマルチAZです。1AZ構成は開発・検証限定と割り切ります。

ルーティング

ルートテーブルは、サブネット内のリソースが「どの宛先にはどこを経由して送るか」を定義するテーブルです。サブネットごとに異なるルートテーブルを割り当てることで、公開・非公開の挙動を分けます。

送信元サブネット	宛先	次ホップ
Public	0.0.0.0/0（インターネット）	IGW
Private	0.0.0.0/0	NAT GW
Isolated	VPC内のみ	local

Public → IGW・Private → NAT GW が定石です。NAT GWは「プライベートサブネットから外向きに通信はしたいが、外からは触らせたくない」ケース用ですが、時間課金＋データ転送課金で意外と高く付くので、必要性を見極めて使います。

セキュリティグループとNACL

ファイアウォールにはセキュリティグループ（SG）と Network ACL（NACL）の2種類があります。役割が違うため、使い分けが重要です。

項目	Security Group	Network ACL
適用対象	リソース単位（EC2等）	サブネット単位
ステートフル	◎（戻り通信は自動許可）	×
拒否ルール	不可（許可のみ）	可
主な用途	通常のファイアウォール	サブネット全体の粗い制御
評価順	全ルール評価	ルール番号順

通常のファイアウォール制御は全てSGで行うのが本命です。NACLは「特定IPをサブネット全体から遮断したい」などのサブネット全体への一括制御で使います。新規構築時はNACLはデフォルト（全許可）のまま、SGで制御するのが大半です。

基本はSGで十分です。NACLはサブネット単位の特殊制御でのみ使います。

外部との接続方式

クラウドVPCと外部（社内拠点・他クラウド・インターネット）をつなぐ方法は複数あります。セキュリティ・帯域・コストで使い分けます。

方式	用途	特徴
IGW + パブリックIP	インターネット公開	最もシンプル・公開用
NAT GW	プライベートから外向き	外からの直接アクセス不可
VPN	社内拠点 ⇔ クラウド	インターネット経由・暗号化
専用線（Direct Connect等）	高信頼・大帯域・低遅延	月額数十万円〜高価
VPC Peering	VPC同士を直接接続	同一/別リージョン
Transit Gateway	多VPC/マルチアカウントのハブ	大規模組織向け

中小規模の社内連携はVPNで十分です。金融系・大企業では専用線を引き、インターネットを経由しない閉域網を構築するのが定石です。

PrivateLink（プライベート接続）

PrivateLink は、AWS・Azure・GCPなどのクラウドサービスにインターネットを経由せず直接接続する仕組みです。S3・RDS・SSM・CloudWatchなど、通常はパブリック経由でアクセスするサービスも、VPC Endpoint を作ることでVPC内から閉域通信できます。

サービス	名称
AWS	VPC Endpoint / PrivateLink
Azure	Private Endpoint
GCP	Private Service Connect

金融・医療・官公庁などセキュリティが厳しい業界では、主要なAWSサービスは全てVPC Endpoint経由にするのが定石です。

DNS設計

DNS（Domain Name System）は、ドメイン名をIPアドレスに変換する仕組みです。クラウドでは外部公開用のパブリックDNSと、社内専用のプライベートDNSを使い分けます。

種別	用途
パブリックDNS	サービス公開用（api.example.com等）
プライベートDNS	社内名前解決（Route 53 Private Hosted Zone）
スプリットホライゾン	内部と外部で同じドメインを別解決

マイクロサービス間通信では「サービス名で名前解決」できる設計（Service Discovery）が重要です。サービスのIPを直接指定すると、スケール時に接続が切れる地雷を踏みます。内部向けDNSを経由してIPの変化を吸収する構造が鉄則です。

内部通信はIPではなくDNS名で。サービス追加・削除に強くなります。

帯域とレイテンシ

ネットワーク設計では帯域（スループット）とレイテンシ（遅延）を意識する必要があります。クラウドでは通信距離により以下の目安があります。

通信範囲	遅延目安	料金傾向
同一AZ内	1ms未満	無料（多くの場合）
同一リージョン・別AZ	1〜2ms	低コスト
同一国・別リージョン	10〜30ms	中コスト
国を跨ぐ（日米など）	100ms以上	高コスト

DBとアプリサーバーは同一AZに置くのが原則です。AZを跨ぐと遅延もコストも増えます。またリージョン跨ぎのデータ転送は有償のケースが多く、コスト試算時に見落とすと後で請求書を見て青くなる部分です。

組織規模別のネットワーク構成

ネットワーク設計は「広めに・最初から」が鉄則ですが、フェーズごとの現実的な構成には差があります。

フェーズ	VPC数	CIDR方針	外部接続	典型コスト
個人・MVP	1	`/16`（10.0.0.0/16）	IGW + 単一 NAT GW	〜5,000円/月
スタートアップ	1〜2	`/16`（用途別に別VPC検討）	IGW + マルチAZ NAT GW	〜5万円/月
中規模 SaaS	3〜10	環境別（prod/stg/dev分離）	Transit Gateway + VPN	5〜30万円/月
大企業	50〜数百	事業部・環境・国別の階層管理	Direct Connect + TGW + VPC Lattice	数百万円〜

NAT Gatewayは時間課金＋通信料で、1つで月 1.5〜3万円 + データ転送料が乗る見えにくいコスト源です。マルチAZで1AZごとに置くのが本番の鉄則ですが、開発環境まで同じ構成にすると無駄が大きいので、環境別にNAT構成を変えるのが実務の工夫です。

NAT GWはAZごと。1つだけにすると、そのAZ障害で他AZも外向き通信が止まります。

ネットワーク設計の鬼門・禁じ手

ここで事故が起きる・運用が崩壊する典型パターンを整理します。後から直しにくい項目を優先して回避します。

禁じ手	なぜダメか
CIDRを `/24`（256アドレス）で始める	サブネット分割で即枯渇。最初は `/16` で広く取るのが鉄則
社内標準CIDRを確認せずVPCを作る	VPN・Direct Connect接続時にIP重複で接続不能、VPC作り直し
セキュリティグループを `0.0.0.0/0` で管理画面ポートに開放	Botに数時間で発見され、攻撃対象に
DBをPublicサブネットに配置	あらゆるセキュリティ基準でNG。Isolatedサブネット必須
NAT GWを1 AZのみに配置	そのAZ障害で他AZの外向き通信も全停止
内部通信でIPアドレス直指定	スケール時に接続が切れる。Service Discovery / DNS経由が必須
PrivateLink / VPC Endpointを使わず全てNAT経由	データ転送料が跳ね上がる。S3・DynamoDB等はGateway Endpoint（無料）が本命
セキュリティグループで戻り通信を意識してEgressルール自作	SGはステートフルで戻り通信は自動許可。明示ルールで制御するのはNACLの仕事

CIDR設計は「一度決めたら実質変更不能」という性質を持つので、設計前に社内ネットワーク管理部門・既存他システムのCIDR一覧を必ず確認します。「後から広げられる」と思って /24 で始めた結果、VPC ごと作り直す事例が今も繰り返されています。

CIDRとSGは最初の設計ですべて決まる。後からの変更コストが最大の領域です。

AI時代の視点

AI駆動開発が前提になると、ネットワーク設計は「Terraform/CloudFormationでコード化できるか」が絶対条件になります。VPC・サブネット・ルートテーブル・SG・NACLをGUIのマネジメントコンソールで作るのは、AI時代にはもう時代遅れです。

コード化すれば差分レビュー・自動テスト・再現・ロールバックが可能になり、AIがネットワーク変更のPull Requestを作成し、人間がレビューして承認するワークフローが標準化します。

AI時代に有利	AI時代に不利
Terraform/CDK（AWS Cloud Development Kit、AWSのIaCフレームワーク）等でネットワーク全定義	マネジメントコンソールでの手動設定
ネットワーク図をコードから自動生成	手書きのVisio図で構成管理
Policy as Code（ポリシーをコードで定義し自動チェック）で変更ガードレール	口頭伝承の変更ルール
Transit Gateway等も宣言的に記述	VPC間接続を都度手動設定

「CIDRを一度決めたら変更できない」という本質的な制約はAI時代でも変わりません。ただし、どの構成が適切かをAIが提案し、コードで検証するというサイクルで、初期設計ミスの発見が早まるメリットがあります。

AI時代のネットワーク設計は「コードで全て管理」が前提です。コンソール操作は消えていきます。

よくある勘違い

CIDRは/24くらいで十分 → 本当はこう：/24は256アドレスで、サブネット1個分です。AZ数×3層構造で必ず足りなくなります。最初は**/16で広く取る**のが鉄則で、「小さく始めて広げる」ができない領域
SGで全部 0.0.0.0/0 でもAWS側が守ってくれる → 本当はこう：AWSは「許可した通信」は通します。全開放すれば全開放のまま外部に晒される。責任共有モデル（クラウド事業者と利用者で守る範囲を明確に分ける考え方。インフラはAWS、設定・データはユーザー責任）でユーザー側の制御範囲
NAT GWはコスト削減のために1つで足りる → 本当はこう：1AZにしか置かないと、そのAZ障害で他AZまで外向き通信が止まります。マルチAZの意味がなくなる甘い選択
DBもPublicサブネットに置けばアクセスが楽 → 本当はこう：DBをインターネットから到達可能にするのは、あらゆるセキュリティ基準でアウト。必ずIsolatedサブネットに閉じ込める

CIDR重複でVPNが繋がらない日（業界事例）

大企業のクラウド移行案件で、若手エンジニアがVPCに 10.0.0.0/16 を割り当てて構築を進めていたところ、社内の別部署がオンプレで同じレンジを長年使っていた。という事例が少なくありません。いざ Direct Connect / VPN で繋ぐ段階になって初めて重複が発覚し、VPCを別レンジで作り直し、EC2・RDS・ALB 含む全リソースを再構築した、という報告が業界では繰り返し聞かれます。

知り合いのインフラエンジニアから「3ヶ月かけて作ったVPCを来月までに全部作り直せと言われた」という話を聞いたこともあります。

教訓は、「CIDRは社内の物理インフラと同じ地図上にある」ということです。自分のVPCだけを見て決めていい数字ではなく、設計前にネットワーク管理部門や社内標準ドキュメントを必ず確認する習慣が、後からの数ヶ月の損失を防ぎます。

IPは世界と繋がった瞬間に、あなた1人では決められなくなるのです。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

VPC CIDR（他システムと重複しないか）
利用するAZ数と配置
サブネット分類と各CIDR
NAT Gatewayの必要性と配置
外部接続方式（VPN / 専用線 / PrivateLink）
セキュリティグループ設計方針
DNS / 名前解決の方針
社内他システムとの連携方式

よくある失敗

CIDRを狭く取って後から不足 ― 「とりあえず小さめで」と /24 で始めると、アプリ追加・AZ拡張・サブネット分割のたびにIPが枯渇。最初は /16 で広めに確保するのが鉄則
他システムとIP帯重複 ― 社内標準を確認せず 10.0.0.0/16 を使うと、VPN接続・VPCピアリング・オンプレ連携の段でIP重複が発覚、接続不能に
SGに 0.0.0.0/0 を気軽に開ける ― 開発中に「一時的に」全開放したSGがそのまま本番に残り、DBポートや管理画面が世界中から到達可能に
NAT GW 1つを全AZで使う ― コスト削減で1AZだけに置くと、そのAZ障害で他AZのPrivateサブネットからの外向き通信も全停止
内部通信でIP直指定 ― サービス間通信でIPをハードコードすると、スケールアウト・入れ替え・AZ移動のたびに接続エラー

2021年10月4日の Facebook（現 Meta）大規模障害は、BGP（Border Gateway Protocol、インターネット上の経路情報を交換する基幹プロトコル）の設定変更ミスで自社のDNSサーバー群がインターネットから見えなくなり、Facebook・Instagram・WhatsApp が約6時間停止した事件です。社内の入館システムまで同じネットワークに依存しており、エンジニアがデータセンターに入れず復旧に手間取りました。ネットワーク設計ミス1つで企業全体が止まる実例として記憶に残ります。

最終的な判断の仕方

ネットワーク設計の本質は「後から変えられない間取り図をどう決めるか」です。IPアドレス帯（CIDR）は一度決めると実質的に変更不能で、他システムとの重複は接続不能を意味します。そのため最初の問いは「社内標準と矛盾しないか」「10年後も足りる広さか」に置き、迷ったら狭くせず広めに取る。これが原則です。

定石は「広めのCIDR + 3層サブネット（Public/Private/Isolated）+ マルチAZ」で、ここから外れる理由はほぼありません。DBは必ずIsolatedに置き、本番は必ずマルチAZ、中間のNAT GW/PrivateLinkはセキュリティとコストの天秤で決めます。

AI駆動開発の観点では、ネットワークをコード（Terraform等）で管理するのが絶対条件で、GUIコンソール操作で管理するネットワークは今後確実に技術負債化します。

選定の優先順位をまとめると次の通りです。

社内標準CIDRと既存システムのIP帯を最初に確認（重複厳禁）
3層サブネット構造（Public/Private/Isolated）をデフォルトとして採用
マルチAZを本番の必須条件にする（NAT GWもAZごとに配置）
全構成をコード化（Terraform/CDK等）し、AIがPR生成できる状態を保つ

「広めに取って、コードで管理する」この2つを最初に守れば、後からの修正コストが劇的に下がります。

まとめ

本記事はクラウドのネットワーク設計について、CIDR・3層サブネット・マルチAZ・外部接続・SG/NACLまで含めて解説しました。如何だったでしょうか。

新規VPCは「広めの/16 + 3層サブネット + マルチAZ + コード管理」が鉄板です。CIDRは社内標準と重複しないかを最初に確認、DBは必ずIsolated、NAT GWはAZごと。これを外さなければ大事故は起きません。

次回は「セキュリティ基盤」（システムアーキテクチャ段階で組み込むセキュリティ機能の全体地図）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。