Azure仮想ネットワーク(VNet)とは？基本から使い方、接続方法まで解説

はい、承知いたしました。Azure仮想ネットワーク(VNet)について、基本から使い方、接続方法までを網羅した詳細な解説記事を作成します。

Azure仮想ネットワーク(VNet)とは？基本から使い方、接続方法まで徹底解説

はじめに

今日のビジネス環境において、クラウドコンピューティングはもはや単なる選択肢ではなく、DX（デジタルトランスフォーメーション）を推進するための必須の基盤となっています。その中でも、Microsoft Azureは、仮想マシン(VM)からAI、IoTまで、幅広いサービスを提供し、多くの企業で利用されています。しかし、これらのクラウドサービスを安全かつ効率的に利用するためには、その根底にある「ネットワーク」を深く理解することが不可欠です。

Azureにおけるネットワークの根幹をなすのが「Azure仮想ネットワーク (Azure Virtual Network、以下VNet)」です。VNetは、Azure上に構築される、お客様専用のプライベートなネットワーク空間です。これは、従来のオンプレミス環境で構築してきた自社のデータセンターネットワークを、クラウド上で論理的に再現したものと考えることができます。

VNetを正しく設計し、活用することで、リソースの分離、強固なセキュリティの実現、そしてオンプレミス環境や他のクラウドサービスとのシームレスな接続性が得られます。逆に、VNetの理解が不十分なままAzureを使い始めると、セキュリティリスクの増大や、将来的なシステム拡張の妨げになる可能性があります。

この記事では、Azureをこれから本格的に活用しようと考えているインフラエンジニアや、クラウドに興味を持つ開発者の方々を対象に、以下の内容を約5000語にわたって徹底的に解説します。

VNetの基本概念: VNetとは何か、どのような構成要素で成り立っているのか。
VNetの作成と基本的な使い方: Azure Portalを使ったVNetの作成手順と、VMのデプロイ。
VNetのセキュリティ: ネットワークセキュリティグループ(NSG)やAzure Firewallを使ったセキュリティ強化策。
VNetの接続: VNet同士の接続や、オンプレミス環境とのハイブリッド接続方法。
VNetとAzureサービスの統合: PaaSサービスとVNetを安全に連携させる方法。
VNetの設計とベストプラクティス: 信頼性と拡張性の高いネットワークを構築するための設計パターン。

この記事を読み終える頃には、あなたはAzure VNetの全体像を把握し、自信を持ってAzureのネットワーク設計・構築・運用に取り組めるようになっているでしょう。それでは、Azureネットワークの旅を始めましょう。

第1章: Azure仮想ネットワーク(VNet)の基本

まず、VNetがどのようなもので、どのような要素から構成されているのか、その基本的な概念を理解することから始めます。

VNetとは何か？

VNetは、Azureクラウド内にお客様専用に確保された、論理的に分離されたネットワーク空間です。この「分離」がVNetの最も重要な特性です。デフォルトでは、あるお客様が作成したVNetは、他のお客様のVNetから完全に隔離されています。これにより、あたかも自社専用のデータセンターを持っているかのようなプライベートな環境をクラウド上に実現できます。

オンプレミスネットワークとのアナロジー

VNetを理解する上で、オンプレミスの物理ネットワークと比較すると分かりやすいでしょう。

オンプレミス環境	Azure VNet 環境	説明
データセンター	Azure リージョン	VNetがデプロイされる物理的な場所。
ネットワーク全体	仮想ネットワーク (VNet)	組織のネットワーク境界全体。
サブネット/VLAN	サブネット (Subnet)	ネットワークを機能ごと（Web層、App層など）に分割する単位。
ルーター/スイッチ	システムルート (System Route)	VNet内のトラフィックを自動的にルーティングする仕組み。
ファイアウォール/ACL	NSG / Azure Firewall	ネットワークトラフィックを制御・フィルタリングする仕組み。

このように、VNetはオンプレミスで培われてきたネットワークの概念をクラウド上でソフトウェアとして実装したもの（Software Defined Network – SDN）と捉えることができます。物理的な機器の購入や設定は不要で、数クリックまたは数行のコードで、柔軟かつスケーラブルなネットワークを構築できるのが大きな利点です。

VNetの主な役割とメリット

分離性 (Isolation): VNet内のリソースは、デフォルトでインターネットから直接アクセスできません。また、VNet単位、サブネット単位でリソースをグループ化し、それぞれに異なるセキュリティポリシーを適用することで、多層的な防御を実現し、ワークロードを安全に分離できます。
セキュリティ (Security): 後述するネットワークセキュリティグループ(NSG)やAzure Firewallを利用して、仮想マシンへのインバウンド/アウトバウンドのトラフィックをきめ細かく制御できます。これにより、不正なアクセスからリソースを保護します。
接続性 (Connectivity): VNet内のAzureリソース（VM、データベースなど）は、相互にプライベートIPアドレスで通信できます。さらに、VNet同士の接続、オンプレミスネットワークとのハイブリッド接続、インターネットとの安全な接続など、様々な接続オプションが提供されています。
スケーラビリティ (Scalability): ビジネスの成長に合わせて、VNetのアドレス空間やサブネットを柔軟に拡張できます。物理的な制約に縛られることなく、需要に応じたネットワーク設計が可能です。

VNetの構成要素

VNetは、いくつかの基本的な構成要素から成り立っています。これらを理解することが、VNet設計の第一歩です。

1. アドレス空間 (Address Space)

VNetを作成する際に、まず「アドレス空間」を定義する必要があります。これは、そのVNet内で使用されるプライベートIPアドレスの範囲を定義するものです。通常、インターネット上でルーティングされないプライベートIPアドレス範囲（RFC 1918で規定）から選択します。

10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
192.168.0.0 – 192.168.255.255 (192.168.0.0/16)

アドレス空間は、CIDR (Classless Inter-Domain Routing) 表記で指定します。例えば、10.1.0.0/16 と指定すると、10.1.0.0 から 10.1.255.255 までの65,536個のIPアドレスがこのVNetのために予約されます。

重要なポイント:
* VNetのアドレス空間は、接続する予定のオンプレミスネットワークや他のVNetのアドレス空間と重複しないように設計する必要があります。重複があると、正常なルーティングができなくなります。
* 将来の拡張を考慮し、少し大きめのアドレス空間を確保しておくことが推奨されます。

2. サブネット (Subnet)

アドレス空間を定義したら、次にそのVNetを1つ以上の「サブネット」に分割します。サブネットは、VNetの大きなアドレス空間を、より管理しやすい小さなセグメントに論理的に分割するものです。

例えば、Webアプリケーションを構築する場合、以下のようにサブネットを分割するのが一般的です。

WebSubnet: Webサーバー（VM）を配置するサブネット。
AppSubnet: アプリケーションサーバーを配置するサブネット。
DbSubnet: データベースサーバーを配置するサブネット。

このようにサブネットを分けることで、各層（Tier）ごとに異なるセキュリティルール（NSG）を適用したり、リソースを整理したりすることが容易になります。

サブネットを作成する際も、VNetのアドレス空間の中から一部をCIDR表記で割り当てます。例えば、10.1.0.0/16 のVNet内に、10.1.1.0/24 (256個のアドレス) をWebSubnetとして割り当てることができます。

Azureが予約するIPアドレス:
各サブネットでは、Azureが内部的に使用するために、先頭から4つと最後の1つ、合計5つのIPアドレスが予約されます。

.0: ネットワークアドレス
.1: デフォルトゲートウェイ用
.2, .3: Azure DNS用
.255 (例: /24の場合): ブロードキャストアドレス

したがって、/24 (256個) のサブネットで実際にリソースに割り当て可能なIPアドレスは 256 - 5 = 251 個となります。この点は、サブネットのサイズを設計する際に考慮する必要があります。

3. リージョン (Region)

