本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第7弾として、ネットワーク設計について解説する記事です。
ネットワーク設計はサーバー間・外部接続の物理/論理骨組みを決める作業で、一度決めたCIDRは実質変更できません。本記事ではCIDR設計・サブネットの3層構造・マルチAZ構成・外部接続方式を解説し、「広めに・余裕を持って・社内標準に沿って」引くための判断基準を提示します。
本記事のテーマについてさらに詳しく知りたい方は『Amazon Web Services基礎からのネットワーク＆サーバー構築 改訂4版』も参考にしてみてください。
この記事の結論
- 新規VPCは広めの/16+3層サブネット+マルチAZ
- CIDRは社内標準との重複を最初に確認する
- DBはIsolatedサブネットに置き、NAT GWはAZごとに配置する
- ネットワーク構成は全てTerraform / CDKでコード管理する
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもネットワーク設計とは何か
ネットワーク設計とは、ざっくり言えば「サーバー同士やインターネットとの通信経路を設計する作業」です。
マンションの配管設計を想像してください。水道管（ネットワーク）の太さや分岐をどう引くかは、建築前に決める必要があります。入居後に「やっぱり各部屋に独立した配管が欲しい」と思っても、壁を壊して配管をやり直す大工事です。クラウドのネットワーク設計も同じで、IPアドレスの範囲やサブネットの区切り方を一度決めると、後から変えるには全リソースの再構築が必要になります。
なぜネットワーク設計が重要なのか
もしネットワーク設計を仮決めで進めたらどうなるか。新設のVPCに適当な 10.0.0.0/16 を割り当てた結果、3か月後に社内オンプレと同じレンジを使っていたことが判明し、VPCごと作り直し──という事例は業界でよく聞く失敗パターンです。
ネットワーク設計は、プロジェクト1週目に確定させる領域です。ここを仮決めで進めると、本格構築に入った段階で全てが崩れます。「とりあえず動かしてから考える」が最も通用しない層です。
なお本記事ではAWSの用語を使いますが、Azure・GCPにもほぼ同じ概念があります。VPC（仮想的な自社専用ネットワーク）、サブネット（VPC内を分けた小区画）、CIDR（10.0.0.0/16 形式のIP範囲表記）、IGW（インターネットとの接続点）、NAT GW（プライベート区画からの外向き通信の代行）、セキュリティグループ（リソース単位のファイアウォール）──この6つを押さえれば読み進められます。
CIDRの設計原則 ― 広めに、社内標準に沿って
CIDRの /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 を使うのは地雷です。
サブネットの3層構造
サブネットはPublic（公開）・Private（非公開）・Isolated（隔離）の3層構造で設計するのが現代の標準です。
| 分類 | 用途 | インターネット接続 |
|---|---|---|
| Public Subnet | ALB・NAT GW・踏み台サーバー | 直接接続可 |
| Private Subnet | アプリサーバー・ワーカー | NAT経由で外向きのみ |
| Isolated Subnet | DB・内部バッチ | 外部接続一切なし |
この3層構造により、「DBはインターネットから到達不能」という基本を守ります。DBを直接インターネットに晒すのは、あらゆるセキュリティ基準が禁じる行為で、大規模情報漏洩の温床になります。
経路制御はルートテーブルで行い、Public→IGW・Private→NAT GWが定石です。NAT GWは「外向きに通信したいが外からは触らせたくない」区画用ですが、時間課金+データ転送課金で意外と高く付くため、必要性を見極めて使います。
マルチ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-cALBはマルチAZで自動的にトラフィックを振り分け、RDSのMulti-AZ構成はプライマリとスタンバイを別AZに配置して数十秒で自動フェイルオーバーします。本番は原則マルチAZ、1AZ構成は開発・検証限定と割り切ります。なお帯域とレイテンシの観点では、DBとアプリサーバーは同一AZに置くのが原則です。AZやリージョンを跨ぐ通信は遅延もデータ転送料も増え、コスト試算で見落とすと後で請求書を見て青くなる部分です。
ファイアウォールと外部接続
ファイアウォールはセキュリティグループ（SG）が主役です。SGはリソース単位・ステートフル（戻り通信は自動許可）で、通常の制御は全てSGで行います。サブネット単位のNACLは「特定IPをサブネット全体から遮断する」ような粗い一括制御専用で、新規構築時はデフォルト（全許可）のままにするのが大半です。
外部との接続は要件に応じて段階があります。インターネット公開はIGW+パブリックIP、社内拠点との中小規模連携はVPN（インターネット経由・暗号化）、金融系・大企業の高信頼・大帯域要件は専用線（Direct Connect、月額数十万円〜）。VPC同士はVPC Peeringで直接つなぎ、VPCが増えてきたらTransit Gatewayをハブにします。またS3・RDS等のクラウドサービスへの通信をインターネット非経由にするPrivateLink / VPC Endpointは、セキュリティの厳しい業界では全面採用が定石です。
DNSは、外部公開用のパブリックDNSと社内専用のプライベートDNS（Route 53 Private Hosted Zone等）を使い分けます。マイクロサービス間の内部通信はIP直指定ではなく「サービス名で名前解決」できる設計（Service Discovery）が鉄則で、IPを直接指定するとスケール時に接続が切れる地雷を踏みます。
どう選べばいいのか ― 規模別の3シナリオ
個人開発・スタートアップなら ― 1 VPC+最小NAT
VPCは1つ、/16 で広く取って、3層サブネットとIGWで始めるのが良いと思います。NAT GWは1つで月1.5〜3万円に転送料までかかる見えにくいコスト源ですので、MVP段階では単一NAT（またはNATなし構成）でコストを抑えておき、本番昇格時にマルチAZ NATへ増強する流れがお勧めです。構成は最初からTerraform / CDKで書いておくと、環境複製が数分で済みます。
中小SaaSなら ― 環境別VPCとマルチAZ NAT
prod / stg / devを別VPCに分離し、本番はマルチAZ+AZごとのNAT GWを標準にします。社内拠点との連携はVPNで十分です。VPCが3つを超えて相互接続が要る段階になったら、Peeringの張り合いをやめてTransit Gatewayに集約します。
大企業なら ― 階層管理と閉域網
事業部・環境・国別に数十〜数百のVPCを階層管理し、Direct Connect+Transit Gatewayで閉域網を構築します。CIDRの採番はネットワーク管理部門の社内標準に完全準拠し、主要クラウドサービスへの通信はVPC Endpoint経由に統一します。この規模ではPolicy as Code（後述）による変更ガードレールが必須です。
規模別の目安
| フェーズ | VPC数 | 外部接続 |
|---|---|---|
| 個人・MVP | 1 | IGW+単一NAT GW |
| スタートアップ | 1〜2 | IGW+マルチAZ NAT GW |
| 中規模SaaS | 3〜10（環境別） | Transit Gateway+VPN |
| 大企業 | 50〜数百（階層管理） | Direct Connect+TGW |
AI判断軸 ― IaCで完全再現できるか
AI駆動開発が前提になると、ネットワーク設計は「Terraform / CDKでコード化し、AIがPRを生成できるか」が絶対条件になります。GUIのマネジメントコンソールで作るネットワークは変更履歴が残らず、AIのレビュー対象にもなりません。
Terraformモジュールとしてのネットワーク設計
VPC・サブネット・セキュリティグループをTerraformモジュールとして定義しておくと、AIは既存モジュールの構造を読み取って新しい環境を複製したり、セキュリティグループのルール追加をPRとして提案できます。実務では、VPCモジュールの変数（CIDR・AZ数・サブネット構成）を定義しておき、環境ごとに terraform.tfvars を切り替える構成が標準です。AIはこの変数ファイルの生成を正確にこなせるため、新環境の立ち上げが数分で完了します。
SG変更をAIに任せる際のガードレール
AIにセキュリティグループのルール追加を任せると、動作確認を優先して 0.0.0.0/0 を開放するコードを書くことがあります。これを防ぐには、CIパイプラインにtfsecやCheckovのようなPolicy as Codeツールを組み込み、過度に緩いルールを自動で検出・拒否する仕組みが必要です。AIが生成したネットワーク設定は「動くけど危ない」状態になりやすいため、人間のレビューだけでなくツールによる自動検証を前提とした運用設計が重要です。
やってはいけないこと
後から直しにくい順に、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
CIDRを /24 で始める | サブネット分割で即枯渇し、VPCごと作り直しになる → 最初から /16 で広く取る |
| 社内標準CIDRを確認せずVPCを作る | VPN・専用線接続時にIP重複で接続不能 → 設計前にネットワーク管理部門へ確認する |
| DBをPublicサブネットに配置 | あらゆるセキュリティ基準でNG、情報漏洩の温床 → Isolatedサブネットに置く |
SGで管理画面ポートを 0.0.0.0/0 に開放 | Botに数時間で発見され攻撃対象になる → 接続元IPを絞る |
| NAT GWを1AZのみに配置 | そのAZ障害で他AZの外向き通信も全停止する → 本番はAZごとに配置する |
| 内部通信でIPアドレス直指定 | スケール時に接続が切れる → Service Discovery / DNS名経由にする |
なおS3・DynamoDBへの通信を全てNAT経由にするとデータ転送料が無駄に膨らみます。Gateway Endpoint（無料）を使うのが本命です。
筆者メモ ― CIDR重複でVPNが繋がらない日
大企業のクラウド移行案件で、若手エンジニアがVPCに 10.0.0.0/16 を割り当てて構築を進めていたところ、社内の別部署がオンプレで同じレンジを長年使っていた──いざDirect Connect / VPNで繋ぐ段階で初めて重複が発覚し、VPCを別レンジで作り直し、EC2・RDS・ALB含む全リソースを再構築した、という報告が業界では繰り返し聞かれます。知り合いのインフラエンジニアから「3ヶ月かけて作ったVPCを来月までに全部作り直せと言われた」という話を聞いたこともあります。
教訓は、「CIDRは社内の物理インフラと同じ地図上にある」ということです。IPは世界と繋がった瞬間に、自分1人では決められなくなります。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- VPC CIDR（他システムと重複しないか）
- 利用するAZ数と配置
- サブネット分類と各CIDR
- NAT Gatewayの必要性と配置
- 外部接続方式（VPN / 専用線 / PrivateLink）
- セキュリティグループ設計方針
- DNS / 名前解決の方針
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はクラウドのネットワーク設計について、CIDR・3層サブネット・マルチAZ・外部接続・SG/NACLまで含めて解説しました。如何だったでしょうか。
新規VPCは「広めの/16+3層サブネット+マルチAZ+コード管理」が鉄板です。CIDRは社内標準と重複しないかを最初に確認、DBは必ずIsolated、NAT GWはAZごと。これを外さなければ大事故は起きません。
次回は「セキュリティ基盤」（システムアーキテクチャ段階で組み込むセキュリティ機能の全体地図）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Amazon VPC も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（18/95）