オンプレミスのネットワーク設計経験が長いほど、YPADやMOSSのアドレス設計をそのままAzureに持ち込みたくなる。しかし、AzureのVNet設計はNSG・ルートテーブル・Private Endpointの仕組みと密接に絡み合っており、オンプレ流の設計思想とは根本的に異なる。
この記事では、ypad・moss・azureの違いをAzure CLIの実行例を交えて解説し、移行時のネットワーク選定で失敗しないための判断軸を示す。
この記事のポイント
・ypad・moss・azureの違いはサブネット分割の粒度と設計思想にある
・Azure CLIのaz network vnet subnet listでサブネット設計を即確認できる
・新規Azure VNetはCAFハブアンドスポーク設計が推奨。ypad/moss設計は持ち込まない
・GatewaySubnetとAzureBastionSubnetは予約名のため命名ルールを変更できない
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ypad・moss・azureの違いが問題になる場面
オンプレミスのLinuxサーバーをAzureへ移行するとき、ネットワーク設計で最初につまずくのがIPアドレス設計の考え方のギャップだ。YPAD（段階的プレフィックス割り当て設計）は、大規模なオンプレミス環境でIPアドレスをロケーション・用途・環境の3階層で管理する手法で、日本のエンタープライズで広く使われてきた。MOSS（旧来のフラットサブネット設計）は、Microsoft Office SharePoint Server（MOSS 2007）時代の展開で普及した、機能単位よりも物理サーバーの配置に基づいたサブネット設計を指す。
どちらもAzureのVNetに持ち込むことは技術的には可能だ。しかし、AzureのNSGやPrivate Endpointはサブネット単位で機能する設計になっており、ypadやmossの設計思想と噛み合わない点がある。後から再設計を余儀なくされるケースが多いのが現実だ。
ypad・moss・azure：3つのアプローチを整理する
1. YPAD（段階的プレフィックス割り当て設計）
YPADはIPアドレス空間をロケーション・用途・環境の3階層で段階的に割り当てる設計手法だ。たとえば次のような構成になる。・1段目（ロケーション）：10.0.0.0/8 → 東京拠点
・2段目（用途）：10.10.0.0/16 → 本社ネットワーク
・3段目（環境）：10.10.1.0/24 → 本番サーバーセグメント
大規模な物理インフラでは管理しやすい半面、Azure VNetに適用するとアドレス空間が広すぎてNSGでの細かい制御が難しくなる。また、複数のVNetをピアリングする際にアドレス空間が重複しやすく、スケールアウトの妨げになる。
2. MOSS（フラット型サブネット設計）
MOSSは、Microsoft Office SharePoint Server時代のオンプレ展開で広まったフラット型サブネット設計だ。機能的な分離よりも物理サーバーの配置に基づいて/24から/26のサブネットを多数作成する。・フロントエンドサーバー：192.168.1.0/24
・バックエンドサーバー：192.168.2.0/24
・データベースサーバー：192.168.3.0/24
Azure VNetに持ち込んだ場合、サブネット数が膨大になりNSGのルール管理が煩雑になる。AzureのApp Service VNet IntegrationやPrivate Endpointはサブネット単位でデリゲーション（委任）が必要であり、サブネットを使い回せないため、MOSS型の設計では後から詰まりやすい。
3. Azureネイティブ設計（CAFハブアンドスポーク）
Azure CAF（Cloud Adoption Framework）が推奨するのはハブアンドスポーク型のVNet設計だ。ypad・mossとは考え方が異なる主なポイントを整理する。・ハブVNet（VPN/ExpressRoute・DNS・Azure Firewallを集約）：10.0.0.0/16
・スポークVNet-Webアプリ：10.1.0.0/16
・スポークVNet-データベース：10.2.0.0/16
各スポークVNet内のサブネット例：
・snet-app（アプリケーション層）：10.1.1.0/24
・snet-db（データベース層）：10.1.2.0/24
・GatewaySubnet（VPNゲートウェイ専用・名前変更不可）：10.1.255.0/27
・AzureBastionSubnet（Bastion専用・名前変更不可）：10.1.254.0/26
GatewaySubnetとAzureBastionSubnetはAzureが予約した名前のため、MOSS型の命名規則（subnet-vpn-01等）で作成しようとするとAzureのサービスが使えない。
ypad・moss・azureの違いを一覧比較
| 比較項目 | YPAD | MOSS | Azureネイティブ |
|---|---|---|---|
| アドレス空間の考え方 | 階層型（3段階で割り当て） | フラット型（機能別/24を多数作成） | ハブスポーク型（VNet単位で分離） |
| サブネット分割の粒度 | 粗め（/16以上が多い） | 細かめ（/24～/26を多数作成） | 用途別（役割ごとに/24を割り当て） |
| NSG制御のしやすさ | 低い（アドレス範囲が広すぎる） | 低い（NSGルール数が過多になる） | 高い（サブネット単位で最小権限制御） |
| Azure PaaS機能との親和性 | 低い | 低い（デリゲーション設計が難しい） | 高い（Private Endpoint・VNet統合に最適） |
| VNetピアリング時のスケーラビリティ | 低い（アドレス重複が起きやすい） | 中程度 | 高い（スポークVNetを独立アドレスで分割） |
Azure CLIでypad・moss・azureの設計を確認する
実行環境：RHEL 9.4 / Ubuntu 24.04 LTS（Azure CLI 2.65.0で動作確認済み）既存VNetのネットワーク設計がypad・moss・azureのどのパターンに近いかはAzure CLIで確認できる。
1. VNetとアドレス空間を一覧確認する
まずサブスクリプション内の全VNetを確認する。# サブスクリプション内の全VNetをテーブル形式で表示 az network vnet list --output table
Name ResourceGroup Location AddressSpace Subnets -------------- ------------------ ---------- ------------------ ------- vnet-hub rg-infra-prod japaneast 10.0.0.0/16 3 vnet-spoke-web rg-webapp-prod japaneast 10.1.0.0/16 2 vnet-spoke-db rg-database-prod japaneast 10.2.0.0/16 2
2. サブネットの割り当てを確認する
特定のVNetのサブネット構成を確認するには以下を実行する。# サブネット一覧の確認 az network vnet subnet list \ --resource-group rg-infra-prod \ --vnet-name vnet-hub \ --output table
Name AddressPrefix PrivateEndpointNetworkPolicies --------------------- --------------- -------------------------------- GatewaySubnet 10.0.255.0/27 Disabled AzureBastionSubnet 10.0.254.0/26 Disabled snet-shared-services 10.0.0.0/24 Enabled
3. NSGとルートテーブルの紐付けを確認する
NSGの割り当て状況とルールを確認するには次のコマンドを使う。# NSGルール一覧の確認 az network nsg rule list \ --resource-group rg-infra-prod \ --nsg-name nsg-snet-shared \ --output table
Name Priority Direction Access Protocol SourceAddressPrefix DestinationAddressPrefix --------------------------- -------- --------- ------ -------- -------------------- ------------------------ allow-ssh-from-bastion 100 Inbound Allow Tcp 10.0.254.0/26 * allow-https-outbound 200 Outbound Allow Tcp * Internet deny-all-inbound 4096 Inbound Deny * * *
ネットワーク選定の実践的な判断軸
ypad・moss・azureの違いを理解した上で、どのアプローチを選ぶべきかの判断軸を整理する。・新規Azure VNet構築の場合：Azureネイティブ（CAFハブアンドスポーク）一択。AzureのPaaS機能（App Service、Azure SQL、Container Instancesなど）はサブネット設計が前提になるため、最初からAzure推奨設計で構築することでデリゲーションの制約を回避できる
・YPAD型設計からの移行の場合：まずVNetのアドレス空間を/16レベルに絞り込む。スポークVNetを独立したアドレスで分割してから移行することで、将来のVNetピアリング時のアドレス重複問題を防げる
・MOSS型設計からの移行の場合：サブネット数を用途別（app/db/gateway/bastion）に統合する。/24単位の多数サブネットをAzureに持ち込むとNSGルール数が膨大になるため、移行前にサブネット整理を先に行うこと
Azureのネットワーク設計を体系的に習得したい場合は、Azure実践ハンズオンでVNet設計からNSG・Private Endpointまでを一連の流れで学べる。
よくある設計ミスとトラブル対処
1. GatewaySubnetの名前を変更してしまった
MOSS型の命名規則に合わせようとして「GatewaySubnet」を「subnet-vpn」などに変更すると、Azure VPN GatewayやExpressRouteゲートウェイが作成できなくなる。GatewaySubnetはAzureが予約する名前のため変更不可だ。対処法はサブネットを削除して正しい名前（GatewaySubnet）で再作成することになる。既存リソースがある場合は先にリソースを削除する必要があるため、本番環境での修正は計画的に行うこと。
2. アドレス空間が重複してVNetピアリングが失敗する
YPAD型の10.0.0.0/8のような広いアドレス空間を複数のVNetで使いまわしていると、VNetピアリング時にアドレス空間の重複エラーになる。Azure CLIで確認するには次のコマンドを使う。# VNetピアリングの状態確認 az network vnet peering list \ --resource-group rg-infra-prod \ --vnet-name vnet-hub \ --output table
Name PeeringState ProvisioningState RemoteVnet ---------------------- -------------- ------------------- ------------------ peer-hub-to-spoke-web Connected Succeeded vnet-spoke-web peer-hub-to-spoke-db Disconnected Failed vnet-spoke-db
3. サブネットにNSGが設定されていない（MOSS型移行後）
MOSS型のオンプレ設計ではファイアウォールが境界で一括制御するケースが多く、サブネット個別のNSGを設定しないままAzureに移行してしまうことがある。AzureではNSG未割り当てのサブネットへの通信はデフォルト動作に依存するため、セキュリティ設計上NSGは必ずサブネットに割り当てること。まとめ
ypad・moss・azureの違いとAzure CLIによる確認コマンドをまとめる。| やりたいこと | コマンド |
|---|---|
| VNet一覧とアドレス空間を確認する | az network vnet list --output table |
| サブネット一覧を確認する | az network vnet subnet list --resource-group RG名 --vnet-name VNet名 --output table |
| NSGルール一覧を確認する | az network nsg rule list --resource-group RG名 --nsg-name NSG名 --output table |
| VNetピアリング状態を確認する | az network vnet peering list --resource-group RG名 --vnet-name VNet名 --output table |
＞＞ Azure実践ハンズオン講座の詳細はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：azure sharepoint違いをMicrosoft 365構成図で整理｜ファイル管理基盤の選定と移行手順
- この記事の属するカテゴリ：Azureへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます