Azure App Serviceのネットワーク｜Private Endpoint(受信)とVNet統合(送信)の違いを図解

Azure

App Serviceのネットワーク設定でほぼ全員がつまずくのが、「Private Endpoint」と「VNet統合」の違いです。名前が似ているうえ、どちらも「VNetにつなぐ」機能なので、どっちがどっちだか分からなくなる——これは学習者だけでなく、実務者でも混同しがちな最重要ポイントです。

Private EndpointとVNet統合、どっちが「入ってくる方」で、どっちが「出ていく方」だっけ…？

この記事では、App Serviceの「ネットワーク（閉域接続）」を、入口（受信）と出口（送信）の2方向で整理します。ここさえ押さえれば、もう混同しません。読み終えたときに、次の4つを説明・実践できるようになることをゴールにします。

  • VNet統合（送信トラフィック）を構成できる
  • Private Endpoint（受信）を構成できる
  • 受信PEと送信VNet統合の違いを説明できる（★この記事の核心）
  • アクセス制限（IP制限／サービスタグ）を設定できる

各セクションの最後に「これが説明できればOK」の自己チェックを置いています。App Serviceの概要は第1回で解説しています。

まず全体像：入口＝Private Endpoint / 出口＝VNet統合

個別の設定に入る前に、この記事で一番大事な1枚の図を頭に入れてください。App Serviceのネットワークは、トラフィックの向きで機能が分かれています。

          【入口＝受信 inbound】
   誰がアプリに「入って」こられるか？
   → Private Endpoint で閉域化
                │
                ▼
   ┌──────────────────────────────┐
   │         App Service           │
   │        （あなたのアプリ）        │
   └──────────────────────────────┘
                │
                ▼
          【出口＝送信 outbound】
   アプリが「外へ出て」どこに繋ぐか？
   → VNet統合 で VNet内リソースへ閉域接続
     （例: DB、Storage、他のPrivate Endpoint）

「入口＝Private Endpoint、出口＝VNet統合」。まずこの一言だけ丸暗記すれば大丈夫！

この「入口／出口」の対応さえ握っておけば、以降のセクションはすべてこの図の詳細説明にすぎません。それでは、まず出口（VNet統合）から見ていきましょう。

VNet統合（送信トラフィック）を構成する

VNet統合（Virtual Network Integration）とは、App Serviceからの「送信（アウトバウンド）」トラフィックを、指定したVNet内に流し込む機能です。＝アプリが”外に出ていく”方向を閉域化します。

典型的なユースケースは、「App Serviceから、VNet内のデータベースやStorage（Private Endpoint化されたもの）に、インターネットを経由せず閉域で接続したい」というケースです。App Serviceは既定ではインターネット側に出ていきますが、VNet統合を有効にすると、送信トラフィックがVNet内のサブネットを通るようになります。

# VNet統合を有効化（委任サブネットを指定）
az webapp vnet-integration add \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --vnet my-vnet \
  --subnet snet-appservice-integration

VNet統合にはApp Service専用に委任された空きサブネットが必要です。有効化すると、アプリからの送信が「そのVNetの一員」として振る舞うようになり、VNet内のプライベートIPを持つリソースへ到達できるようになります。

【ここが説明できればOK①】
VNet統合を有効化し、アプリからの送信トラフィックがVNet内のリソースへ到達することを確認できれば、このチェックはクリアです。

Private Endpoint（受信）を構成する

Private Endpoint（プライベートエンドポイント）とは、App Serviceへの「受信（インバウンド）」を、VNet内のプライベートIP経由に限定する機能です。＝アプリに”入ってくる”方向を閉域化します。

Private Endpointを作成すると、App ServiceにVNet内のプライベートIPアドレスが割り当てられます。これにより、「社内ネットワーク（VNet）からしかアプリにアクセスできない」という閉域構成が実現します。パブリックのインターネットからは到達できなくなる（＝アプリを隠せる）のが最大の効果です。

# App Service用のPrivate Endpointを作成
az network private-endpoint create \
  --resource-group rg-appservice \
  --name pe-my-webapp \
  --vnet-name my-vnet \
  --subnet snet-private-endpoints \
  --private-connection-resource-id "<App ServiceのリソースID>" \
  --group-id sites \
  --connection-name conn-my-webapp

Private Endpointを使うときは、プライベートDNSゾーン（privatelink.azurewebsites.net）を構成し、アプリのFQDNがプライベートIPに解決されるようにするのが定石です。これで、VNet内のクライアントは「いつものURL」のままプライベートIP経由でアクセスできます。

【ここが説明できればOK②】
Private Endpointを作成し、アプリへの受信がVNet内のプライベートIP経由になることを確認できれば、このチェックはクリアです。

【核心】受信PEと送信VNet統合の違い

ここが本記事の山場です。2つの機能を並べて比較すると、役割の違いがはっきりします。

Private EndpointVNet統合
向き受信（inbound）＝入口送信（outbound）＝出口
何を閉域化？アプリに入ってくるアクセスアプリが外に出ていく接続
典型用途アプリを社内VNetからのみ公開アプリからVNet内のDB/Storageへ接続
合言葉「誰が入ってこられるか」「どこへ出ていくか」

覚え方はシンプルです。「Private Endpoint＝人がアプリに入ってくる玄関を閉じる」「VNet統合＝アプリが外へ出ていく裏口を作る」。この2つは対立するものではなく、両方同時に使うのが普通です。

【両方使う典型構成：完全閉域のWebアプリ】

  社内ユーザー
     │ ①受信：Private Endpoint経由（VNet内から）
     ▼
 ┌───────────────┐
 │  App Service   │
 └───────────────┘
     │ ②送信：VNet統合経由
     ▼
  VNet内のDB（Private Endpoint化されたSQL DB等）

  → 入口も出口もインターネットを通らない＝完全閉域

この「入口＝PE、出口＝VNet統合」の役割分担は、App ServiceだけでなくAzureの閉域設計全般に通じる考え方です。ちなみに、前段にApplication Gatewayを置く構成では、AGW側でも同じ「入口／出口」の整理（AGWのネットワーク・セキュリティ記事）が登場します。合わせて読むと閉域設計の全体像がつかめます。

【ここが説明できればOK③】
「Private Endpointが受信の閉域化、VNet統合が送信側の接続を担う」という役割の違いを説明できれば、このチェックはクリアです。

アクセス制限（IP制限／サービスタグ）を設定する

Private Endpointほど厳格な閉域化までは不要でも、「特定のIPアドレスやサービスからのアクセスだけ許可したい」という要件はよくあります。これに応えるのがアクセス制限（Access Restrictions）です。

アクセス制限は、受信トラフィックに対する許可／拒否ルールのリストです。指定できる条件には次のようなものがあります。

  • IPアドレス範囲（例: 社内オフィスのグローバルIP 203.0.113.0/24 だけ許可）
  • サービスタグ（例: AzureFrontDoor.Backend など、特定のAzureサービスからのアクセスだけ許可）
  • VNet（サブネット）（サービスエンドポイント経由の特定サブネットのみ）
# 特定IPからのみ許可するルールを追加
az webapp config access-restriction add \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --rule-name "allow-office" \
  --action Allow \
  --ip-address 203.0.113.0/24 \
  --priority 100

許可ルールを1つでも追加すると、それ以外は暗黙的に拒否される動きになります。「Front Doorの背後にApp Serviceを置き、Front Door経由（サービスタグ）以外は弾く」といった構成でよく使われます。Private Endpointが「そもそもインターネットから見えなくする」のに対し、アクセス制限は「見えるけど許可リストで絞る」——用途に応じて使い分けます。

【ここが説明できればOK④】
アクセス制限ルールで許可IPやサービスタグを指定し、許可外アクセスが拒否されることを確認できれば、このチェックはクリアです。

まとめ

今回はApp Serviceのネットワークを「入口／出口」の2方向で整理しました。ここが分かれば、閉域設計はもう怖くありません。

  • 入口（受信）＝Private Endpoint：アプリに入ってくるアクセスをVNet内プライベートIPに限定
  • 出口（送信）＝VNet統合：アプリから外へ出る接続をVNet内リソースへ閉域化
  • 両者は対立せず同時に使うのが普通（完全閉域なら両方）
  • アクセス制限：PEほど厳格でなく「見えるけど許可リストで絞る」（IP/サービスタグ）

ネットワークの次は認証・ID——マネージドIDやKey Vault参照で、閉域接続をさらにパスワードレスに——へ進みましょう。次回（第5回）で解説します。

あわせて読みたい

タイトルとURLをコピーしました