Databricksのサーバレスを閉域網につなぐために：Private Network GatewayとNCC Private Linkの違いを(私が理解するために)整理する

Posted at 2026-10-18

はじめに

少し前にDatabricks Private Network Gatewayの公式紹介記事が掲載されていました。

企業でサーバレスコンピュートを使っていると必ずぶつかるのが閉域網内のリソースアクセスの壁です。
社内のDB、オンプレのシステム、VPC内に立てたAPIやMCPサーバなど、こういったものにサーバレスから繋ごうとすると、途端に話がややこしくなります。

これまでは NCC（Network Connectivity Configuration）のPrivate Link（プライベートエンドポイントルール）を使うのが定番でしたが、上記の記事では新しい方法(Private Network Gateway(PNG))が紹介されています。

存在は知っていたのですが、自分が利用しているAWS環境だとまだPrivate Previewだったため、理解含めて後回しにしていました。今回改めて自分なりに整理したくなったので、整理・理解を記事にしてみました。
＊ネットワークは専門ではないので誤っている部分もあると思いますので、間違いがあればご指摘ください。

Private Network Gatewayは2026年10月時点で AzureはPublic Preview、AWSはPrivate Preview です。

AWS版の詳細仕様は公開されていないため、本記事のPNGの仕様は主にAzureのドキュメントを元にしています。また、手を動かした検証はしておらず、ドキュメントベースの整理です。

前提：なぜサーバレスは閉域網に届かないのか

まず前提のおさらいです。

クラシックコンピュート：自社のVPC/VNet内でクラスタが動く。なのでVPCピアリングやTransit Gateway等、普通のクラウドの仕組みで社内ネットワークに届く
サーバレスコンピュート：Databricksが管理するアカウント／ネットワーク（サーバレスコンピュートプレーン）で動く。自社VPCの「外」にいる

つまりサーバレスから自社の閉域リソースへ行くには、Databricks管理のネットワークから自社ネットワークへの経路を明示的に作ってあげる必要があります。
Databricksのブログによると、顧客インタビューで75%超が「ネットワーク構成の複雑さ」をワークロードがクラシックに留まる主因に挙げていたそうで、みんな同じところで悩んでいるんだなと。（かくいう自分も閉域網内のデータソースにアクセスする場合はクラシックを利用しがち）

NCCとは

どちらの方式も NCC（Network Connectivity Configuration） という仕組みの上に乗っています。

主な特徴は以下の通りです：

アカウントレベルのオブジェクト: ワークスペースではなくアカウントコンソールで管理する
リージョン単位: 同一リージョンのワークスペースにのみアタッチできる
サーバレスのネットワーク設定の入れ物: 安定IP（ファイアウォール許可用）、プライベートエンドポイントルール、そして今回のPNGもこの中に作る
ワークスペースにアタッチして有効化: NCCを付けたワークスペースのサーバレス全体に設定が効く

PNGは新しいオブジェクトモデルを作るのではなく、既存のNCCの中に作る形になっています。
使いまわしできるのはありがたい。

従来方式：NCC Private Link（AWSの場合）

まずは従来方式から。AWSで「自社VPC内のリソース」にサーバレスから繋ぐ場合の構成です。

設定の流れ

ざっくり以下の手順になります。

自社VPCに内部スキームのNLBを作り、ターゲットに接続先を登録
NLBを公開するVPCエンドポイントサービスを作成（接続承認を必須にし、Databricksのサーバレス用IAMロールを許可プリンシパルに追加）
アカウントコンソールでNCCを作成
NCCにプライベートエンドポイントルールを追加（エンドポイントサービス名と、接続先のFQDNを指定）
AWS側でエンドポイント接続リクエストを承認
ルールのステータスが ESTABLISHED になったことを確認
NCCをワークスペースにアタッチ

ポイントは手順4のFQDN指定です。
サーバレスからの通信先ホスト名がルールのドメイン名に一致すると、そのプライベートエンドポイント経由にルーティングされます。

制約と「つらみ」

ドキュメント上の主な制約は以下です（2026年10月時点）。

項目	内容
NCC数	アカウント・リージョンあたり最大20
プライベートエンドポイント数	リージョンあたり30（複数NCCに分配）
ドメイン数	VPC内リソース向けルール1つあたり最大100
NCCのアタッチ先	1つのNCCにつき最大50ワークスペース
DNS	DNSチェイシング・リダイレクトは非対応（FQDNが直接バックエンドに解決される必要あり）

実運用で効いてくるのは制約そのものよりも運用の手間だと思います。

接続先ごとにNLB＋エンドポイントサービスを用意するのが基本形。接続先が増えるほど部品が増える
NLBはL4なので、RDSのMulti-AZのようにIPが変わる相手はターゲットIPの追従を自前で仕組み化する必要がある
オンプレや別VPC（Transit Gateway越し） に届かせたい場合、NLBの先にHAProxy等のプロキシを置く構成になりがち

最後の点は、Databricks公式のソリューションリポジトリでHAProxyベースの dbx-proxy が公開されています。多くの人が同じことで悩んでるんだろうな、という感じがします。

そして、これらの作業はDatabricks管理者・クラウド/インフラ管理者・ネットワークセキュリティ担当の三者調整になりやすい。接続先が1〜2個なら問題ないのですが、「Lakeflow Connectで社内DBを十数個取り込みたい」となった瞬間に結構しんどくなりそうです。
インフラ担当者にキレられそう。

Private Network Gateway（PNG）とは

そこで(?)登場したのがPNGです。

一言でいうと、「リソース単位」ではなく「ネットワーク単位」でサーバレスを自社ネットワークにつなぐ、Databricksマネージドなゲートウェイです。

主な特徴は以下の通りです：

サブネットを1つ委任するだけ: 自社VNet（VPC）にゲートウェイ専用サブネットを用意してDatabricksに委任すると、Databricksがそこにゲートウェイを注入・運用する
そのサブネットから届く先には全部届く: VNet内はもちろん、ExpressRoute/VPN越しのオンプレなど推移的に接続されたネットワークにも到達できる
ゲートウェイVMの管理不要: パッチ当てやスケールはDatabricks側。帯域はAzureで10/30/50/100Gbpsのティアから選択
既存NCCの中に作る: NCCをアタッチ済みのワークスペースはそのままゲートウェイを使える
到達制御は自社ネットワーク側の仕組みで: サブネットから先はルートテーブル、NSG、DNSリゾルバ、ファイアウォール等、普段のネットワーク制御がそのまま効く

ブログで挙げられているユースケースも、社内DBからのLakeflow Connect取り込み、エージェントから社内MCPサーバの呼び出し、社内PyPIミラーからのライブラリインストール、自社FW経由のエグレス、自社所有の送信元IPでSaaSに接続など、まさに「従来だと面倒だったやつ」が並んでいます。

2つのトラフィックモード

PNGは traffic_mode で、どこまでのトラフィックを担うかを選ぶようです。

モード	挙動	使いどころ
`SPECIFIC_DESTINATIONS`	`destinations` に列挙したDNS名だけをPNG経由にする（サフィックス一致あり）	大半のケースで推奨。特定の閉域リソースに繋ぎたい
`ALL_TRAFFIC`	より具体的な経路（Private Link等）に一致しない全エグレスをPNG経由にする	全エグレスを自社FWで検査したい／自社IPから出したい

エグレス制御との関係が少し違うので注意。SPECIFIC_DESTINATIONS で指定した宛先はエグレス制御で自動的に許可されますが、ALL_TRAFFIC の場合は接続したい宛先をネットワークポリシーに明示的に追加する必要があるようです。

経路の優先順位

サーバレスのアウトバウンド通信は、以下の優先順位で最初に一致した経路が使われます。

優先度	経路	対象
1	プライベートエンドポイントルール（Private Link）	ルールが存在する特定リソース宛て
2	AWS: S3/DynamoDBのゲートウェイエンドポイント／Azure: サービスエンドポイント	クラウドのバックボーンに留まり、PNGで上書きできない
3	Private Network Gateway	`SPECIFIC_DESTINATIONS` の宛先、または `ALL_TRAFFIC` の残り全部
4	デフォルトのサーバレスエグレス	それ以外

Private Linkのルールがある宛先は、ALL_TRAFFICモードであってもPrivate Linkが勝ちます。
PNGは既存設定を置き換えるものではなく、「横に足す」ものとして設計されていて、有効化・削除しても既存のPrivate Link設定には影響しない、とされています。

設定イメージ（Azure）

Azureのドキュメントにあるリクエスト例を元に、設定イメージを載せてみます。
NCC配下の private-network-gateways にPOSTする形です。

create_png.sh

curl --request POST \
  'https://accounts.azuredatabricks.net/api/2.0/accounts/{account_id}/network-connectivity-configs/{ncc_id}/private-network-gateways' \
  --header 'Authorization: Bearer <access_token>' \
  --header 'Content-Type: application/json' \
  --data '{
    "gateway_name": "my-azure-png",
    "traffic_mode": "SPECIFIC_DESTINATIONS",
    "azure_cloud_connection": {
      "gateway_subnet": {
        "resource_id": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}"
      }
    },
    "private_dns_resolvers": [
      { "resolver_type": "IP_ADDRESS", "value": "10.0.0.4" }
    ],
    "destinations": [
      { "destination_type": "DNS_NAME", "value": "myserver.internal.contoso.com" }
    ]
  }'

作成直後は CREATING で、数分で ESTABLISHED に遷移するとのこと。
Private Linkと比べると、NLBもエンドポイントサービスも承認作業もない ようです。その代わり、DNSリゾルバの指定が必須 になっているのが特徴的です。PNGは自社ネットワークのDNSで名前解決するので、プライベートDNSゾーンのリンク漏れ等はここで効いてきそうです。

Azureでの主な前提・制限は以下です。

Premiumプラン、/28 以上の専用サブネット（他リソースと共用不可）、Microsoft.Databricks/workspaces への委任
ゲートウェイとサブネットはNCCと同一リージョン
NCCあたり最大2ゲートウェイ、ゲートウェイあたりDNSリゾルバ最大2・宛先最大100
ADLSのようにサービスエンドポイント経由になるクラウドサービスには使えない
課金は2026年12月1日以降に開始予定

比較してみる

ここまでの内容を表にまとめてみました。

観点	NCC Private Link（自社VPC内リソース向け）	Private Network Gateway
接続の単位	リソース（エンドポイントサービス）単位	ネットワーク（サブネット）単位
自社側に必要なもの	NLB＋VPCエンドポイントサービス（＋必要ならプロキシ）	委任サブネット1つ＋DNSリゾルバ
オンプレ・別VPC	基本はプロキシ等を挟む工夫が必要	サブネットから届けば届く（推移的接続OK）
接続先追加時の作業	NLB/ターゲット/ルール追加、承認…	`destinations` にDNS名を追加
名前解決	ルールに登録したFQDNが直接バックエンドに解決される必要あり	自社のDNSリゾルバで解決
到達制御	エンドポイントサービス単位で限定的に公開	自社のルート・NSG・FWで制御
エグレスのFW経由化／送信元IP固定	用途外	`ALL_TRAFFIC` で可能
クラウドマネージドサービス（S3/ADLS等）	こちらが適任	対象外
経路の優先度	最優先	Private Link・サービスエンドポイントの次
成熟度	GA	Preview（AWSはPrivate Preview）

一言でまとめると、

Private Link は「この1つのリソースにだけ、専用の細い管を通す」
PNG は「自社ネットワークへの玄関を1つ作り、その先は自社のネットワーク設計に任せる」

という発想の違いだと理解しました。

自社AWSアカウント側のコストはどう変わる？

基盤担当として気になるのはやはりお金の話です。
自社AWSアカウントの請求書に載るものに絞って整理してみます。

:::note warn AWS版PNGはPrivate Previewで、料金体系は2026年10月時点で公開されていません。PNG側はAzureの情報や構成からの推測を含みます。 :::

NCC Private Link方式の場合

自社VPC側に接続先ごとの部品を用意するため、それぞれに固定費がかかります。

NLBの時間料金＋LCU料金：エンドポイントサービスの裏に置くNLB分。接続先ごとにNLBを分けると、その数だけ固定費が積み上がる
NLB〜ターゲット間のAZ間転送料：NLBノードとターゲットが別AZにある場合
クロスリージョン時の追加料金：エンドポイントサービス提供側のリモートリージョンごとの時間料金と、リージョン間データ転送料
プロキシEC2など（必要な場合）：オンプレや別VPCへ届かせるためのHAProxy、RDSのIP追従用Lambdaなど

