Azure Databricks で Zerobus Ingest や Lakebase Autoscaling などの高負荷サービスをプライベート接続で使う場合、通常のワークスペース向け inbound Private Link だけでは足りないケースがあります。今回確認すべきポイントは、service_direct を使う「performance-intensive services」向けの inbound Private Link を別途構成できるようになっている点です。
特に、外部ネットワーク上のアプリケーションやクライアントから Lakebase Autoscaling に Postgres クライアント、ドライバー、ORM で接続する構成では、従来のフロントエンド Private Link と用途が異なるため、DNS、Private Endpoint、Databricks アカウント側の登録まで含めて確認が必要です。なお、本稿は2026年6月29日時点で確認できる公式情報をもとに整理していますが、対象の Microsoft Learn ページ上では最終更新日が2026年6月26日と表示されています。(Microsoft Learn)
Azure Databricks の「Configure inbound Private Link for performance-intensive services」とは
「Configure inbound Private Link for performance-intensive services」は、Azure Databricks プラットフォーム上の高パフォーマンス系サービスに対して、外部クライアントやユーザーが Azure Private Link 経由でプライベートにアクセスするための設定手順です。公式ドキュメントでは、この機能は Public Preview とされ、対象例として Zerobus Ingest と Lakebase Autoscaling が挙げられています。(Microsoft Learn)
ここで重要なのは、「Azure Databricks ワークスペースへプライベート接続するための inbound Private Link」と「performance-intensive services 用の inbound Private Link」は同じものではない、という点です。
Azure Databricks の Private Link には、ユーザーやAPIからワークスペースへ入る inbound、serverless compute からAzureリソースへ出る outbound、classic compute plane と control plane の通信を保護する back-end など複数の考え方があります。今回の対象は、その中でも高負荷サービス向けの inbound private connectivity に位置付けられます。(Microsoft Learn)
何が便利になるのか
この構成により、パブリックインターネットを経由せずに Azure Databricks の特定サービスへ到達できるようになります。セキュリティ境界を VNet、Private Endpoint、DNS に寄せられるため、金融、製造、公共、医療、グローバル企業のようにネットワーク経路を厳格に管理したい環境では特に意味があります。
公式ドキュメントでは、主なメリットとして、Azure ネットワーク基盤内にトラフィックを保持できること、Zerobus Ingest や Lakebase Autoscaling などの高負荷サービスにプライベート接続できること、規制・コンプライアンス要件への対応、NAT gateway などのパブリック接続オプションと比べたコスト効率が挙げられています。(Microsoft Learn)
ただし、コスト面については注意が必要です。Databricks は現時点で、この inbound Private Link 接続に関連するネットワークコストを課金していないと説明していますが、将来的に課金が導入される可能性にも触れています。設計時には「今は無料だから固定費に影響しない」と決め打ちせず、将来の価格変更を前提に見積もりや利用部門への説明を行うべきです。(Microsoft Learn)
影響範囲：対象になる環境と対象になりにくい環境
今回の更新ポイントは、すべての Azure Databricks 利用者に直ちに影響するものではありません。影響が大きいのは、Private Link を前提に Azure Databricks を閉域化しており、さらに Zerobus Ingest や Lakebase Autoscaling のような高負荷サービスを使う、または検証している組織です。
| 利用シーン | 影響度 | 確認すべきこと |
|---|---|---|
| Lakebase Autoscaling に外部アプリから Postgres クライアントで接続する | 高 | performance-intensive services 用の inbound Private Link が必要になる可能性が高い |
| Zerobus Ingest を閉域網から利用する | 高 | service_direct の Private Endpoint とDNS設計を確認する |
| Azure Databricks のUI、REST API、Databricks Connect API のみを Private Link 化している | 中 | 通常の inbound Private Link と今回の構成を混同していないか確認する |
| ワークスペース内のアプリや Feature Store connectors から Lakebase に接続する | 低〜中 | 追加エンドポイントが不要なケースに該当するか確認する |
| Data API のみで Lakebase に接続する | 低 | performance-intensive services 用エンドポイントが不要とされるケースに該当する可能性がある |
Lakebase Autoscaling では、標準の inbound Private Link は Azure Databricks REST API やワークスペース接続を扱い、performance-intensive services 用の inbound Private Link は Postgres database connections を扱います。特に外部から Postgres クライアント、ドライバー、ツールで地域付き接続文字列を使う場合、後者が必要とされています。(Microsoft Learn)
一方で、アプリケーションが Azure Databricks ワークスペース内から接続する場合や、Data API のみを使う場合は、この endpoint が不要と説明されています。不要な構成を追加すると、DNSや権限管理が複雑になり、トラブルシューティング対象も増えるため、まず接続方式を棚卸しすることが大切です。(Microsoft Learn)
通常の inbound Private Link との違い
既に Azure Databricks の Private Link を構成済みの管理者ほど、今回の設定を「既存の Private Endpoint の延長」と見なしてしまいがちです。しかし実務上は、用途、対象トラフィック、DNSレコード、サブリソース名が異なります。
| 比較項目 | 通常の inbound Private Link | performance-intensive services 用 inbound Private Link |
|---|---|---|
| 主な用途 | ワークスペースUI、REST API、Databricks Connect API | Zerobus Ingest、Lakebase Autoscaling などの高負荷サービス |
| 代表的な通信 | HTTPS / 443 | Lakebase の Postgres 接続では 5432 が関係する |
| Private Endpoint の対象 | ワークスペース向けフロントエンド | リージョン単位の高性能サービス入口 |
| Target sub-resource | 代表例は databricks_ui_api など | service_direct |
| DNS設計 | ワークスペース向けの Private Link DNS | privatelink.azuredatabricks.net に <region>.service-direct の A レコードを作成 |
| 管理単位 | 主にワークスペース設計と連動 | アカウントレベル、同一リージョンの Premium ワークスペースへ影響 |
通常の inbound Private Link は、ユーザーやAPIクライアントが Azure Databricks ワークスペースにアクセスするための経路です。公式の概念説明では、Azure Databricks web application、REST API、Databricks Connect API への安全なアクセスが対象として示されています。(Microsoft Learn)
これに対して、performance-intensive services 用の Private Link は、Zerobus Ingest や Lakebase Autoscaling のようなサービスに対する専用のプライベート経路です。既存の inbound Private Link を設定済みでも、Postgres クライアント接続が public 経由になっていないか、DNS が意図どおり private IP を返しているかを確認する必要があります。
前提条件：設定前に確認すべきライセンス、権限、機能フラグ
公式手順では、構成前の要件として Azure Databricks アカウントが Premium tier であること、アカウントで Public Preview 機能を有効化していること、Databricks 側ではアカウント管理者であること、Azure 側では Network Contributor または同等の権限を持つことが示されています。(Microsoft Learn)
設定画面に Private Endpoint が見えない場合、ネットワーク設定そのものよりも、Public Preview 機能が有効化されていない可能性があります。特にグローバル企業では、Databricks アカウント管理者、Azure サブスクリプション管理者、ネットワークチームが別組織になっていることが多いため、作業前に責任分界を明確にしておくべきです。
| 確認項目 | 必要な状態 | 不足している場合に起きやすい問題 |
|---|---|---|
| Azure Databricks プラン | Premium tier | 機能要件を満たせない |
| Public Preview 機能 | アカウントコンソールで有効化 | 登録対象の endpoint が表示されない |
| Databricks 権限 | Account admin | Private Endpoint を登録できない |
| Azure 権限 | Network Contributor 相当 | Private Endpoint やNICを作成できない |
| リージョン設計 | ワークスペースVNetと整合 | Private Endpoint のリージョン不一致やDNS不整合が起きる |
| DNS運用 | Private DNS Zone を管理可能 | public IP へ解決され、閉域化に失敗する |
設定変更の流れ：管理者が実施する主な手順
設定は大きく分けて、Azure 側で Private Endpoint を作成し、Databricks 側で登録し、最後にDNSを構成する流れです。順番を誤ると、Private Endpoint の接続状態が Pending のままに見えたり、名前解決だけ public 側に残ったりします。
Private Endpoint 用の VNet とサブネットを準備する
最初に、Private Endpoint を配置する VNet とサブネットを決めます。新規VNetでも既存VNetでも構成できますが、既存のワークスペースVNetを再利用する場合は、ワークスペースの compute injection subnets とは別のサブネットを使う必要があります。(Microsoft Learn)
一方で、performance-intensive services 用の Private Endpoint は、既存の inbound private endpoint と同じサブネットに配置できると説明されています。ここを誤解すると、不要にサブネットを増やしてIP設計が複雑になるため注意が必要です。(Microsoft Learn)
Private Endpoint を置く VNet と、実際にトラフィックを発生させる VNet が異なる場合は、VNet peering などの接続性も確認します。グローバル展開では、ハブアンドスポーク型の transit VNet に Private Endpoint を集約する設計が多いため、アプリケーション側サブネットから private IP へ到達できるかを事前に確認しておくと手戻りを減らせます。
Azure portal で Private Endpoint を作成する
Azure portal では、Private Endpoint 作成時に「Connect to an Azure resource by resource ID or alias」を選び、対象リージョンに対応する Private Link Service resource ID を入力します。Target sub-resource には service_direct を指定します。(Microsoft Learn)
リージョン別の Private Link Service Resource ID は、Microsoft Learn の「IP addresses and domains for Azure Databricks services and assets」に一覧化されています。たとえば japaneast や japanwest など、利用リージョンごとに resource ID が異なるため、テンプレート化する場合もリージョン変数を誤らないようにします。(Microsoft Learn)
DNS 統合は、この段階では「No」のままにし、後続手順で手動設定します。公式手順でも、DNS は後で構成する前提になっています。(Microsoft Learn)
Databricks アカウントコンソールで Private Endpoint を登録する
Azure 側で Private Endpoint を作成しただけでは完了しません。作成後、Azure Databricks account console に移動し、Security > Networking > Endpoints > Register endpoint から Private Endpoint を登録します。(Microsoft Learn)
Private Endpoint 作成直後に接続状態が Pending になっていても、それ自体は異常とは限りません。公式手順では、Databricks 側で登録を完了するまで Pending のままになると説明されています。運用監視で「Pending＝障害」と即断するのではなく、作業ステップのどこまで終わっているかを確認しましょう。(Microsoft Learn)
Private DNS Zone と A レコードを構成する
DNS では、privatelink.azuredatabricks.net の Private DNS Zone を作成または再利用します。既に通常の inbound Private Link で同名の Private DNS Zone を使っている場合は、既存ゾーンを再利用する構成が示されています。(Microsoft Learn)
A レコードは、<region>.service-direct という形式で作成します。たとえば West US 2 なら westus2.service-direct です。値には、Private Endpoint 作成後に確認した private IP address を設定します。(Microsoft Learn)
日本リージョンで考えるなら、Japan East の場合は japaneast.service-direct.privatelink.azuredatabricks.net の名前解決が private IP を返す状態を目指します。実際のリージョン名は Azure のリージョン表記と公式ドキュメントの resource ID 一覧に合わせてください。
確認には、VNet 内の仮想マシンや、対象の Private DNS Zone に接続された環境から nslookup または dig を使います。公式手順でも、<region>.service-direct.privatelink.azuredatabricks.net が Private Endpoint の private IP を返すことを確認する流れが示されています。(Microsoft Learn)
nslookup japaneast.service-direct.privatelink.azuredatabricks.net期待する結果は、public IP ではなく、作成した Private Endpoint の private IP が返ることです。ここで public 側に解決される場合、Private DNS Zone のリンク漏れ、A レコード名の誤り、オンプレミスDNSフォワーダーの条件付き転送漏れを疑います。
public access の扱い：Private Link 設定だけでは閉域化は完了しない
見落としやすい点として、Private Link を構成しても、それだけで Azure Databricks ワークスペースへの public internet access が自動的に遮断されるわけではありません。公式手順では、private-only connectivity を強制するには、Azure portal の Azure Databricks workspace resource で Allow Public Network Access を Disable に設定すると説明されています。(Microsoft Learn)
つまり、セキュリティ監査で「Private Link を構成したので閉域化済み」と説明するのは不十分です。少なくとも次の3点をセットで確認する必要があります。
| 確認観点 | 確認内容 | 判断基準 |
|---|---|---|
| 経路 | 対象サービスのFQDNが private IP に解決されるか | nslookup や dig で Private Endpoint のIPが返る |
| アクセス制御 | public network access が必要に応じて無効化されているか | セキュリティ要件が private-only なら Disable |
| 疎通 | アプリケーションが private 経由で接続できるか | Postgres クライアントや対象処理で実接続確認を行う |
本番環境では、設定作業後に「名前解決」「TCP接続」「認証」「アプリケーション処理」の4段階で確認するのがおすすめです。DNSだけ成功しても、ルートテーブル、NSG、ファイアウォール、プロキシ、クライアント設定のどこかで失敗することがあります。
移行期限はあるのか
今回の公式ドキュメントには、既存環境に対する強制移行期限や廃止日として明確な日付は示されていません。確認できるのは、この機能が Public Preview であること、対象サービス向けの Private Link 構成手順が提示されていること、そして public access を無効化する場合は別途設定が必要であることです。(Microsoft Learn)
そのため、管理者が取るべき現実的な対応は「期限が出るまで放置」ではなく、対象サービスを使っている環境から順に棚卸しすることです。特に、セキュリティポリシーで public internet 経由のDB接続を禁止している組織では、Lakebase Autoscaling の利用計画とセットで早めに検証環境を作るべきです。
Public Preview の機能は、一般提供時に仕様、制限、課金、サポート条件が変わる可能性があります。本番採用を検討する場合は、公式ドキュメントの更新履歴と Azure Databricks アカウントチームからの案内を継続的に確認してください。
制限事項と設計上の注意点
performance-intensive services 用の Private Endpoint は、アカウントレベルで同一リージョン内のすべての Premium ワークスペースに自動的に影響します。また、アカウントごとの制限として、リージョンあたり5個、アカウント全体で100個までという上限が示されています。上限引き上げが必要な場合は Azure Databricks アカウントチームへの相談が必要です。(Microsoft Learn)
この「アカウントレベルで影響する」という点は、マルチワークスペース運用では特に重要です。開発、検証、本番でワークスペースを分けている場合でも、同一リージョン・同一アカウントであれば設計判断が共有されます。部門ごとに独自の Private Endpoint を作り始めると、リージョンあたり5個の上限に早く到達する可能性があります。
失敗しやすいポイント
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Private Endpoint が Pending のまま | Databricks 側の登録が未完了 | Account console で endpoint 登録を完了する |
| 接続が public 経由になる | Private DNS Zone のリンク漏れ、A レコード誤り | VNet から nslookup で private IP を確認する |
| Azure portal で対象が見えない | Public Preview 機能が未有効 | Databricks account console で機能を有効化する |
| 既存 Private Link だけで十分だと思い込む | UI/API向けと高負荷サービス向けの経路を混同 | 接続方式ごとに必要 endpoint を整理する |
| グローバル展開で設定がばらつく | リージョンごとの resource ID とDNS名を手作業で管理 | IaC化し、リージョン変数とレビュー手順を標準化する |
| public access を止めたらアプリが失敗する | DNSまたはルーティングが private 経由になっていない | public access 無効化前に疎通テストを完了する |
管理者向けチェックリスト
本番適用前には、次の順序で確認すると抜け漏れを減らせます。
| フェーズ | 確認項目 | 完了条件 |
|---|---|---|
| 影響調査 | Zerobus Ingest、Lakebase Autoscaling の利用有無を確認 | 対象サービスと接続元が一覧化されている |
| 接続方式確認 | Postgres クライアント、Data API、ワークスペース内アプリのどれかを分類 | performance-intensive services 用 endpoint の要否を判断できる |
| 権限確認 | Databricks Account admin と Azure Network Contributor を確保 | 作業担当者と承認者が決まっている |
| ネットワーク設計 | Private Endpoint を置く VNet、サブネット、peering を決定 | アプリケーション接続元から private IP へ到達できる |
| Private Endpoint 作成 | service_direct を指定して作成 | resource GUID と private IP を記録済み |
| Databricks 登録 | Account console で endpoint 登録 | Pending 状態が解消または想定ステータスに進む |
| DNS設定 | privatelink.azuredatabricks.net に <region>.service-direct を追加 | nslookup で private IP が返る |
| public access 判断 | public network access を残すか無効化するか決定 | セキュリティ要件と運用手順が一致している |
| 監視・運用 | 接続失敗時の確認手順を整備 | DNS、NSG、ルート、認証の切り分け手順がある |
実務でのおすすめ対応
まずは、Azure Databricks の利用台帳から Lakebase Autoscaling と Zerobus Ingest の利用予定を確認してください。次に、接続元がワークスペース内なのか、外部アプリケーションなのか、Postgres クライアントを使うのか、Data API だけなのかを分類します。
そのうえで、対象となるリージョンごとに Private Link Service Resource ID、Private Endpoint 配置先サブネット、Private DNS Zone、A レコード名を設計します。日本環境だけでなく、米国、欧州、APAC にワークスペースを展開している場合は、リージョンごとの設定差分を Excel やリポジトリで管理するより、Bicep、Terraform、Azure Verified Modules などの IaC に落とし込むほうが安全です。
最後に、Private Link 構成後すぐに public access を無効化するのではなく、検証環境で次の順に確認することをおすすめします。
nslookup <region>.service-direct.privatelink.azuredatabricks.netdig <region>.service-direct.privatelink.azuredatabricks.net名前解決が private IP を返すことを確認したら、実際のクライアント、ドライバー、ORM で接続テストを行います。Lakebase Autoscaling の場合は、接続文字列の種類によって必要な endpoint が異なるため、テストでは本番と同じ接続文字列、同じDNS経路、同じネットワークセグメントを使うことが重要です。
まとめ：通常の Private Link と分けて設計することが重要
今回の「Configure inbound Private Link for performance-intensive services」は、Azure Databricks の高負荷サービスを閉域網から安全に使うための重要な更新ポイントです。特に Lakebase Autoscaling や Zerobus Ingest を利用する組織では、従来のワークスペース向け inbound Private Link だけで要件を満たせるかを再確認する必要があります。
管理者が最初に行うべきことは、対象サービスの利用有無、接続方式、リージョン、DNS設計、public access の扱いを棚卸しすることです。公式ドキュメントに明確な移行期限は示されていないものの、Public Preview の段階から検証しておけば、一般提供後の仕様確定やセキュリティ要件の変更にも対応しやすくなります。
特に本番環境では、「Private Endpoint を作成した」だけで完了とせず、Databricks 側の登録、service_direct の指定、Private DNS Zone の A レコード、名前解決、アプリケーション疎通、public network access の設定までを一連のチェックとして運用に組み込んでください。
コメント