【AWS/Azure】ハイブリッドクラウドネットワーク設計書の書き方｜CIDR・専用線

2026年9月20日

レベル別記事一覧

▼▼▼まずはここからチェック！

【結論】ハイブリッドネットワーク設計書で押さえるべき4大鉄則

オンプレミスとクラウドを跨ぐネットワークを設計する際、現場で絶対に外してはならない大原則は以下の4点です。

① オンプレと絶対に重複させない「広域階層型CIDR設計」
第2・第3オクテットで拠点・クラウド・環境（本番/検証）を厳密に分離し、将来のマルチアカウント・マルチリージョン拡張に耐えうるアドレスプールを事前確保する。
② クラウド事業者の「予約IP（AWS:5個 / Azure:5個）」を前提に計算する
オンプレの感覚（ネットワークアドレスとブロードキャストアドレスの2個引き）を捨て、サブネットサイズは最小でも /27 または /26 を基本とする。
③ Transit Gateway / Virtual WANを中心とした「ハブ＆スポーク型ルーティング分離」
全VPCをメッシュ接続するのではなく、集約ルータ（TGW/vWAN）を介して本番環境・検証環境・共有サービス間のルートテーブルを論理的に完全分離する。
④ 専用線冗長化時の「インバウンド／アウトバウンド非対称ルーティング」を防止する
行き（オンプレ ➔ クラウド）はLocal Preference、戻り（クラウド ➔ オンプレ）はAS-Path PrependingやMEDを用いて優先度を一致させ、オンプレ側FWでのパケット破棄を完全に防ぐ。

なぜハイブリッド接続設計は破綻するのか？オンプレとクラウドの4大ギャップ

クラウド移行のネットワーク設計で手戻りが発生する最大の理由は、「オンプレミスの常識がクラウドでは通用しない」ことにあります。

設計書を起こす前に、必ず押さえておくべき4大ギャップを整理します。

物理L2（ブロードキャストドメイン）が存在しない世界

オンプレミスのネットワーク設計では、スイッチ上でVLANを切り、同一VLAN内であればARPブロードキャストやGARP、VRRP/HSRPによる冗長化が当たり前に機能していました。

しかし、AWS VPCやAzure VNetの内部は、物理ネットワークの上に仮想化オーバーレイ（SDN）が敷かれています。

ブロードキャスト通信やマルチキャスト通信は原則として破棄され、ARPスプーフィングやVIP（仮想IP）のGratuitous ARPによるフェイルオーバーは動作しません。

設計書に「同一セグメントでのL2延伸」や「VRRPによるVIP切り替え」を安易に盛り込むと、実装フェーズで100%破綻します。

クラウドアグリゲーションにおいては、ロードバランサー（ALB/NLB等）やルートテーブル切り替えAPIを用いた「L3ベースの設計」へ思考を完全にシフトさせる必要があります。

クラウド特有の「予約IP」によるアドレス枯渇

オンプレミスでは、サブネット内の使用不可IPは「ネットワークアドレス（先頭）」と「ブロードキャストアドレス（末尾）」の2個だけでした。

一方、主要パブリッククラウドでは、管理用・基盤サービス用に各サブネットあたり先頭・末尾から計5個のIPが予約されています。

IPアドレスの位置	AWS VPCの予約用途	Azure VNetの予約用途
先頭（.0）	ネットワークアドレス	ネットワークアドレス
2番目（.1）	VPCルータ用	デフォルトゲートウェイ用
3番目（.2）	AWS DNS用	Azure DNS用
4番目（.3）	将来の利用のために予約	将来の利用のために予約
末尾（.255等）	ブロードキャストアドレス（予約）	ブロードキャストアドレス

たとえば、少数のサーバ用に /28（合計16個）のサブネットを切ると、利用可能なホストIPは 16−5=11 個しか残りません。冗長化構成や将来のオートスケーリング、マネージドサービス（Private Endpoint等）を配置した瞬間にIPが枯渇します。

設計書のアドレッシング規約には、「サブネットの最小サイズは /27（利用可能27個）または /26（利用可能59個）とする」といった安全係数を組み込むことが鉄則です。

クラウド側の上限値とBGP経路数制限

クラウドには、基盤の安定性を担保するための「サービス上限値」が存在します。特に専用線接続におけるBGP経路数の上限は見落としがちです。

AWS Direct Connect (Transit VIF)
アタッチされたDirect Connect GatewayからアドバタイズできるBGPルート数の上限は最大100プレフィックス。
AWS ルートテーブル
1つのVPCルートテーブルに登録できるルート数はデフォルトで50ルート（緩和申請で最大100ルート）。
Azure ExpressRoute Gateway
ゲートウェイSKUごとに学習可能な最大ルート数が厳密に制限（標準ゲートウェイで最大4,000ルート、ルート数超過時はBGPセッションが切断）。

オンプレミス側のL3スイッチが社内LANの細かなサブネット（/24など）をそのままクラウドへ広報してしまうと、上限を超過した瞬間にBGPセッションが切断されるか、一部の経路が受信拒否されます。

設計書には「オンプレミス側エッジルータで必ず広報ルートを集約する」要件を明記しなければなりません。

オンプレミス設計書とクラウドリソースの対比マッピング

オンプレミス専門のエンジニアや社内SEとクラウドアーキテクトが設計レビューを行う際、用語の認識齟齬がトラブルの火種になります。

まずは、オンプレミスの構成要素がクラウド上でどのリソースに対応するのかを正確に対比させます。

オンプレミス概念 ➔ AWS / Azureリソース対照表

オンプレミス構成要素	物理・論理の役割	AWSリソース	Azureリソース	設計書での記載ポイント
データセンター / 拠点	物理的な立地・境界	リージョン / VPC	リージョン / VNet	地理的冗長性、遅延要件
フロア / サーバルーム	物理的な電源・空調の独立区画	Availability Zone (AZ)	Availability Zone (AZ)	マルチAZ設計による可用性担保
VLAN / セグメント	L2ブロードキャスト境界	Subnet (AZ固有)	Subnet (VNet全体)	AWSはSubnetがAZに閉じる点に注意
コアルータ / VRF	L3ルーティング・論理分離	Transit Gateway (TGW)	Virtual WAN / Virtual Network Gateway	ハブ＆スポーク経路集約
スイッチポート / NIC	物理インターフェース	ENI (Elastic Network Interface)	仮想ネットワークインターフェース (NIC)	プライベートIPの固定化要否
ルータのルーティングテーブル	パケットの転送先定義	Route Table	Route Table (UDR: ユーザー定義ルート)	デフォルトルート (0.0.0.0/0) の向き先
ステートレスACL (L3スイッチ)	パケットフィルタリング	ネットワークACL (NACL)	該当なし (NSGでステートフル制御)	サブネット単位の通信制御境界
ファイアウォール (FW)	アプリ・ポート単位の制御	セキュリティグループ (SG)	ネットワークセキュリティグループ (NSG)	ENI/NIC単位のステートフル制御
専用線 / WAN引込	キャリア閉域網接続	AWS Direct Connect (DX)	Azure ExpressRoute (ER)	物理帯域、BGPピアリング

ハイブリッド構成における責任共有境界のドキュメント化

ハイブリッドクラウドの設計書では、「どこからどこまでが通信キャリアの責任で、どこからが自社の運用責任か」の責任分界点を明確に図示する必要があります。

設計書の「基本方針」セクションには、上記の物理終端位置、VLANタグの付与位置、BGPピアのアドレス割り当て位置を明記した「責任分界点マップ」を必ず掲載します。

破綻しない「ハイブリッドCIDR・サブネット設計書」の書き方

ハイブリッドクラウド環境において、後から最も変更が効かないのがIPアドレス空間（CIDR）の設計です。

VPCやVNetのアドレス範囲を一度作成すると、後から変更するには大規模なリソース再構築とサービス停止が必要になります。

オンプレミスと連携する全体IPアドレッシング規則

プライベートIPアドレス空間（RFC 1918：10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）の中から、オンプレミスとクラウドで完全に重複しないアドレスブロックを切り出します。

推奨されるのは、「第2オクテットで拠点・環境を分け、第3オクテットで役割を分ける」階層化設計です。

このように大枠のブロックをあらかじめ予約しておくことで、ルータやFWのルーティングテーブルに 10.100.0.0/16 の1行を追加するだけで、クラウド上の全本番VPCへの通信を集約（サマライズ）できるようになります。

サブネットの役割別3層分離設計

1つのVPC/VNet内では、セキュリティ要件とインターネット到達性に応じてサブネットを3層に分離します。

Public Subnet（外向け境界）
- インターネットゲートウェイ（IGW）への直接ルートを持つ。
- 配置リソース：NAT Gateway、インターネット向けALB。
- ※直接EC2や仮想マシンを配置することはセキュリティ上原則禁止。
Private Subnet（業務システム層）
- インターネットへの直接のインバウンド／アウトバウンドルートを持たない。
- 外への通信はPublic SubnetのNAT Gatewayを経由する。
- 配置リソース：Web/Appサーバ、コンテナクラスタ（ECS/EKS/AKS）、RDS/データベース。
Isolated / Attachment Subnet（接続専用層）
- NAT GatewayやIGWへのルートを一切持たず、VPC内またはTGW経由の閉域通信のみを許可する。
- 配置リソース：Transit Gatewayアタッチメント用ENI、専用ファイアウォールエンドポイント、DB専用サブネット。

【実務サンプル】VPC・サブネットパラメータシート

設計書にそのまま貼り付けて使用できるパラメータ定義表の形式です。

ネットワーク名	CIDR	AZ	サブネット名	役割・用途	利用可能IP	関連ルートテーブル
vpc-prod-tokyo	`10.100.0.0/20`	–	–	本番業務VPC	–	–
└ Subnet-Pub-1a	`10.100.0.0/24`	ap-northeast-1a	`snet-prod-pub-1a`	NAT-GW / ALB	251	`rtb-prod-public`
└ Subnet-Pub-1c	`10.100.1.0/24`	ap-northeast-1c	`snet-prod-pub-1c`	NAT-GW / ALB	251	`rtb-prod-public`
└ Subnet-Pri-1a	`10.100.2.0/23`	ap-northeast-1a	`snet-prod-app-1a`	App / Container	507	`rtb-prod-private-1a`
└ Subnet-Pri-1c	`10.100.4.0/23`	ap-northeast-1c	`snet-prod-app-1c`	App / Container	507	`rtb-prod-private-1c`
└ Subnet-DB-1a	`10.100.6.0/24`	ap-northeast-1a	`snet-prod-db-1a`	RDS Aurora	251	`rtb-prod-isolated`
└ Subnet-DB-1c	`10.100.7.0/24`	ap-northeast-1c	`snet-prod-db-1c`	RDS Aurora	251	`rtb-prod-isolated`
└ Subnet-TGW-1a	`10.100.15.0/28`	ap-northeast-1a	`snet-prod-tgw-1a`	TGWアタッチメント	11	`rtb-prod-isolated`
└ Subnet-TGW-1c	`10.100.15.16/28`	ap-northeast-1c	`snet-prod-tgw-1c`	TGWアタッチメント	11	`rtb-prod-isolated`

💡 ポイント: TGWアタッチメント用サブネットはENIが1つ配置されるだけなので、/28（利用可能11個）で十分です。貴重なアドレスを無駄遣いしないようメリハリをつけます。

Transit Gateway（TGW）設計とルートテーブル定義書の書き方

オンプレミスと複数のVPC/VNetを相互接続する場合、AWSではAWS Transit Gateway（TGW）、AzureではAzure Virtual WAN（vWAN）を中央ハブとする「ハブ＆スポーク型」を採用するのが業界標準です。

ハブ＆スポーク構造におけるルートテーブル分離設計

すべての通信を1つの巨大なルートテーブルに放り込むと、「検証環境から本番環境のDBへ意図せずパケットが届いてしまう」といった重大な事故が起きます。

TGW内では、用途ごとにルートテーブルを分離して定義します。

ルート伝播と静的ルートの使い分け

TGWのルーティング定義書では、経路の学習方式を明確に区別して記載します。

関連付け（Association）
そのアタッチメント（VPCや専用線）からTGWに入ってきたパケットが、「どのルートテーブルを参照してルーティングされるか」を決定する（1つのアタッチメントにつき1つのルートテーブルのみ関連付け可能）。
伝播（Propagation）
そのアタッチメントが持つCIDR情報を、「どのTGWルートテーブルに自動登録（動的学習）させるか」を決定する（複数のルートテーブルへ伝播可能）。
静的ルート（Static Route）
デフォルトルート（0.0.0.0/0）を集約ファイアウォールVPCに向けたい場合や、特定のBlackhole（破棄）ルートを設定したい場合に明示的に手動登録する。

【実務サンプル】TGWアタッチメント定義書