VNetは、必ず単一のAzureリージョン（例: 東日本、米国西部など）に属します。あるリージョンで作成したVNetを、別のリージョンにまたがって拡張することはできません。異なるリージョンにあるリソースを接続したい場合は、後述する「VNetピアリング」や「VPNゲートウェイ」といった技術を使用します。

第2章: VNetの作成と基本的な使い方

概念を理解したところで、実際にVNetを作成し、その中に仮想マシン(VM)をデプロイする手順を見ていきましょう。ここでは、最も直感的なAzure Portalを使った方法を解説します。

Azure Portalを使ったVNetの作成手順

Azure Portalへのサインイン:
まず、Azure Portal (https://portal.azure.com/) にサインインします。Azureサブスクリプションが有効になっていることが前提です。
リソースの作成:
ポータルの上部にある検索バーに「仮想ネットワーク」と入力し、表示された「仮想ネットワーク」サービスを選択します。その後、「+ 作成」ボタンをクリックします。
仮想ネットワークの作成ウィザード:
作成ウィザードが開き、いくつかのタブに分かれた設定項目を入力していきます。
- [基本] タブ:
  - サブスクリプション: VNetを作成するサブスクリプションを選択します。
  - リソースグループ: VNetや関連リソースをまとめるためのコンテナです。「新規作成」するか、既存のものを選択します。リソースグループ単位で権限管理や課金管理ができます。（例: RG-VNet-Prod-EastJP）
  - 名前: VNetの名前を入力します。命名規則を決めておくと管理が容易になります。（例: VNet-Prod-EastJP-001）
  - リージョン: VNetをデプロイするリージョンを選択します。（例: 東日本）
- [IPアドレス] タブ:
  - IPv4 アドレス空間: ここでVNetのアドレス空間をCIDR表記で入力します。（例: 10.1.0.0/16）
  - + サブネットの追加: サブネットを定義します。
    - サブネット名: サブネットの名前を入力します。（例: Subnet-Web）
    - サブネットのアドレス範囲: VNetのアドレス空間の中から、このサブネットに割り当てる範囲をCIDRで指定します。（例: 10.1.1.0/24）
  - 必要に応じて、複数のサブネット（Subnet-App, Subnet-DBなど）を同様に追加します。
- [セキュリティ] タブ:
  - Azure Bastion: ブラウザ経由でVMに安全に接続するためのマネージドサービスです。ここでは一旦「無効」のまま進めます。
  - DDoS Protection Standard: 高度なDDoS攻撃からの保護機能です。デフォルトのBasicは無料で有効ですが、Standardは有料です。これも「無効」にします。
  - Azure Firewall: マネージドファイアウォールサービスです。これも後から設定できるため、「無効」にしておきます。
- [タグ] タブ:
  - リソースを識別・整理するためのメタデータです。コスト管理や運用自動化に非常に役立ちます。
  - 例: Name: Environment, Value: Production, Name: CostCenter, Value: 12345
確認および作成:
最後に「確認および作成」タブで設定内容を確認し、問題がなければ「作成」ボタンをクリックします。数分でVNetとサブネットのデプロイが完了します。

仮想マシン(VM)をVNetにデプロイする

VNetという「土地」の準備ができたので、次はその上に「家」である仮想マシン(VM)を建ててみましょう。

VMの作成ウィザードを開始します。（「仮想マシン」サービスから「+ 作成」）
[基本] タブでVMの名前、リージョン、イメージ、サイズなどを選択します。
[ネットワーク] タブが重要です。
- 仮想ネットワーク: 先ほど作成したVNet（例: VNet-Prod-EastJP-001）が自動的に選択されているか確認します。リージョンが同じVNetのみが選択肢に表示されます。
- サブネット: VMを配置したいサブネットを選択します。（例: Subnet-Web）
- パブリック IP: インターネットからこのVMにアクセスする必要がある場合は、パブリックIPアドレスを作成します。テスト目的でない限り、本番環境ではパブリックIPを直接VMに割り当てることは避けるべきです。
- NIC ネットワークセキュリティグループ: ここでNSG（後述）を設定できます。「基本」または「詳細」を選択できます。
残りの設定を完了し、VMを作成します。

作成が完了すると、VMは指定したVNetとサブネット内に配置され、そのサブネットのアドレス範囲からプライベートIPアドレスが自動的に割り当てられます。

VNet内のリソース間の通信

Azureでは、同一VNet内にあるリソースは、サブネットが異なっていても、デフォルトで相互に通信可能です。これは、Azureが内部的に管理している「システムルート」によって、VNet内のすべてのサブネット間のルーティングが自動的に設定されているためです。

例えば、Subnet-Web にあるWebサーバーVM (10.1.1.4) と、Subnet-DB にあるデータベースサーバーVM (10.1.3.4) は、特別な設定をしなくてもプライベートIPアドレスでお互いに通信できます。

このデフォルトの通信を制御し、セキュリティを強化するために使われるのが、次章で解説する「ネットワークセキュリティグループ(NSG)」です。

第3章: VNetのセキュリティを強化する

VNetは分離されたネットワークですが、その内部の通信や、外部との通信をきめ細かく制御することで、初めて安全な環境と言えます。ここではVNetのセキュリティを強化するための主要な機能を解説します。

ネットワークセキュリティグループ (NSG)

NSGは、VNet内のリソースに対するネットワークトラフィックをフィルタリングするための、仮想的なファイアウォールです。ステートフル（一度許可した通信の戻りのパケットは自動的に許可する）なパケットフィルタリング機能を提供します。

適用範囲: NSGは、サブネットまたは個々のネットワークインターフェイス(NIC)、あるいはその両方に適用できます。
- サブネットに適用: そのサブネット内のすべてのリソースにルールが適用されます。
- NICに適用: そのNICが接続されたVMにのみルールが適用されます。
ルール: NSGは「受信セキュリティ規則」と「送信セキュリティ規則」のセットで構成されます。各ルールは以下の要素で定義されます。
- 優先度 (Priority): 100〜4096の数値。小さいほど優先度が高い。
- ソース/宛先 (Source/Destination): IPアドレス範囲(CIDR)、サービスタグ（Internet, VirtualNetworkなど）、またはASG（後述）を指定。
- プロトコル (Protocol): TCP, UDP, ICMP, Any。
- ポート範囲 (Port Range): 80, 443, 22, 3389, * (すべて) など。
- アクション (Action): 許可 (Allow) または拒否 (Deny)。

デフォルトのセキュリティ規則:
NSGには、変更・削除できないデフォルトのルールがいくつか存在します。

AllowVnetInBound: VNet内からの受信トラフィックをすべて許可。
AllowAzureLoadBalancerInBound: Azureロードバランサーからのヘルスプローブを許可。
DenyAllInBound: 上記以外のすべての受信トラフィックを拒否。
AllowVnetOutBound: VNet内への送信トラフィックをすべて許可。
AllowInternetOutBound: インターネットへの送信トラフィックをすべて許可。
DenyAllOutBound: 上記以外のすべての送信トラフィックを拒否。

具体的な設定例:
Webサーバーを配置したサブネット (Subnet-Web) のNSGに、以下のような受信規則を追加します。
* ルール1:
* 優先度: 100
* ソース: Internet (サービスタグ)
* プロトコル: TCP
* ポート範囲: 80, 443
* アクション: Allow
* 目的: インターネットからWebサーバーへのHTTP/HTTPSアクセスを許可する。
* ルール2:
* 優先度: 110
* ソース: (あなたの会社のグローバルIPアドレス)
* プロトコル: TCP
* ポート範囲: 22 (Linux) or 3389 (Windows)
* アクション: Allow
* 目的: 特定の管理拠点からのみSSH/RDPアクセスを許可する。

Application Security Groups (ASG)

アプリケーションの規模が大きくなると、IPアドレスベースでのNSGルール管理は煩雑になります。そこで役立つのがASGです。ASGは、VMなどのリソースをグループ化し、そのグループ名を使ってNSGルールを定義できる機能です。

利用シナリオ:
1. Webサーバー群を asg-web-servers というASGに所属させる。
2. アプリケーションサーバー群を asg-app-servers というASGに所属させる。
3. Subnet-App に適用するNSGで、以下のような受信ルールを定義する。
* ソース: asg-web-servers (ASGを指定)
* 宛先ポート: 8080 (Appサーバーのポート)
* アクション: Allow

これにより、asg-web-servers グループに属するVMからのトラフィックのみを許可できます。VMの追加や削除があっても、ASGのメンバーシップを変更するだけで、NSGルールを書き換える必要がなくなります。

Azure Firewall

NSGがL3/L4（IPアドレス、ポート）レベルのファイアウォールであるのに対し、Azure Firewallは、より高度な機能を提供する、フルマネージドなクラウドネイティブファイアウォールサービスです。

NSGとの主な違い:
* L7 (アプリケーション層) のフィルタリング: FQDN (完全修飾ドメイン名) に基づくトラフィックフィルタリングが可能です。例えば、「特定のVMからは *.github.com へのアクセスのみを許可する」といったルールが設定できます。
* 脅威インテリジェンス: Microsoftの脅威インテリジェンスフィードと連携し、既知の悪意のあるIPアドレスやドメインとの通信を自動的にブロックします。
* 中央集権的な管理: ハブ&スポークモデル（後述）のハブVNetにAzure Firewallを配置し、すべてのスポークVNetやオンプレミスからのトラフィックをここに集約して一元的に検査・管理できます。

Azure Firewallを導入するには、AzureFirewallSubnet という名前の専用サブネットをVNet内に作成し、そこにデプロイする必要があります。

Azure DDoS Protection

Azureはすべてのリソースを基本的なDDoS攻撃から保護する「Basic」プランを無料で提供しています。しかし、より大規模で巧妙な攻撃（L3/L7攻撃）からビジネスクリティカルなアプリケーションを保護するには、有料の「Standard」プランの利用を検討すべきです。

DDoS Protection Standardは、VNet単位で有効化でき、機械学習アルゴリズムを用いてトラフィックを常時監視し、攻撃を検知・緩和します。攻撃中の詳細な分析レポートや、攻撃によって発生したスケールアウトコストの補填などのサポートも提供されます。

第4章: VNet間の接続とハイブリッド接続

単一のVNetだけでシステムが完結することは稀です。開発環境と本番環境、あるいは異なるリージョンのVNet、そしてオンプレミスのデータセンター。これらを安全に接続する方法を学びましょう。

VNetピアリング (VNet Peering)

VNetピアリングは、2つのVNetをMicrosoftのバックボーンネットワーク上でプライベートに接続する最もシンプルな方法です。ピアリングされたVNetは、あたかも1つの大きなVNetであるかのように振る舞い、相互にプライベートIPアドレスで通信できます。

リージョンVNetピアリング: 同一リージョン内のVNet同士を接続します。
グローバルVNetピアリング: 異なるリージョン間のVNetを接続します。

設定と注意点:
* アドレス空間の重複不可: ピアリングするVNetのアドレス空間は重複してはいけません。
* 推移的接続は不可: VNet-AとVNet-B、VNet-BとVNet-Cをピアリングしても、VNet-AとVNet-Cは直接通信できません。AとCを通信させたい場合は、AとCの間でもピアリングを設定する必要があります。
* ゲートウェイトランジット: ハブ&スポークモデルで重要な機能です。ハブVNetにVPNゲートウェイがある場合、スポークVNetがそのゲートウェイを「経由」してオンプレミスと通信できるようにする設定です。

VPNゲートウェイ (VPN Gateway)

VPNゲートウェイは、暗号化されたトンネルをインターネット経由で作成し、VNetと他のネットワークを安全に接続するためのマネージドサービスです。

主な接続シナリオ:
1. サイト間 (S2S) 接続: VNetとオンプレミスのデータセンターを接続します。オンプレミス側には対応するVPNデバイスが必要です。
2. ポイント対サイト (P2S) 接続: VNetと個々のクライアントPC（例: リモートワーク中の従業員のPC）を接続します。クライアントPCにVPNクライアントソフトウェアをインストールして接続します。
3. VNet間 (VNet-to-VNet) 接続: 2つのVNetをVPNで接続します。VNetピアリングが推奨されますが、特定の要件（暗号化が必須など）で利用されることがあります。

VPNゲートウェイをデプロイするには、GatewaySubnet という名前の専用サブネットが必要です。

ExpressRoute

ExpressRouteは、VPNゲートウェイのようにインターネットを経由するのではなく、通信事業者が提供するプライベートな閉域網を介して、オンプレミス環境とAzureを接続するサービスです。

VPNゲートウェイとの比較:
* 帯域幅と安定性: インターネットの状況に左右されない、保証された帯域幅と低遅延、高い信頼性を実現します。
* セキュリティ: プライベート接続であるため、本質的に高いセキュリティを確保できます。
* コスト: 一般的にVPNゲートウェイよりも高コストであり、通信事業者との別途契約が必要です。

大量のデータ転送、リアルタイム性が求められるアプリケーション、またはコンプライアンス要件でパブリックなインターネットの経由が許可されない場合に選択されます。

Virtual WAN (vWAN)

Virtual WANは、大規模なグローバルネットワークを統合的に管理・運用するためのネットワークサービスです。ハブ&スポークトポロジの構築を簡素化し、S2S VPN、P2S VPN、ExpressRoute、VNet接続などを、単一のインターフェースから一元管理できます。

ブランチオフィスが多数あるグローバル企業などが、複雑なネットワーク接続を自動化し、運用を効率化するために利用します。

第5章: VNet内の名前解決 (DNS)

VNet内のリソースがIPアドレスではなく、ホスト名で互いに通信するためには、DNSによる名前解決が不可欠です。Azure VNetでは、主に3つのDNSオプションがあります。

1. Azure提供のDNS (デフォルト)

VNetを作成すると、デフォルトでAzureが提供するDNSサービスが利用できます。

機能: 同一VNet内のVMのホスト名を自動的に解決できます。
制限:
- VNetをまたいだ名前解決はできません（ピアリングしても不可）。
- オンプレミスのリソースの名前解決はできません。
- 独自のカスタムドメイン（例: server1.corp.local）は使用できません。

2. カスタムDNSサーバー

より高度な要件に対応するため、VNetの設定で独自のDNSサーバーを指定できます。

指定可能なサーバー:
- オンプレミスに設置されたDNSサーバー（Active Directoryドメインコントローラーなど）。
- Azure VM上に構築したDNSサーバー（Windows ServerのDNS機能やBINDなど）。
利用シナリオ:
- オンプレミスとAzureのハイブリッド環境で、双方のリソースをシームレスに名前解決したい場合。
- Active Directoryドメインに参加しているVMの名前解決を行いたい場合。

カスタムDNSサーバーを指定すると、VNet内のリソースはすべてそのDNSサーバーに名前解決を問い合わせるようになります。

3. Azure Private DNS

Azure Private DNSは、VNet内で独自のドメイン名（プライベートDNSゾーン）を管理するためのフルマネージドなDNSサービスです。

主な利点:
- DNSサーバーをVMとして構築・管理する手間が不要になります。
- プライベートDNSゾーンを複数のVNet（ピアリングされたVNetも含む）にリンクさせることで、VNetをまたいだ名前解決が容易に実現できます。
- ゾーンを作成し（例: corp.local）、VMのAレコードを自動または手動で登録するだけで利用できます。

現代的なAzure環境では、カスタムDNSサーバーの管理オーバーヘッドを避けるため、Azure Private DNSが第一の選択肢となることが多いです。

第6章: VNetとAzureサービスとの統合

Azureの真価は、VM（IaaS）だけでなく、Azure SQL DatabaseやAzure StorageといったPaaSサービスとの組み合わせで発揮されます。これらのPaaSサービスをVNetから安全に利用するための仕組みが用意されています。

サービスエンドポイント (Service Endpoint)

多くのPaaSサービスは、デフォルトでパブリックIPアドレスを持ち、インターネット経由でアクセスされます。サービスエンドポイントは、VNetから特定のPaaSサービスへのトラフィックを、インターネットに出さずにAzureのバックボーンネットワーク経由で直接ルーティングする機能です。

仕組み:
1. VNetの特定のサブネットで、対象サービス（例: Azure Storage）のサービスエンドポイントを有効化します。
2. 対象のPaaSリソース（例: ストレージアカウント）のファイアウォール設定で、そのサブネットからのアクセスのみを許可するように構成します。
メリット:
- PaaSサービスへのアクセス経路をVNet内に閉じ込めることで、セキュリティが向上します。
- トラフィックが最適化され、パフォーマンスが向上する可能性があります。

サービスエンドポイントは、VNetからPaaSへの「片道」のプライベート接続を確立するイメージです。

プライベートエンドポイント (Private Endpoint)

プライベートエンドポイントは、サービスエンドポイントをさらに進化させた機能です。PaaSサービスを、VNet内にプライベートIPアドレスを持つ仮想的なNICとして公開します。

仕組み:
- 対象のPaaSリソースに対してプライベートエンドポイントを作成すると、指定したVNetとサブネット内にNICが作成され、プライベートIPアドレスが割り当てられます。
- VNet内のリソースは、このプライベートIPアドレスを使ってPaaSサービスにアクセスします。
サービスエンドポイントとの違いとメリット:
- 双方向性: プライベートエンドポイントを使えば、オンプレミスからVPN/ExpressRouteを経由してPaaSサービスにプライベートアクセスすることも可能です。
- 完全な分離: トラフィックは完全にプライベートIPアドレス間で完結し、パブリックエンドポイントを無効化することもできます。
- より高いセキュリティ: IPリークのリスクを排除し、ネットワーク分離の要件を厳格に満たすことができます。

新規設計では、多くの場合、よりセキュアで柔軟なプライベートエンドポイントの利用が推奨されます。

VNet統合 (VNet Integration)

サービスエンドポイントやプライベートエンドポイントが「VNetからPaaSへ」のアクセスだったのに対し、VNet統合は「PaaSからVNetへ」のアクセスを実現する機能です。

対象サービス: Azure App Service, Azure Functions など。
利用シナリオ: Webアプリ（App Service）が、VNet内にあるデータベースサーバー（VM上のSQL Serverや、プライベートエンドポイントを持つAzure SQL Database）にアクセスする必要がある場合。

VNet統合を設定すると、App Serviceのバックエンドからの送信トラフィックが、指定したVNetのサブネットを経由するようになり、VNet内のリソースにプライベートにアクセスできるようになります。

第7章: VNetの設計とベストプラクティス

最後に、これまでの知識を基に、信頼性、拡張性、安全性の高いVNetを設計するためのベストプラクティスをいくつか紹介します。

ハブ&スポークモデル (Hub and Spoke Model)

複数のワークロードや環境（開発、ステージング、本番など）を運用する場合、最も一般的で推奨される設計パターンが「ハブ&スポークモデル」です。

ハブ (Hub) VNet:
- 中央に位置するVNetで、共有サービスを集中配置します。
- 配置されるリソース例: Azure Firewall, VPN/ExpressRouteゲートウェイ, Active Directoryドメインコントローラー, 監視ツールなど。
スポーク (Spoke) VNet:
- 個々のワークロード（例: あるアプリケーション、特定の部署の環境）を配置するVNetです。
- スポークは、VNetピアリングを使ってハブVNetに接続します。
メリット:
- コスト削減: ゲートウェイやファイアウォールなどの高価な共有リソースをハブに集約できます。
- 管理の簡素化: セキュリティポリシーや接続設定をハブで一元管理できます。
- 分離性の確保: ワークロードはスポークごとに分離されており、スポーク間の直接通信はデフォルトではできません（ハブのファイアウォール経由で制御可能）。

IPアドレッシング計画 (IPAM)

場当たり的なIPアドレスの割り当ては、将来の拡張やオンプレミスとの接続時に深刻な問題を引き起こします。

十分なアドレス空間: 将来のAzure利用拡大を見越して、VNetには十分に大きなアドレス空間（例: /16）を割り当てることを検討します。
重複の回避: オンプレミスや、将来接続する可能性のある他のVNet（パートナー企業など）と重複しないプライベートIPアドレス範囲を選択します。
サブネットの計画:
- 機能（Web, App, DB）ごとにサブネットを分割します。
- Azure Firewall (AzureFirewallSubnet), VPN/ExpressRouteゲートウェイ (GatewaySubnet), Azure Bastion (AzureBastionSubnet) など、特定のサービスには専用のサブネットが必要です。これらのサイズ要件をドキュメントで確認します。
- 将来のVM追加を考慮し、サブネットのサイズ（例: /24, /25）を適切に決定します。

セキュリティの多層防御 (Defense in Depth)

単一のセキュリティ対策に頼るのではなく、複数の層で防御を固めるアプローチが重要です。

境界: Azure FirewallやWAF (Web Application Firewall) で、外部からの不正なトラフィックをフィルタリングします。
ネットワーク: NSGを使ってサブネット間やVM間の通信を最小権限の原則で制御します。
ホスト: VM自体のファイアウォールを有効化し、アンチウイルスソフトを導入します。
アプリケーション: アプリケーションレベルでの認証・認可を実装します。
データ: データを暗号化します。

命名規則とタグ付け

リソースが増えてくると、何が何だか分からなくなります。

命名規則: VNet-Prod-EastJP-001 のように、リソースの種類、環境、リージョン、連番などを組み合わせた一貫性のある命名規則を組織で定めます。
タグ付け: コストセンター、オーナー、環境（Prod/Dev）、アプリケーション名などのタグをすべてのリソースに付与することを徹底します。これにより、コスト分析、アクセス権管理、運用の自動化が格段に容易になります。

まとめ

本記事では、Azureのネットワーク基盤であるAzure仮想ネットワーク(VNet)について、その基本概念から、作成、セキュリティ、接続、サービス統合、そして設計のベストプラクティスまで、幅広く詳細に解説しました。

最後に、VNetの重要なポイントをもう一度振り返りましょう。

VNetは、Azure上に構築されるお客様専用のプライベートネットワークであり、すべてのAzureネットワーク設計の出発点です。
アドレス空間とサブネットによって構成され、リソースの論理的なグループ化と分離を実現します。
NSGやAzure Firewallを用いることで、きめ細かいトラフィック制御と多層的なセキュリティを実装できます。
VNetピアリング、VPNゲートウェイ、ExpressRouteといった多様な接続オプションにより、VNet間やオンプレミスとのハイブリッド接続を柔軟に構築できます。
サービスエンドポイントやプライベートエンドポイントを活用することで、PaaSサービスをVNetから安全に利用できます。
実際の設計では、ハブ&スポークモデルやIPアドレッシング計画といったベストプラクティスに従うことが、将来にわたって安定したスケーラブルな環境を維持する鍵となります。

Azure VNetは非常に多くの機能を持ち、最初は複雑に感じるかもしれません。しかし、一つ一つのコンポーネントの役割と関係性を理解すれば、それらを組み合わせて自社の要件に最適なネットワークを自由に設計できるようになります。

クラウドの力を最大限に引き出すためには、その土台となるネットワークをマスターすることが不可欠です。この記事が、あなたのAzureジャーニーにおける確かな一歩となることを願っています。さらに深く学ぶためには、Microsoft Learnの公式トレーニングやAzureのドキュメントもぜひ参照してください。