1.はじめに
オンプレでネットワークに関わってきた方は、Azure ネットワークに触れたときに「今の知識ってどこまで通用するんだろう？」と感じたことはありませんか？
私自身も最初は戸惑いましたが、実際にはレイヤーの見え方が変わっただけで、身につけた知識は十分活かせることに気づきました。
以前の記事では、Azure ネットワーク全体を「町」に例えて整理しています。
今回はその一歩先として、オンプレのレイヤー知識を Azure でどう読み替えるかを整理します。
本記事は、オンプレ経験者の方に向けて書いています。
- ネットワーク機器やレイヤーの違いは理解している
- でも Azure でその理解をどう活用すればよいか分からない…
L1〜L7 の視点で整理することで、「知識がどこまで通用するか」を確認しつつ、オンプレで培った知識が、Azure でも確かに活きることを確認していきます。
本記事のレイヤー表記（L1〜L7）は OSI 参照モデルを基準としています。
図や説明の都合上、厳密さよりも理解しやすさを優先している点はご了承ください。
Azure を例にしていますが、レイヤーを軸にした整理の考え方は、他クラウド（例：AWS）でも共通して活用できます。
2.本記事で扱う構成と読み進め方
まずは、オンプレでよくあるネットワーク構成を出発点に見ていきます。
2-1.ベースとなるオンプレ構成
本記事の共通前提となるオンプレ構成図です。
実環境を忠実に再現することが目的ではなく、オンプレ環境で一般的に利用されるネットワーク機器の「レイヤー」と「役割」を整理することを目的としています。
図はネットワークの役割に焦点を当てるため、サーバの詳細や説明は省略しています。
各機器の関連レイヤーと役割は次の通りです。
以降、本文中の一部のキーワードには関連情報へのリンクを付けています。
用語やサービスの概要を確認したい場合にご活用ください。
必要に応じて生成 AI で要約すると、理解しやすくなることもあります。
| 機器 | 関連レイヤー | 主な役割 | 代表的なキーワード |
|---|---|---|---|
| Edge Router （エッジルータ） |
L3 | 外部ネットワークとの接続 | 静的ルーティング※、動的ルーティング※（BGP）、NAT |
| FW （ファイアウォール） |
L3・L4・L7 | ネットワーク境界の通信制御 | パケットフィルタリング（静的）、ステートフルインスペクション（動的） |
| LB （ロードバランサ） |
L4・L7 | 通信の振り分け | L4・L7 ロードバランシング |
| L3SW （L3 スイッチ） |
L3 | IP ルーティング | VLAN 間ルーティング、静的ルーティング、動的ルーティング（OSPF） |
| L2SW （L2 スイッチ） |
L2 | 通信範囲の分離 | VLAN |
※ スタティックルーティング、ダイナミックルーティングと呼ばれることもありますが、本記事では表記を統一しています。
2-2.読み進め方
この構成図をもとに、章が進むごとに図を少しずつ変形させていきます。
特に注目してほしいのは次の2点です。
- L1・L2：物理機器は見えず、利用者が直接操作することもできない
- L3・L4・L7：物理機器そのものは見えないが、機能（役割）はサービスとして利用できる
この違いを意識しながら図の変化を追うことで、「オンプレでのレイヤー知識が Azure でどのように活きるのか」が見えてきます。
3.L1 / L2 の領域
ここからは、オンプレでの各レイヤーの役割が、Azure ではどのように扱われるのかを見ていきます。
まずは、ネットワークの土台となる L1 / L2 です。
3-1.オンプレでの L1 / L2
現在の構成図をあらためて確認します。
オンプレでは、L1 / L2 がネットワークの土台を支え、ネットワーク基盤そのものを、自分たちで設計・構築・維持していたという感覚があるかと思います。
代表的な技術要素の一例は次の通りです。
| レイヤー | 技術要素 | 主な役割 | オンプレで意識するポイント |
|---|---|---|---|
| L1 | 物理媒体・インターフェース （物理ケーブル・ポート速度） |
信号の伝達 | 伝送方式、帯域設計 |
| L2 | スタック | 複数スイッチの統合 | 冗長化（機器）、管理一体化 |
| L2 | LAG | リンク集約 | 冗長化（リンク）、帯域拡大 |
| L2 | STP | ループ防止 | トポロジ制御 |
| L2 | VLAN | 論理分割 | 到達範囲制御 |
スタック、LAG、STP などは L3 機器でも利用しますが、本記事では説明の構成を考慮し、L2 で整理しています。
3-2.クラウド（Azure）での L1 / L2
クラウドでも L1 / L2 は確かに存在しています。
大きな違いは「利用者が操作しない」という点です。
直接操作や設定を行わないため、これらのレイヤーは利用者の構成図上では“見えない存在”になります。
図のグレー部分が、その領域です。
物理機器やケーブル配線は、クラウド事業者が管理するデータセンター内に実在し、その内部基盤として組み込まれています。
これらは利用者が直接設計や運用する対象ではなく、あらかじめ整備された基盤として提供されています。
そのため、利用者が考慮対象とするのは主に L3 以上です。
利用者の視点で見ると、構成図は次の通りです。
Azure のネットワーク基盤の内部構造をより詳しく知りたい場合は、こちらの方の記事が参考になります。
利用者からは見えないバックボーンや内部基盤について理解を深めることができます。
オンプレ経験者にとっては、L1 / L2 の機器が見えなくなる（構成図に表現されない）ことにかなりの違和感があるかもしれません。
利用者には「見えない存在」というのが、オンプレで理解していた構成と Azure の構成をうまく対応づけられない理由の一つです。
本文で触れた通り、クラウドでは L1 / L2 は通常利用者が操作しません。
ただし、ハイブリッドクラウドで L2 延伸を行う構成では、例外的に L2 を考慮する場面もあるため注意が必要です。
4.L3 の領域
L3 の本質は、IP アドレスを使って「この通信を、どのネットワークへ届けるか」を決めることです。
IP アドレスで宛先を識別し、ルーティングで経路を決める。
この仕組み自体は、オンプレでもクラウドでも変わりません。
ここではまず、オンプレでの L3 を整理し、そのあと Azure に置き換えていきます。
4-1.オンプレでの L3
まず、これまで整理してきた構成図を確認します。
オンプレでは、ルータや L3 スイッチといった物理機器が L3 での役割を担っていました。
L3 の本質は大きく2つです。
- IP アドレス：通信における送信元・宛先を識別する
- ルーティング：宛先ネットワークへの到達経路を決める
もう少し整理すると、次のようになります。
| 観点 | 本質 | 内容 |
|---|---|---|
| アドレス空間の定義 | IP アドレス | 利用する IP アドレス範囲を決める |
| ネットワークの論理分割 | IP アドレス | 用途ごとに到達範囲（セグメント）を分ける |
| セグメント間接続 | ルーティング | 内部ネットワークや VLAN 間での経路を決める |
| 外部ネットワーク接続 | ルーティング | 他拠点やインターネット宛の経路を決める |
ここまでの内容は、オンプレでネットワーク設計や構築などをしてきた方にとっては特別な話ではないはずです。
4-2.クラウド（Azure）での L3
クラウドでは、ルータや L3 スイッチといった物理機器を直接操作することはありません。
その代わり、オンプレで機器が担っていた L3 の役割は、サービスとして提供されます。
まず、オンプレ構成のうち「物理機器として存在していた部分」をグレーで表現します。
次に、オンプレで担っていた L3 の役割を、Azure のサービス名で置き換えます。
ここでは、L3 の本質である「IP アドレス」と「ルーティング」という軸で、オンプレの構成を Azure のサービスへと読み替えます。
| 観点 | 本質 | オンプレでの主な対象機器 | Azure でのサービス例 |
|---|---|---|---|
| アドレス空間の定義 | IP アドレス | - （管理表などで定義） |
Azure VNet |
| ネットワークの論理分割 | IP アドレス | L3 スイッチ・ルータ | Subnet |
| 経路制御 | ルーティング | L3 スイッチ・ルータ | システムルート、UDR |
| 外部ネットワーク接続 | ルーティング | L3 スイッチ・ルータ | ・BGP（Azure VPN Gateway・Azure ExpressRoute）※1 ・NAT（Azure NAT Gateway）※2 |
※1 外部ネットワーク接続については、「付録1：拠点接続・ハイブリッド構成で活きる」で触れています。
※2 Azure NAT Gateway は送信元アドレス変換を行うサービスで、経路決定（ルーティング）とは異なります。
ポート変換も考慮する場合は L4 の役割も関わりますが、本記事では L3 の外部接続補助として紹介しています。
ここでは Azure サービス名を例として挙げていますが、詳細な解説は行いません。
目的は、L3 の役割のイメージを掴むことです。
サービスの仕様や操作方法については、別途 Azure に特化した学習が必要です。
学習方法については、以前まとめた記事をご参照ください。
オンプレでは物理機器を用意することで L3 を実現していました。
Azure ではサービスを組み合わせて実現します。
Azure 独自の設計思想や制約はありますが、IP アドレスとルーティングという本質は変わりません。
オンプレで培った理解は、そのまま各工程での判断の土台になります。
5.L4 / L7 の領域
L4 / L7 の本質は、L3 が IP アドレスを使って「どこへ届けるか」を決めるのに対し、その通信を「どう扱うか」を決めることです。
たとえば、次のような判断です。
- 複数サーバーのどこへ振り分けるか
- 通信を通すのか、通さないのか
この役割自体は、オンプレでもクラウドでも変わりません。
ここではまず、オンプレでの L4 / L7 を整理し、そのあと Azure に置き換えていきます。
5-1.オンプレでの L4 / L7
まず、オンプレ構成の中で L4 / L7 を担っていた部分を確認します。
本記事では、L4 / L7 の本質を大きく2つとします。
- 負荷分散：複数のサーバーへ通信を振り分ける
- 通信制御：通信を許可・拒否したり、条件に応じて扱いを変える
もう少し具体化すると、次のようになります。
| 観点 | 本質 | 内容 |
|---|---|---|
| 負荷分散 | 通信の分散 | TCP / UDP（L4）や HTTP / HTTPS（L7）などに基づいて振り分ける |
| 通信制御 | トラフィック制御 | IP アドレス（L3）・ポート（L4）・FQDN / URL（L7）などに基づいて通信を制御する |
オンプレでは、これらを物理機器がその役割を担っていました。
5-2.クラウド（Azure）での L4 / L7
クラウドでは、ロードバランサやファイアウォールといった物理機器を直接操作することはありません。
しかし、それらが担っていた役割は、サービスとして提供されています。
これまでと同様に、オンプレで機器として見えていた部分をグレーで表現します。
次に、Azure のサービス名で置き換えます。
L4 / L7 の本質である「負荷分散」と「通信制御」という軸で、オンプレの構成を Azure のサービスへと読み替えます。
| 観点 | 本質 | オンプレでの主な対象機器 | Azure サービス例 |
|---|---|---|---|
| 負荷分散 （L4） |
TCP / UDP レベルでの分散 | ロードバランサ | Azure Load Balancer |
| 負荷分散 （L7） |
HTTP / HTTPS レベルでの分散 | ロードバランサ | Azure Application Gateway |
| 通信制御 （L3 / L4 / L7） |
IPアドレス、ポート番号、FQDN / URL 単位の制御 | ファイアウォール | Azure NSG / Azure Firewall |
オンプレでは機器の設定によって L4 / L7 の役割を実現していましたが、Azure ではそれらの役割をサービスとして選択し、構成します。
「どの単位で振り分けるのか」「どこまで制御するのか」という整理ができていれば、実装の形が変わっても迷うことはありません。
通信制御（クラウドセキュリティのネットワークセキュリティ分野に該当）におけるレイヤー単位のサービスの違いについては、以下の記事で整理しています。
- Azure では、DMZ / 内部 LAN のような明確なゾーン構造は薄くなり、複数 VNet を Azure Firewall（境界制御機器）で制御する構成が基本になります。
- オンプレ機器の役割がそのまま Azure に存在するわけではなく、提供形態や制約が異なるため、要件に応じたサービス選定と機能可否の確認が必要です。
付録.オンプレネットワーク知識は特にどこで活きる？
本記事では、オンプレのレイヤー知識を Azure でどう読み替えるかを整理しました。
では、この知識は実務のどの場面で活きるのでしょうか。
ここからは筆者の実務経験をもとにした内容です。
環境や体制によって状況は異なるため、一つの事例としてお読みいただければ幸いです
付録1.拠点接続・ハイブリッド構成で活きる
付録1.拠点接続・ハイブリッド構成で活きる
クラウド導入でも、オンプレ環境を完全に置き換えるとは限りません。
- オンプレ拠点との接続
- 他社データセンターとの接続
- 段階的なクラウド移行
このような構成では、オンプレとクラウドをまたぐ考慮が必要になります。
代表的な技術要素の一例は次の通りです。
| レイヤー | 接続方式 | 代表的なキーワード | 用途 |
|---|---|---|---|
| L3 | 専用線※1 | - | 拠点間接続（専用の閉域） |
| L3 | VPN（IP-VPN） | MPLS | 拠点間接続（キャリア網の閉域） |
| L3 | VPN（インターネットVPN - Site-to-Site※2） | IPsec | 拠点間接続（インターネット） |
| L3 | VPN（インターネットVPN - Point-to-Site※2） | IPsec | 拠点-端末間接続（インターネット） |
※1 本記事での"専用線"は、クラウドの閉域接続サービス（例：Azure ExpressRoute）を前提に、レイヤー3として整理しています。
※2 サイト間 VPN や S2S、リモートアクセス VPN や P2S と呼ばれることもありますが、本記事では表記を統一しています。
クラウドでは物理機器が見えず、従来 L3 スイッチや Edge Router が担っていた役割は、サービスとして提供されます（図のグレー部分）。
今回のように外部接続に必要な機能は、ゲートウェイサービス（Azure VPN Gateway や Azure ExpressRoute など）で実現します。
実務では、拠点間の接続方式や利用する技術の考え方は、Azure であっても大きくは変わりません。
閉域網や VPN の前提はオンプレと共通しており、違いは主にクラウドサービス側の制約や仕様にあります。
筆者が初めて Azure を触った際も、接続方式やルーティングの考え方はオンプレの経験がそのまま活きる領域だと感じました。
オンプレで培ったレイヤー理解は、Azure でも確かな土台になります。
付録2.技術の翻訳で活きる
付録2.技術の翻訳で活きる
オンプレ知識は、移行プロジェクトやハイブリッド構成での構成検討において特に活きます。
オンプレとクラウドの両方を理解していることで、それぞれの前提を踏まえた「翻訳」ができるようになります。
オンプレ担当者の視点
オンプレ側のネットワーク担当者は、物理/論理構成や機器単位で構成を考えることが多い印象です。
- L3 スイッチやエッジルータの構成・挙動を理解している
- 閉域網接続や BGP の動作イメージを持っている
一方で、クラウド特有のサービス構成には馴染みがなく、サービス名だけでは「どのサービスが何をしているのか」というイメージが掴みにくい場合があります。
クラウド担当者の視点
クラウド担当者は、サービス単位・機能単位で構成を考えることが多い印象です。
- 内部構成は抽象化され、提供機能やサービス名で説明する
- オンプレ側の物理構成や接続機器の詳細までは意識しないことがある
両方を知ることの強み
両者の前提を理解していれば、同じ内容でも相手に合わせて言葉を変えて説明できます。
例えば、オンプレと Azure を閉域網（例：ExpressRoute）で接続する場合でも
1.オンプレ担当者向け
「オンプレ側のルータとサービス側のルータ間で BGP により経路交換します」と説明する
2.クラウド担当者向け
「オンプレ機器と ExpressRoute を接続し、相互接続します」と説明する
このように技術を適切に翻訳することで、説明の行き違いや構成の誤解を減らせます。
クラウドでは物理機器が見えにくくなりますが、ネットワークの原理そのものは変わりません。
オンプレで培った知識は、クラウド時代においても“橋渡し役”として価値を持ち続けます。
6.おわりに
本記事では、オンプレのネットワーク構成をベースに、Azure における各レイヤーの役割を整理しました。
- L1 / L2：Azure では利用者からは物理機器が見えず操作できないが、基盤として存在している
- L3 / L4 / L7：物理機器そのものは見えないが、機能（役割）はサービスとして利用できる
オンプレで培ったネットワーク知識は、「どこへ届けるのか」「どう扱うのか」という視点で捉え直すことで、Azure にも応用できます。
Azure では物理機器を意識する必要はありませんが、レイヤーごとの役割を理解しておくことで、サービス選択や設計判断、関係者間の認識合わせがよりスムーズになります。
本記事が、オンプレ経験者の方にとって、Azure でも知識を活かせると感じるきっかけになれば幸いです。
ここまで読んでいただき、ありがとうございました。
We Are Hiring!