アタッチメント名	接続リソース	リソースID	関連付けルートテーブル (Association)	伝播先ルートテーブル (Propagation)	備考
`tgw-att-prod-vpc`	VPC (本番)	`vpc-0a1b2c3d`	`tgw-rtb-prod`	`tgw-rtb-shared`, `tgw-rtb-edge`	本番環境VPCアタッチメント
`tgw-att-dev-vpc`	VPC (検証)	`vpc-0e4f5a6b`	`tgw-rtb-dev`	`tgw-rtb-shared`, `tgw-rtb-edge`	検証環境VPCアタッチメント
`tgw-att-shared-vpc`	VPC (共通)	`vpc-09876543`	`tgw-rtb-shared`	`tgw-rtb-prod`, `tgw-rtb-dev`	AD・監視サーバ共有VPC
`tgw-att-dxgw`	Direct Connect GW	`dxgw-11223344`	`tgw-rtb-edge`	`tgw-rtb-prod`, `tgw-rtb-dev`, `tgw-rtb-shared`	オンプレミス閉域網接続

Direct Connect / ExpressRoute設計書：BGP冗長化と非対称ルーティング対策

ハイブリッドクラウドの根幹となるのが、物理専用線とBGP（Border Gateway Protocol）による動的ルーティングです。

ここを曖昧に記述すると、通信キャリアやNW構築ベンダーとの間で手戻りが無限に発生します。

専用線接続の物理・論理パラメータ（AWS DX vs Azure ER）

設計書の「回線接続仕様」には、以下の項目を一覧化します。

項目名	設定値例（AWS Direct Connect）	設定値例（Azure ExpressRoute）	説明
接続ロケーション	Equinix TY2 (東京)	Equinix TY2 (東京)	物理クロスコネクトを接続する接続拠点
物理ポート帯域	1 Gbps Dedicated (占有)	1 Gbps / Direct	物理インターフェースの帯域
インターフェース	1000BASE-LX (シングルモード光)	1000BASE-LX	光ファイバーのコネクタ・波長仕様
VLAN ID	`VLAN 100`	`VLAN 100`	802.1QタグVLAN番号
MTUサイズ	9001 (Jumbo Frames)	1500 (Standard固定)	AWSはJumbo対応、Azureは1500固定

■ Azure ExpressRouteを設計する際の必須注意点

AWS Direct Connectと異なり、Azure ExpressRouteのプライベートピアリングでは以下の固有仕様を設計書に明記する必要があります。

MTUサイズは「1500固定」（Jumbo Frame非対応のためオンプレ側ルータもMTU 1500に設定）
BGP ASN：オンプレミス側はプライベートASNを使用するが、「65515〜65521」はAzure内部予約のため使用不可。Microsoft側ASNは「12076」に固定される
ルータ冗長化：ExpressRouteは1回線契約で2本の物理接続（Primary/Secondary）が提供されるため、設計書上で両系統のBGPピア設定を必須化する

BGPパラメータシートの必須項目

BGPピアリングを確立するための設計シートです。

パラメータ名	オンプレミス側ルータ	クラウド側 (AWS DXGW / Azure ER)	備考
BGP自ASN	`65010` (Private ASN)	`64512` (AWS) / `12076` (Azure)	自社ASNは予約番号を避けて選定
BGPピアIP	`169.254.100.1/30`	`169.254.100.2/30`	/30のポイントツーポイント接続
BGP認証キー (MD5)	`Secr3t_Bgp_Key!2026`	`Secr3t_Bgp_Key!2026`	平文での設計書記載厳禁（別紙管理）
Hold Time / Keepalive	`90秒 / 30秒`	`90秒 / 30秒`	デフォルト値で一致させる
広報プレフィックス	`10.10.0.0/16` (集約ルート)	`10.100.0.0/16`, `10.101.0.0/16`	細かいサブネットではなく集約ルートを広報

アクティブ／スタンバイの経路制御設計（非対称ルーティング防止）

回線冗長化において、「メイン回線障害時のみバックアップ回線に迂回させる」アクティブ／スタンバイ設計を行う場合、以下のBGP属性を設計書に明記します。

① オンプレミス ➔ クラウド（送信トラフィックの制御）

使用する属性: Local Preference（ローカルプレファレンス）
設計内容: オンプレミス側ルータのBGPインバウンドポリシーにて設定。
- メイン回線から受信したクラウド経路：Local Preference = 200
- バックアップ回線から受信したクラウド経路：Local Preference = 100
- ➔ 数値が大きい「メイン回線」が優先的にアウトバウンド経路として選択される。

② クラウド ➔ オンプレミス（受信トラフィックの制御）

使用する属性: AS-Path Prepending（ASパスプレペンド）
設計内容: オンプレミス側ルータからクラウドへ経路をアドバタイズする際、バックアップ回線側に自ASNを複数個付加して広報する。
- メイン回線から広報するオンプレ経路：AS-Path: 65010
- バックアップ回線から広報するオンプレ経路：AS-Path: 65010 65010 65010（自ASNを2つ重ねて長大に見せる）
- ➔ クラウド側ルータは「AS-Path長が短いメイン回線」を優先してパケットを返送する。

この両方の制御を設計書に盛り込むことで、行きの通信と戻りの通信が同じ回線を通り、オンプレ側FWでの通信断を完全に回避できます。

BFD（Bidirectional Forwarding Detection）による高速フェイルオーバー

BGPの標準キープアライブタイマー（30秒間隔、Hold Time 90秒）に依存していると、物理回線の途中障害やサイレント障害が発生した際、経路の切り替えに最長90秒〜3分程度のパケットロスが発生します。

業務システムでこのダウンタイムが許容できない場合、BFD（Bidirectional Forwarding Detection）の有効化を設計書に記載します。

送信間隔（Transmit Interval）: 300 ms
受信間隔（Receive Interval）: 300 ms
検出倍数（Detect Multiplier）: 3
➔ 障害発生から 約900ミリ秒（1秒未満） で障害を検知し、瞬時にバックアップ回線へルーティングを切り替えます。

【実務テンプレート】ハイブリッド接続パラメータシートの構成

実務でハイブリッドクラウドのネットワーク設計書をExcelやスプレッドシートで納品する場合、以下の5シート構成で作成するとレビュー・運用保守が極めてスムーズになります。

IaC（Terraform / CloudFormation）連携を見据えた命名規則

現代のクラウドインフラ設計書は、パラメータシートからそのままTerraform（tfvars）やCloudFormationのパラメータに変数として展開できることが求められます。

設計書のパラメータシートに以下の命名規則ルールを適用しておくと、構築自動化の工数を劇的に削減できます。

リソース命名フォーマット:[PJ名]-[環境]-[リージョン]-[リソース種別]-[識別子]
- 例: prj-prod-tyo-vpc-app（本番業務VPC）
- 例: prj-prod-tyo-snet-pub-1a（パブリックサブネット）
- 例: prj-prod-tyo-tgw-rtb-prod（本番用TGWルートテーブル）
必須タグ設計:すべてのネットワークリソースに Environment（Prod/Stg/Dev）、Project、Owner、ManagedBy（Terraform）のタグ定義を設計書上で必須化します。

まとめと次のステップ（設計書シリーズへの展開）

ハイブリッドクラウドのネットワーク設計は、オンプレミスの堅牢なIP管理・物理要件と、クラウドの柔軟で動的なSDNアーキテクチャを結びつける、インフラアーキテクトの腕が最も試される領域です。

7-1. ハイブリッドクラウドネットワーク設計納品前セルフチェックシート

設計レビューの前に、以下の必須項目が設計書に網羅されているか最終確認を行ってください。

カテゴリ	チェック項目	確認
アドレッシング	オンプレミスとクラウド（AWS/Azure）でCIDRの重複が絶対に存在しないか	□
アドレッシング	各サブネットでクラウド特有の「予約IP（5個）」を差し引いてIP数が計算されているか	□
アドレッシング	サブネットサイズが極小（/28など）になっておらず、拡張余力（/26や/24）があるか	□
ルーティング	TGW/vWANのルートテーブルを環境別（本番・検証・共通）に分離定義しているか	□
クォータ	オンプレミス側エッジルータで広報ルートを集約し、DX/ERの経路数上限を超えないか	□
専用線接続	回線全体のMTUポリシー（Jumbo Frame vs 1500）が全機器で整合しているか	□
BGP冗長化	Local PreferenceとAS-Path Prependingで、行きと戻りの優先回線が完全一致しているか	□
障害切替	BGPタイマー遅延を回避するためのBFDパラメータ（300ms×3等）が定義されているか	□