「Configure Inbound Private Link – Azure Databricks」は、Azure DatabricksのワークスペースUI、REST API、Databricks Connect APIなど、ユーザーからワークスペースへ入る通信をPrivate Link経由にするための設定です。結論から言うと、確認すべきポイントは「databricks_ui_api private endpoint」「browser_authentication private endpoint」「Private DNS」「既存ワークスペース更新時の停止計画」の4つです。特に既存環境では、DNSやSSO認証用エンドポイントを後回しにすると、ログインできない、APIだけ通らない、社内ネットワークから名前解決できないといった障害につながります。
Microsoft Learnの該当ページは2026年5月時点で更新されており、Inbound Private Linkをハイブリッドアクセス構成で実装する流れが整理されています。この記事では、Azure Networkingの観点から「何が変わるのか」「どの管理者・開発者に影響するのか」「移行・展開前に何を確認すべきか」を、実務で使えるチェックリスト付きで解説します。(Microsoft Learn)
Azure Networkingの「Configure Inbound Private Link – Azure Databricks」は何が変わるのか
今回のポイントは、Azure DatabricksのPrivate Link設計を「ユーザーからワークスペースへの入口」として明確に分けて考える必要がある点です。
Azure DatabricksのPrivate Linkには、大きく分けて次の3種類があります。
| 種類 | 主な目的 | 対象通信 |
|---|---|---|
| Inbound / front-end | ユーザーやアプリからワークスペースへの接続を保護 | Workspace UI、REST API、Databricks Connect API |
| Outbound / serverless | Serverless computeからAzureリソースへの接続を保護 | Azure Storage、Azure SQLなどへの接続 |
| Classic / back-end | Classic computeからDatabricks control planeへの接続を保護 | クラスターとcontrol plane間の通信 |
Inbound Private Linkは、ユーザーがAzure Databricksワークスペースへアクセスする経路をPrivate Endpoint経由にする設定です。つまり、データソースへの接続やClassic computeのバックエンド通信を直接保護する設定ではありません。Azure Databricks公式のPrivate Link概念ページでも、Inbound、Outbound、Classicはそれぞれ独立または組み合わせて利用できる構成として整理されています。(Microsoft Learn)
管理者がまず押さえるべき変更点は、「Azure DatabricksをPrivate Link化する」と一言でまとめず、どの通信をPrivate Link化するのかを分けて設計することです。たとえば、ユーザーのブラウザアクセスだけをPrivate Link化したいのか、Serverless computeのデータアクセスも閉域化したいのか、Classic computeのcontrol plane通信まで閉域化したいのかで、必要なPrivate EndpointやDNS設計が変わります。
Inbound Private Linkで保護される範囲
Inbound Private Linkで保護されるのは、ユーザーやクライアントアプリケーションからAzure Databricksワークスペースへ入る通信です。公式情報では、Azure Databricks Webアプリケーション、REST API、Databricks Connect APIへの安全なアクセスに利用できると説明されています。(Microsoft Learn)
| 項目 | Inbound Private Linkの対象か | 実務上の確認ポイント |
|---|---|---|
| Workspace UIへのブラウザアクセス | 対象 | SSO用のbrowser_authentication endpointが必要 |
| REST APIアクセス | 対象 | CI/CD、外部ツール、管理スクリプトの接続元を確認 |
| Databricks Connect API | 対象 | 開発者PCや踏み台環境からの到達性を確認 |
| Serverless computeからAzure Storageへの接続 | 対象外 | Outbound Private LinkやNCCの検討が必要 |
| Classic computeからcontrol planeへの接続 | 対象外 | Classic compute plane Private Linkを別途検討 |
| ワークスペース外のSaaS連携 | 条件次第 | IP固定不可のSaaSはcontext-based ingress controlも検討 |
よくある誤解は、「Inbound Private Linkを設定すればAzure Databricks全体の通信がすべて閉域化される」と考えてしまうことです。完全なプライベート化を目指す場合は、InboundだけでなくClassic compute plane Private LinkやServerless向けのPrivate Link構成も含めて検討する必要があります。公式手順でも、No public access構成で完全なトラフィックプライベート化を行うにはClassic compute plane Private Link接続も必要とされています。(Microsoft Learn)
対象となる管理者・開発者
この更新は、Azure Databricksを利用する全ユーザーに一律で作業を求めるものではありません。影響が大きいのは、ネットワーク境界、認証、ワークスペース運用を管理しているチームです。
| 対象者 | 確認すべき内容 |
|---|---|
| Azureネットワーク管理者 | Transit VNet、Private Endpoint subnet、Private DNS zone、条件付きフォワーダー |
| Azure Databricks管理者 | ワークスペースのPremiumプラン、VNet injection、Public Network Access設定 |
| セキュリティ管理者 | Public accessを残すか、context-based ingress controlやIP access listで制限するか |
| ID管理者 | SSOログインでbrowser_authentication private endpointが必要か |
| 開発者・DevOps担当者 | REST API、CLI、CI/CD、Databricks Connectの接続元がPrivate Link経由で到達できるか |
| 運用担当者 | 既存ワークスペース更新時の停止時間、検証手順、ロールバック方針 |
特に開発者は、UIにログインできるかだけでなく、Databricks CLI、Terraform、CI/CDパイプライン、JDBC/ODBC接続などがどのネットワーク経路から実行されているかを確認する必要があります。Private Link化後に「管理者は社内VPNから入れるが、GitHub Actionsや外部SaaSからAPIが失敗する」といった状況が起きやすいためです。
実装前に確認すべき前提条件
公式手順では、Inbound Private Linkの構成前に、ワークスペースがPremium planであること、VNet injectionを利用していること、Private EndpointやDNSレコードを管理できるAzure権限があることが要件として示されています。(Microsoft Learn)
| 確認項目 | 必須度 | 確認内容 |
|---|---|---|
| Premium plan | 必須 | Azure DatabricksワークスペースがPremium planか |
| VNet injection | 必須 | ワークスペースが自社管理VNetにデプロイされているか |
| Secure cluster connectivity | 推奨・構成上重要 | No Public IPが有効か |
| Transit VNet | 必須 | ユーザー通信、オンプレミス接続、Private Endpointを集約できるか |
| Azure DNSによるPrivate DNS管理 | 必須に近い | privatelink.azuredatabricks.netを管理できるか |
| Azure権限 | 必須 | Private Endpoint作成、DNSレコード管理、VNet設定変更ができるか |
| 停止計画 | 既存環境では必須 | クラスター、プール、Classic SQL Warehouseを停止できる時間帯があるか |
既存ワークスペースに構成する場合、作業前にクラスター、プール、Classic SQL Warehouseなどのコンピュートリソースを停止する必要があります。公式手順では、実行中のコンピュートリソースがあるとアップグレードが失敗するため、ダウンタイムを計画することが推奨されています。(Microsoft Learn)
アクセスモデルは「No public access」と「Hybrid access」から選ぶ
Inbound Private Linkの設計では、まずPublic accessを完全に無効化するのか、Private LinkとPublic accessを併用するのかを決めます。
| モデル | 向いているケース | 注意点 |
|---|---|---|
| No public access | 金融、医療、個人情報、厳格な社内閉域要件がある環境 | すべてのユーザー・運用ツールがPrivate Endpoint経由で到達できる必要がある |
| Hybrid access | 段階移行、社外SaaS連携、固定IPの拠点アクセスを残したい環境 | Public accessを残すため、context-based ingress controlやIP access listで制御する |
公式のConfigure Inbound Private Link手順は、Private Linkを有効にしつつPublic accessを残し、context-based ingress controlやIP access listで信頼済みの公開経路を制御するHybrid accessモデルを前提に説明されています。(Microsoft Learn)
実務では、最初からNo public accessに切り替えるより、Hybrid accessで名前解決、SSO、API、運用ツールの接続を検証し、段階的にPublic accessの範囲を絞る方が安全です。特に複数拠点、VPN、ExpressRoute、外部CI/CD、SaaS監視ツールが絡む環境では、Public accessを一度に閉じると業務影響の切り分けが難しくなります。
設定手順の全体像
既存ワークスペースでは最初にコンピュートを停止する
既存ワークスペースへPrivate Link設定を追加する場合は、作業前にアクティブなクラスター、プール、Classic SQL Warehouseを停止します。停止せずに進めると更新が失敗する可能性があるため、運用チームと利用部門に影響時間を共有してから作業します。(Microsoft Learn)
作業前チェックとして、以下を記録しておくとトラブル時の切り戻しが容易です。
| 記録する項目 | 理由 |
|---|---|
| ワークスペースURL | DNS変更後の名前解決確認に使う |
| 現在のPublic Network Access設定 | 切り戻し判断に必要 |
| 稼働中クラスター一覧 | 停止漏れ防止 |
| 利用中のCI/CD・CLI接続元 | API接続失敗の切り分けに必要 |
| DNSサーバー構成 | 社内DNSとAzure Private DNSの連携確認に必要 |
ワークスペースのネットワーク設定を確認する
Azure portalでAzure Databricksワークスペースを開き、Networkingタブから次の設定を確認します。
| 設定 | 確認内容 |
|---|---|
| Secure cluster connectivity / No Public IP | Enabledになっているか |
| Allow Public Network Access | Hybrid accessではEnabledになっているか |
| VNet injection | 自社管理VNetを利用しているか |
| Region | Private Endpoint、VNet、DNS設計と一致しているか |
Hybrid accessではPublic Network Accessを有効にしたまま、Private Link、context-based ingress control、IP access listでアクセス元を制限します。Public accessを残すこと自体が悪いわけではありませんが、「誰が、どこから、どの機能にアクセスできるか」を明示的に制御する必要があります。
databricks_ui_api private endpointを作成する
Inbound Private Linkの中心になるのが、databricks_ui_api private endpointです。これはワークスペースUI/APIへの通信をPrivate Endpoint経由にするためのエンドポイントです。
作成時の主な確認点は次のとおりです。
| 項目 | 推奨設定・確認内容 |
|---|---|
| Target sub-resource | databricks_ui_api |
| 配置先VNet | Transit VNet |
| 配置先subnet | Private Endpoint用subnet |
| Region | ワークスペースと同一リージョン |
| Private DNS統合 | Yes |
| Private DNS zone | privatelink.azuredatabricks.net |
公式手順では、databricks_ui_apiのPrivate EndpointをTransit VNetに作成し、Private DNS zoneとしてprivatelink.azuredatabricks.netが自動選択されることを確認する流れが示されています。(Microsoft Learn)
ここで重要なのは、Private Endpointを作成しただけでは終わりではない点です。ユーザーのPC、VPN接続先、踏み台VM、オンプレミスDNSから、ワークスペースURLがPrivate IPに解決される必要があります。
SSO用のbrowser_authentication private endpointを用意する
ブラウザでSSOログインを行う場合、browser_authentication private endpointが重要です。Azure Databricks公式のPrivate Link概念ページでは、front-end accessでPrivate Linkを使う場合、WebブラウザログインのSSOをPrivate接続で機能させるために専用のbrowser_authentication endpointが必要と説明されています。(Microsoft Learn)
本番環境では、通常の業務ワークスペースとは別に、認証専用の「private web auth workspace」を用意する構成が推奨されます。理由は単純で、認証用endpointをホストしているワークスペースを誤って削除すると、同じリージョンとPrivate DNS zoneを共有するワークスペースのWebログインに影響する可能性があるためです。(Microsoft Learn)
認証専用ワークスペースでは、次の運用ルールを徹底します。
| ルール | 理由 |
|---|---|
| ワークロードを実行しない | 認証専用の安定性を優先する |
browser_authentication以外のPrivate Endpointを作らない | 役割を混在させない |
| Public Network AccessをDisabledにする | 認証用ホストの露出を減らす |
| 削除ロックを設定する | 誤削除によるログイン障害を防ぐ |
| リージョンごとに設計する | Private Endpointはリージョン単位で考える必要がある |
小規模な検証環境では既存ワークスペースにbrowser_authentication endpointを持たせることも考えられますが、本番環境では認証専用ワークスペースを分離した方が運用リスクを抑えられます。
DNS設定で確認すべきポイント
Inbound Private Linkの成否は、最終的にDNSで決まります。Private Endpointが正しく作成されていても、クライアントがPublic IPに名前解決していると、期待した閉域アクセスにはなりません。
公式手順では、Private Endpoint作成後にprivatelink.azuredatabricks.netのPrivate DNS zoneを確認し、ワークスペースUI/API用レコードとブラウザ認証用レコードがPrivate IPを指していることを検証する流れが示されています。(Microsoft Learn)
Azure DNSを使う場合
Azure Private DNS zoneを利用する場合は、少なくとも次を確認します。
| レコード | 役割 |
|---|---|
adb-xxxxxxxxxxxxxxxx.x | ワークスペースUI/API用 |
pl-auth.<region>など | ブラウザ認証用 |
| VNet link | Transit VNetからPrivate DNS zoneを参照できるか |
ワークスペースURLに対してnslookupを実行し、adb-xxxxxxxxxxxxxxxx.x.privatelink.azuredatabricks.netに解決され、Private EndpointのPrivate IPが返ることを確認します。公式手順でも、VNet内VMまたはVPN/ExpressRoute接続環境からnslookupでPrivate IPに解決されるかを確認する例が示されています。(Microsoft Learn)
カスタムDNSを使う場合
社内DNSや独自DNSを使っている場合は、条件付きフォワーダーの設計が重要です。公式手順では、信頼性の高い方法としてDatabricks関連ドメインをAzure内部DNSへフォワードする構成が推奨されています。対象には、*.azuredatabricks.net、*.privatelink.azuredatabricks.net、*.databricksapps.comが含まれます。(Microsoft Learn)
条件付きフォワーダーを使えない場合は、手動でAレコードを作成する選択肢もあります。ただし、SSO認証URLはリージョンやcontrol plane構成により複数レコードが必要になる可能性があるため、手動管理は運用負荷が高くなります。大規模環境では、手動Aレコードより条件付きフォワーダーを優先した方が安全です。
context-based ingress controlとIP access listの使い分け
Hybrid accessではPublic accessを完全には閉じないため、Private Link以外のアクセス制御も必要です。ここで重要になるのが、context-based ingress controlとIP access listです。
context-based ingress controlは、誰がアクセスしているか、どこからアクセスしているか、どの種類のリクエストかを組み合わせて許可・拒否を設定する機能です。公式情報では、IP access listやfrontend private connectivityと連携し、ID、リクエスト種別、ネットワークソースの組み合わせで制御できると説明されています。(Microsoft Learn)
| 制御 | 向いている用途 | 注意点 |
|---|---|---|
| context-based ingress control | ID、API/UI種別、接続元を組み合わせた制御 | Public Previewの機能として扱われているため採用時は仕様確認が必要 |
| IP access list | 固定IP・CIDR単位の制限 | IPだけではユーザーやAPI種別を区別できない |
| Private Link | 社内VNetやオンプレミスからの閉域アクセス | DNS、SSO、Private Endpoint設計が必要 |
Workspace IP access listとaccount-level context-based ingress controlは併用され、リクエストは両方で許可される必要があります。IP access listは追加の絞り込みには使えますが、context-based ingress controlで拒否されたアクセスを広げることはできません。(Microsoft Learn)
実務では、まずcontext-based ingress controlをdry run modeで適用し、ログを見ながら影響範囲を確認してからEnforcedに切り替えるのが安全です。公式情報でも、dry run modeは違反をログに記録するがブロックしないモードとして説明されています。(Microsoft Learn)
既存環境で失敗しやすいポイント
Public accessを急に無効化して運用ツールが止まる
最も多い失敗は、Private Linkの動作確認前にPublic Network Accessを無効化してしまうことです。管理者のブラウザログインは成功しても、外部CI/CD、監視SaaS、管理スクリプト、JDBC/ODBC接続がPublic経路に依存している場合があります。
切り替え前に、次の接続元を洗い出してください。
| 接続元 | 確認内容 |
|---|---|
| 管理者PC | VPNまたはExpressRoute経由でPrivate IPに解決されるか |
| 開発者PC | Databricks ConnectやCLIが利用できるか |
| CI/CD | 実行環境がPrivate Link経由で到達できるか |
| 監視ツール | API接続元IPまたはPrivate接続方式を確認 |
| BIツール | JDBC/ODBC接続先がPrivate経路に対応しているか |
SSO用endpointを忘れる
databricks_ui_api endpointだけを作成し、browser_authentication endpointを忘れると、API疎通は見えてもブラウザログインで詰まる可能性があります。Inbound Private Linkでは、UI/API用endpointとSSO用endpointを別の役割として考えることが重要です。
DNSの確認をAzure VMだけで終える
Azure上のテストVMでは名前解決できても、オンプレミスPCやVPN接続端末では社内DNSの条件付きフォワーダーが未設定でPublic側に解決されることがあります。検証は必ず、実際の利用者に近いネットワークから行います。
確認すべき場所は次の3つです。
| 検証場所 | 理由 |
|---|---|
| Transit VNet内のテストVM | Azure内部のPrivate DNS連携を確認 |
| VPN/ExpressRoute接続端末 | 社内ユーザーの実利用経路を確認 |
| CI/CDや運用自動化の実行環境 | API・CLIの継続利用を確認 |
NSGやFirewallで必要通信を落とす
Private Endpoint subnetにNSGポリシーを適用している場合、必要なポートを誤ってブロックすることがあります。Azure DatabricksのPrivate Link概念ページでは、Private EndpointにNSGポリシーが有効な場合、443、6666、3306、8443から8451をInbound Security Rulesで許可する必要があるとされています。(Microsoft Learn)
ただし、すべての環境で同じFirewall設計が最適とは限りません。社内プロキシ、Azure Firewall、Private DNS Resolver、ExpressRouteの経路制御がある場合は、通信経路図を作ってからルールを適用する方が安全です。
展開前チェックリスト
作業前には、次の項目を確認してから変更を開始してください。
| チェック項目 | 確認済み |
|---|---|
| ワークスペースがPremium planである | □ |
| VNet injectionを利用している | □ |
| Transit VNetとPrivate Endpoint用subnetを用意した | □ |
databricks_ui_api private endpointの配置先を決めた | □ |
browser_authentication private endpointのホスト方針を決めた | □ |
| 本番では認証専用ワークスペースを作成し、削除ロックを設定する | □ |
privatelink.azuredatabricks.netのPrivate DNS zoneを確認した | □ |
| カスタムDNS利用時の条件付きフォワーダーを設計した | □ |
| 既存クラスター、プール、Classic SQL Warehouseの停止時間を確保した | □ |
| VPN、ExpressRoute、踏み台VM、CI/CDからの接続確認手順を用意した | □ |
| context-based ingress controlまたはIP access listの方針を決めた | □ |
| 影響が出る開発者、運用担当、BI利用者へ周知した | □ |
このチェックリストで特に重要なのは、Private Endpoint作成そのものではなく「利用者の実ネットワークからPrivate IPに解決されるか」「SSOログインできるか」「APIや自動化が止まらないか」です。Azure portal上で設定が成功していても、実利用経路で検証していなければ移行完了とは言えません。
管理者と開発者が次に取るべき行動
まず、現在のAzure Databricks環境で「何をPrivate Link化したいのか」を整理してください。ユーザーのUI/APIアクセスだけならInbound Private Linkが中心です。Serverless computeからAzureリソースへの接続を閉域化したい場合はOutbound Private Link、Classic computeのcontrol plane通信を閉域化したい場合はClassic compute plane Private Linkも検討します。
次に、Hybrid accessで段階的に検証するか、No public accessで厳格に閉域化するかを決めます。多くの既存環境では、まずHybrid accessでdatabricks_ui_api、browser_authentication、DNS、SSO、API、CI/CDを確認し、その後にPublic accessの制限を強める進め方が現実的です。
最後に、作業手順を「設定作業」ではなく「移行プロジェクト」として扱ってください。Inbound Private Linkはネットワーク、認証、DNS、Databricks管理、開発者ツールが交差する設定です。Private Endpointを作成するだけでなく、利用者の接続経路、DNSの解決結果、SSOの動作、API自動化の継続性まで確認してから本番展開することが、トラブルを避ける最短ルートです。
コメント