Skip to content

MS_AzurePrivateLink

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure Private Link

概要

補足（Private Link と Private Endpoint の関係）: 2 つの名前が
紛らわしいが、繋ぐ側と繋がれる側の関係にある。

【アクセス元の VNET】                    【アクセス先（サービス提供側）】

  VM(10.0.1.4)
     ↓
  Private Endpoint  ══════════════════→  Private Link サービス
  (10.0.2.5 の NIC)     Private Link          ↓
                         （経路）        Standard ILB → VM 群
                                         または PaaS
Private Endpoint Private Link サービス
誰が作るか 利用する側 提供する側
何ができるか VNET 内にプライベート IP を生やす 自分のサービスを他 VNET に公開する
PaaS の場合 自分で作る Microsoft が既に用意している

つまり、

  • Azure PaaS を使うだけなら、Private Endpoint を作るだけでよい
    （Private Link サービス側は Microsoft が用意済み）、
  • 自社のサービスを他部門・他社の VNET に公開したい場合に
    Private Link サービスを自分で作る、

という使い分けになる。
実務で圧倒的に多いのは前者である。

詳細

メリット

NAT ルータを介したパケット転送に相当し、Hub & Spoke（FgCF）を構成する際に有用。

オンプレ延伸でIPアドレスを浪費しない。

隔離 VNET を構成し、オンプレの IP アドレスを枯渇させなくて済む。

  • Spoke を隔離 VNET で隔離する。
  • 大量の VM を起動する大量計算バッチなどを隔離 VNET で隔離。

移行メモ（体裁）: 原典の「バッチなどをを隔離」は
「を」が重複していたため修正した。

補足（この「IP アドレスを浪費しない」が実務上いちばん効く）: 一見地味だが、
オンプレと繋ぐ大規模環境では最重要の論点である。

オンプレと VPN / ExpressRoute で繋ぐ場合、

【通常のハブ＆スポーク】
  オンプレの IP 体系（例: 10.0.0.0/8 の一部）を
  VNET にも「切り出して」割り当てる必要がある
    Hub VNET   : 10.100.0.0/16 ← オンプレの管理表から払い出し
    Spoke1     : 10.101.0.0/16 ← 同上
    Spoke2     : 10.102.0.0/16 ← 同上
    ...
  → Spoke を増やすたびにオンプレの IP を消費していく

ところが、大量計算バッチで数百台の VM を一時的に起動するような
用途では、そのために /16 を恒久的に確保することになり、
企業全体の IP 設計を圧迫する。

Private Link を使うと、

【Private Link 方式】
  隔離 VNET     : 172.16.0.0/16 ← オンプレと重複していてもよい
      ↓ Private Endpoint 経由で必要なサービスだけに到達
  Hub VNET      : 10.100.0.0/16

隔離 VNET のアドレスはオンプレから見えない（ルーティングされない）ため、
オンプレの IP 体系から払い出す必要がない。

これが「NAT ルータを介したパケット転送に相当」という説明の意味であり、
Azureの仮想ネットワーク ピアリングが
アドレス重複を許さないのと決定的に違う点である。

単方向のみ許可するのでセキュア＆負荷軽減が可能

単方向のみ許可するので逆方向の通信を行う場合、逆方向の Private Link が必要になる。

  • アクセス先の Azure のサービスからアクセス元の Azure の VNET に入れないのでセキュア
  • この場合、
    • オンプレのプロキシを経由しないので、専用線の負荷軽減が可能。
    • インバウンド開放によるアクセス経路変更が容易になる。

補足（「単方向」がセキュリティ上の本質）: VNET ピアリングとの
決定的な違いがここにある。

VNET ピアリング Private Link
繋がる範囲 VNET 全体 ⇔ VNET 全体 特定のサービス 1 つだけ
方向 双方向 単方向
侵害された時 相手 VNET 全体が攻撃対象 そのサービスにしか到達できない
アドレス重複 不可 可

Azureの仮想ネットワーク ピアリングが
「故に、Private Link の方が安全」と結論しているのはこの理由による。

「経路が存在しない」ことが最も強い防御であり、
NSG のような設定で塞ぐ方式は
設定ミスや変更で穴が開き得る（Network Security Group (NSG)）。

デメリット

メンテナンス経路の検討

SpokeからHubへアクセスするケース

  • 同期であれば、逆方向の Private Link か、NSGだが、セキュリティ・レベルが下がる。
  • 非同期であれば、間にデータ交換用の隔離 VNET を作成することで対応できる。

隔離VNET用のプロキシをどのように準備するか？

が課題になる。

移行メモ（体裁）: 原典の「セキュリティ・レベルが下る」は
「下がる」の送り仮名の誤りであるため修正した。

補足（デメリットの本質は「隔離しすぎると運用できない」）: 3 つの
デメリットは、いずれも同じ問題の別の側面である。

隔離 VNET（Private Link で必要なサービスにだけ繋がる）
  ↑ 単方向なので、外から入れない
  ↑ ではどうやって …
      ・ 管理者がログインするのか？（メンテナンス経路）
      ・ 逆方向にデータを返すのか？（Spoke → Hub）
      ・ パッケージを取得するのか？（プロキシ）

それぞれの現実的な解を挙げておく。

課題 解
メンテナンス経路 隔離 VNET 内に Azure Bastion を置く（Azure Bastion）。パブリック IP は Bastion のみ
Spoke → Hub（同期） 逆方向の Private Link（Hub 側に Private Link サービスを立てる）
Spoke → Hub（非同期） Storage / Service Bus を介する（両者が同じキューに Private Endpoint で繋ぐ）
外部への通信（パッケージ取得等） Azure Firewall を隔離 VNET 内に置くか、Hub の Firewall へ UDR で向ける（Azureのプロキシ的なモノ。）

本文の「非同期であれば、間にデータ交換用の隔離 VNET を作成する」は
中間ストレージを介するという考え方で、
双方が「そこへ書きに行く」だけにすれば、
どちらからも相手の VNET に入る必要が無くなる。
これは古典的なファイル交換方式と同じ発想であり、
セキュリティ境界を跨ぐ設計としては堅実である。

アクセス元・先

アクセス元

Azureの仮想ネットワーク（VNET）

アクセス先

各種の Azure のサービス

補足（IaaS 側で Standard ILB が必須である理由）: 「Private Link サービスと
ILB は依存関係」という記述は重要な制約である。

Private Link サービスは、背後に負荷分散の仕組みを必要とする。
個々の VM を直接公開するのではなく、
ILB のフロントエンド IP を公開する構造になっている。

【提供側 VNET】
  VM1 ┐
  VM2 ├→ Standard 内部 LB（ILB）→ Private Link サービス
  VM3 ┘                                  ↑
                                   【利用側 VNET】の Private Endpoint から接続

ここでStandard SKU が必須であり、Basic では作れない
（Basic SKU 自体が廃止済みでもある）。

この構造の利点は、

  • 提供側はVM を自由に増減できる（利用側から見た窓口は変わらない）、
  • 利用側は提供側の VNET 構成を一切知らなくてよい

という疎結合が成り立つ点にある。
「サービスとして公開する」という語がふさわしい構造になっている。

参考

Qiita

Microsoft Docs

クイックスタート

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally