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

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第7弾として、ネットワーク設計について解説する記事です。

ネットワーク設計はサーバー間・外部接続の物理/論理骨組みを決める作業で、一度決めたCIDRは実質変更できません。本記事ではCIDR設計・サブネットの3層構造・マルチAZ構成・外部接続方式を解説し、「広めに・余裕を持って・社内標準に沿って」引くための判断基準を提示します。

本記事のテーマについてさらに詳しく知りたい方は『Amazon Web Services基礎からのネットワーク＆サーバー構築 改訂4版』も参考にしてみてください。

そもそもネットワーク設計とは何か

ネットワーク設計とは、ざっくり言えば「サーバー同士やインターネットとの通信経路を設計する作業」です。

マンションの配管設計を想像してください。水道管（ネットワーク）の太さや分岐をどう引くかは、建築前に決める必要があります。入居後に「やっぱり各部屋に独立した配管が欲しい」と思っても、壁を壊して配管をやり直す大工事です。クラウドのネットワーク設計も同じで、IPアドレスの範囲やサブネットの区切り方を一度決めると、後から変えるには全リソースの再構築が必要になります。

なぜネットワーク設計が重要なのか

もしネットワーク設計を仮決めで進めたらどうなるか。新設のVPCに適当な 10.0.0.0/16 を割り当てた結果、3か月後に社内オンプレと同じレンジを使っていたことが判明し、VPCごと作り直し──という事例は業界でよく聞く失敗パターンです。

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

基本用語

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

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

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層構造で設計するのが現代の標準です。

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

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

ルーティング

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

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

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

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

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

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

外部との接続方式

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

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

PrivateLink（プライベート接続）

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

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

DNS設計

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

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

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

帯域とレイテンシ

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

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

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

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

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

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

AI判断軸 ― IaCで完全再現できるか

AI駆動開発が前提になると、ネットワーク設計は「Terraform/CDKでコード化し、AIがPR生成できるか」が絶対条件になります。GUIのマネジメントコンソールで作るネットワークは変更履歴が残らずAIのレビュー対象にもならないため、AI時代にはもう時代遅れです。

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

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

Terraformモジュールとしてのネットワーク設計

VPC・サブネット・セキュリティグループをTerraformモジュールとして定義しておくと、AIは既存モジュールの構造を読み取って新しい環境を複製したり、セキュリティグループのルール追加をPRとして提案できます。

実務では、VPCモジュールの変数（CIDR・AZ数・サブネット構成）を定義しておき、環境ごとにterraform.tfvarsを切り替える構成が標準です。AIはこの変数ファイルの生成を正確にこなせるため、新環境の立ち上げが数分で完了します。

セキュリティグループの変更をAIに任せる際のガードレール

AIにセキュリティグループのルール追加を任せると、動作確認を優先して0.0.0.0/0を開放するコードを書くことがあります。これを防ぐには、CIパイプラインにtfsecやCheckovのようなPolicy as Codeツールを組み込み、過度に緩いルールを自動で検出・拒否する仕組みが必要です。

AIが生成したネットワーク設定は「動くけど危ない」状態になりやすいため、人間のレビューだけでなくツールによる自動検証を前提とした運用設計が重要です。

やってはいけないこと

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

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

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

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 / 名前解決の方針
• 社内他システムとの連携方式

この記事に関連する記事

https://senkohome.com/arch-intro-system-bcp/ https://senkohome.com/arch-intro-system-cloud-vendor/ https://senkohome.com/arch-intro-system-deployment-model/

まとめ

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

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

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

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

本記事で扱った内容の詳細は Amazon VPC も合わせて参考にしてください。

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