なお、インターフェースVPCエンドポイント自体は Databricks側のアカウントに作られるため、エンドポイントの時間料金やデータ処理料金はAWSではなく、Databricksの請求（Private Connectivity）として載ってきます。

PNG方式の場合

NLB・エンドポイントサービス・プロキシが不要になるので、上記の「接続先ごとの固定費」はほぼなくなります。ゲートウェイ自体もDatabricksが運用するので、自社でVMを持つ必要はありません。

その代わり、委任サブネットから先は自社ネットワークの経路を通るので、その経路上の従量課金がそのまま自社アカウントに乗ってきます。

ゲートウェイ用サブネットとターゲットのAZが異なる場合の AZ間転送料
Transit Gateway経由で別VPCへ行く場合の TGWデータ処理料金
Direct Connect／VPN経由でオンプレへ行く場合のデータ転送料
ALL_TRAFFIC モードの場合は、NAT Gateway・Network Firewall・インターネット向け転送料も追加

特に最後の ALL_TRAFFIC は、これまでDatabricks側のデフォルトエグレスで出ていた通信が自社経由になるため、ほぼ純増になると思われます。

また、ゲートウェイそのものの料金は、Azureでは2026年12月1日以降に課金開始とアナウンスされていますが、単価や課金主体は公開情報からは確認できませんでした。

個人的な見立てとしては、接続先が多い・オンプレ向けが多い環境ではPNGの方がNLBやプロキシの固定費と運用工数を削れるので、トータルで有利になりやすいと思います。オンプレ向けの通信はどちらの方式でも結局TGWやDXを通るので、その部分の従量費は大きく変わりません。

一方で、Lakeflow Connectで大きなDBを毎日取り込むような大量転送のケースでは、PNG自体にGB課金があるかどうかで結論が変わりそうです。このあたりはAWS版の正式な料金が出てから改めて比較したいところかな、と。

どう使い分けるか

ドキュメント上も「PNGはPrivate Linkを置き換えるものではなく補完するもの」と明言されています。
それを踏まえて、以下のような考え方かなと思います。

Private Link（NCCのプライベートエンドポイントルール）を選ぶ

S3、ADLS、Snowflakeなど、クラウドマネージドなサービスやSaaS への接続
接続先が少数で固定的、かつ「そのリソースにしか行けない」ことをネットワーク的に強く保証したい
Preview機能を本番に入れられない（PNGがGAになるまで）

PNGを選ぶ

閉域内の自前リソースが多数ある（社内DB群、Kafka、社内API、MCPサーバ、パッケージリポジトリ…）
オンプレ や Transit Gateway/ピアリング越しの別ネットワークに届かせたい
サーバレスの エグレスを自社FWで検査 したい、自社のIPから出したい

併用する

実際には併用が一番現実的だと思います。例えばストレージやSaaSはPrivate Link、社内DB・オンプレ系はPNGの SPECIFIC_DESTINATIONS で、という形です。優先順位があるので、併用しても経路が勝手に奪われることはありません。

注意点としては、PNGは「サブネットから先は自社ネットワーク次第」なので、到達範囲の統制責任が自社のネットワーク設計側に寄ることです。Private Linkは良くも悪くも「エンドポイントサービスで公開したものにしか行けない」構造でしたが、PNGはルート・NSG・FWをきちんと絞らないと、サーバレスから見えるものが想定より広くなりえます。
なんとなくで設定するとセキュリティチームに激詰めされるおそれがありますね。。。

まとめ

Databricksサーバレスから閉域網に接続する方法として、従来のNCC Private LinkとPrivate Network Gatewayの違いを整理してみました。

個人的には、「接続先が増えるたびにNLBとエンドポイントサービスを生やす」運用から解放される のがPNGの一番大きな価値だと思います。特にオンプレのDBや社内のMCPサーバに繋ぎたいケースでは、これまでプロキシを挟む構成が実質必須だったので、かなり世界が変わりそうです。

とはいえ、AWSはまだPrivate Previewで詳細仕様も公開されておらず、本番投入には怖いところがあります。到達範囲の統制が自社ネットワーク側に寄る点も、設計上きちんと考えておく必要があります。

利用できるようになったら実際に手を動かして検証してみたいと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up