Azure Databricks のネットワーク設定は、従来の「ワークスペースにアクセスできるか」「クラシック クラスターが動くか」だけでなく、サーバーレス コンピューティングから Azure Storage や Azure SQL などへ安全に到達できるかまで確認が必要になっています。特に 2026年7月2日に更新された公式情報では、サーバーレス通信の識別、Network Security Perimeter、AzureDatabricksServerless サービス タグ、NCC、Private Link、ネットワーク コストの扱いが重要な確認ポイントです。(Microsoft Learn)
結論から言うと、Azure Databricks を運用している管理者は、まず サーバーレス ワークロードが使うデータソースのファイアウォール設定、既存の IP 許可リスト運用、Private Link / NCC の設定状態、Secure Cluster Connectivity と NAT Gateway の有無を確認すべきです。期限がすでに到来している変更もあるため、「次回更改時に見る」ではなく、現在の本番ワークスペースを棚卸しするところから始めるのが安全です。
Azure Databricks Networking の更新ポイントを一言で整理
Azure Databricks の Networking は、ワークスペースへの入口、コンピューティング プレーン、データソースへの出口をまとめて設計するための公式ガイドです。Microsoft Learn では、Databricks が既定でセキュアなネットワーク環境を提供しつつ、必要に応じてワークスペース アクセス、コントロール プレーンとコンピューティング プレーンの接続、データソースへの接続を追加制御できると説明しています。(Microsoft Learn)
実務上は、次の 3 つの通信を分けて考えると理解しやすくなります。
| 観点 | 主な通信 | 管理者が見るべき設定 |
|---|---|---|
| Inbound | ユーザー、API、BI ツールから Azure Databricks へのアクセス | IP access lists、Context-based ingress control、Inbound Private Link、DNS、SSO |
| Classic compute | クラシック クラスターと Databricks コントロール プレーンの通信 | VNet injection、Secure Cluster Connectivity、NSG、UDR、NAT Gateway、Back-end Private Link |
| Serverless outbound | Serverless SQL Warehouse、Jobs、Notebooks、Model Serving などから Azure Storage や外部サービスへの通信 | NCC、Private endpoint rules、NSP、AzureDatabricksServerless サービス タグ、ネットワーク ポリシー |
今回の更新で特に重要なのは、3つ目の Serverless outbound です。サーバーレス ワークロードは Databricks 管理のサーバーレス コンピューティング プレーンで動作し、接続先の場所・種類・構成に応じて service endpoints、private IP、public IP を使い分けます。ストレージやデータベースをファイアウォールで保護している環境では、この通信経路を明示的に許可しないと、ジョブや SQL クエリが突然失敗する可能性があります。(Microsoft Learn)
影響範囲：誰が確認すべきか
今回の Networking – Azure Databricks の確認対象は、Azure Databricks を「使っている人」ではなく、主に ワークスペース管理者、Azure ネットワーク管理者、セキュリティ管理者、データ基盤運用担当者です。特に影響を受けやすいのは、次のような構成です。
| 対象 | 影響を受けやすい理由 | 確認ポイント |
|---|---|---|
| Serverless SQL Warehouse を利用している環境 | サーバーレスからストレージや外部サービスへ接続する通信が制御対象になる | Storage firewall、NSP、サービス タグ、NCC |
| ADLS Gen2 / Azure Storage をファイアウォールで保護している環境 | 旧来のサブネット ID 許可や手動 IP 許可のままだと接続失敗の原因になる | AzureDatabricksServerless の地域別サービス タグ、NSP |
| Model Serving や Lakeflow を使う環境 | モデル ビルド時やパイプライン実行時に外部依存関係へアクセスする | ネットワーク ポリシー、許可 FQDN、拒否ログ |
| VNet injection のクラシック ワークスペース | 新規 VNet のアウトバウンド既定変更や SCC の将来必須化に備える必要がある | NAT Gateway、Secure Cluster Connectivity、NSG |
| Private Link 前提の閉域環境 | DNS、SSO、Private endpoint の不足でログインやクラスタ起動に失敗しやすい | databricks_ui_api、browser_authentication、Private DNS |
クラシック コンピューティングだけを使っている場合でも、将来的な Secure Cluster Connectivity 必須化や Azure Databricks 管理 VNet の非推奨化予定が案内されています。Microsoft Learn の “What’s coming?” では、詳細な移行タイムラインは別途案内予定とされているため、現時点で確定日を断定せず、設計方針として VNet injection と Secure Cluster Connectivity を前提に寄せておくのが現実的です。(Microsoft Learn)
サーバーレス通信は NCC と NSP を中心に見直す
Azure Databricks のサーバーレス ネットワークでは、Network Connectivity Configuration（NCC） が重要な管理単位になります。NCC はアカウント レベルかつリージョン単位の構成で、サーバーレス コンピューティングからユーザー管理の Azure リソースへ接続するための Private Endpoint やファイアウォール連携を管理します。1つの NCC は同一リージョンの複数ワークスペースに関連付けられます。(Microsoft Learn)
NCC を使う場合の基本的な流れは、次の通りです。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| NCC を作成 | Azure Databricks account console の Security から Network connectivity configuration を作成 | ワークスペースと NCC のリージョンが一致していない |
| ワークスペースに関連付け | 対象ワークスペースの Network connectivity configurations に NCC を選択 | 反映後にサーバーレス サービスの再起動を忘れる |
| Private endpoint rule を作成 | Azure Storage、Azure SQL、Key Vault などのリソース ID と subresource ID を指定 | Storage で blob と dfs のどちらが必要か整理していない |
| リソース側で承認 | Azure 側の Private endpoint connections で接続要求を承認 | PENDING のまま放置し、接続できないのに課金対象になる |
| 接続を検証 | SQL、Notebook、Job、Model Serving など実際のワークロードで確認 | DNS とネットワーク ポリシーの両方を確認していない |
NCC private endpoints は、SQL warehouses、Jobs、Notebooks、Lakeflow Spark Declarative Pipelines、Model Serving endpoints などからサポートされます。アカウントとワークスペースは Premium plan が必要で、Azure では 1アカウントあたりリージョンごとに最大 10 NCC、リージョンごとに最大 100 private endpoints、1 NCC あたり最大 50 ワークスペースという制限があります。(Microsoft Learn)
Azure Storage のファイアウォール設定は最優先で確認する
2026年7月時点で特に注意したいのが、Azure Storage をファイアウォールで保護している構成です。公式情報では、既存の Azure Storage アカウントで Azure Databricks サーバーレス サブネット ID を許可している場合、2026年6月9日までに Network Security Perimeter（NSP）へオンボードし、AzureDatabricksServerless サービス タグを許可する必要があるとされています。(Microsoft Learn)
すでに期限を過ぎているため、次のいずれかに該当する環境はすぐに確認してください。
- ADLS Gen2 のネットワーク設定で、古い Databricks サーバーレス サブネット ID を許可している
- Serverless SQL Warehouse から Storage に接続している
- 以前に取得した安定 IP や手動コピーした NCC の IP をファイアウォールに登録している
- 同一リージョンの Storage に対して、サービス タグではなく個別 IP / サブネットで制御している
- 本番ジョブは動いているが、ステージングや DR リージョンの検証が未実施
NSP は、Azure PaaS リソースの論理的な分離境界を作る Azure の機能です。Azure Databricks から同一リージョンの Azure Storage にアクセスさせる場合、NSP の inbound access rule で AzureDatabricksServerless.[region] のような地域別サービス タグを使うと、グローバル タグよりも露出範囲を狭くできます。(Microsoft Learn)
NSP は enforced mode より transition mode から始める
NSP には transition mode と enforced mode があります。Azure Databricks の公式手順では、多くの用途で transition mode にとどめることが推奨されています。transition mode では NSP ルールを先に評価し、該当しない場合は既存のリソース ファイアウォール ルールへフォールバックします。一方、enforced mode は NSP ルールに合わない通信をブロックするため、Azure Databricks 以外の既存サービスまで巻き込む可能性があります。(Microsoft Learn)
本番環境では、いきなり enforced mode にするのではなく、次の順序で進めると安全です。
| フェーズ | 作業内容 | 判断基準 |
|---|---|---|
| 棚卸し | Databricks からアクセスする Storage アカウントを一覧化 | ワークスペース、リージョン、用途、所有者が分かる |
| NSP 作成 | Storage と同一リージョンで NSP と profile を作成 | profile ID を記録している |
| transition mode で関連付け | Storage を NSP に関連付ける | 既存通信が止まらない |
| inbound rule 追加 | 地域別 AzureDatabricksServerless を許可 | グローバル タグを安易に使っていない |
| 検証 | Serverless SQL / Notebook から実データへアクセス | 成功・失敗ログを確認できる |
| 監視 | Diagnostic settings や Log Analytics で確認 | 許可・拒否の理由を追える |
旧来の IP 許可リストは JSON 取得方式へ移行済みか確認する
Azure Databricks は、サーバーレスから Storage 以外のリソースへ接続する場合、公開されたアウトバウンド IP の CIDR ブロックをファイアウォールで許可する運用を案内しています。2026年2月中旬以降は、サポートされる取得方法として JSON 形式の公開エンドポイントが使われます。公式情報では、Public Preview の stable IP や account console からコピーした NCC の IP を使っている場合、2026年5月25日までに新方式へ移行する必要があり、移行が不完全だとワークロード中断の可能性があると説明されています。(Microsoft Learn)
この期限も 2026年7月時点では到来済みです。管理者は、次の観点で点検してください。
| 確認項目 | NG 例 | 推奨対応 |
|---|---|---|
| IP 情報の取得元 | ポータル画面から手動コピーした IP をそのまま使用 | 公開 JSON を定期取得して region / platform / type で抽出 |
| 更新頻度 | 一度だけ登録して放置 | 30日程度の間隔で差分確認を自動化 |
| 対象リージョン | US の IP だけ登録し、日本や EU のワークスペースを忘れる | ワークスペース リージョンごとに allowlist を管理 |
| 変更反映 | ファイアウォール変更後すぐ本番実行 | 伝播時間を考慮して検証環境で先に確認 |
| 責任分界 | Databricks 管理者だけが把握 | Azure Firewall / Storage / SQL 管理者と変更手順を共有 |
ポイントは、「今つながっているから問題ない」と判断しないことです。ネットワーク IP は時間とともに変わるため、手動運用のままでは次回更新時に接続障害が発生します。公式情報でも、IP は変わるため allowlist 更新の自動化が必要であり、新しい IP は公開後一定期間を経て有効化されることが説明されています。(Microsoft Learn)
Serverless egress control で外部通信を制御する
Azure Databricks の Serverless egress control は、サーバーレス ワークロードから外部ネットワークへ出る通信をネットワーク ポリシーで制御する機能です。ネットワーク ポリシーはアカウント レベルの設定で、複数ワークスペースに関連付けられますが、1つのワークスペースに同時に関連付けられるポリシーは1つです。Restricted Access にすると、Unity Catalog の external locations や明示的に許可した FQDN / Storage のみへ通信できます。(Microsoft Learn)
実務では、次のような使い分けが現実的です。
| 用途 | 推奨モード | 理由 |
|---|---|---|
| まず影響を調べたい | Dry-run | ブロックせずに違反ログを確認できる |
| 本番データを扱う SQL Warehouse | Restricted Access | 不要な外部通信を抑止しやすい |
| 既知の危険ドメインだけ止めたい | Full Access + blocked destinations | 全面制限せず軽量にブロックできる |
| Model Serving | Dry-run から開始 | モデル ビルド時の PyPI、conda、外部ファイル取得が失敗しやすい |
| 開発用 Notebook | 段階的に制限 | ライブラリ取得や検証用 API 呼び出しが多いため |
ネットワーク ポリシーには上限があります。公式情報では、サポートされる宛先は最大 2500、storage destinations はポリシーごとに 100、allowed domains はポリシーごとに 100 とされています。また、Private Link 経由の通信もポリシー対象になるため、「Private Endpoint を作ったからポリシーは不要」ではありません。(Microsoft Learn)
拒否ログは Unity Catalog の system table で確認する
Serverless egress control を適用する場合、拒否ログを見られる状態にしておくことが重要です。拒否ログは Unity Catalog の system.access.outbound_network テーブルに保存され、dry-run の違反も DRY_RUN_DENIAL として確認できます。(Microsoft Learn)
SELECT *
FROM system.access.outbound_network
WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
ORDER BY event_time DESC;本番適用前には、少なくとも SQL Warehouse、Jobs、Notebooks、Model Serving の代表ワークロードで検証し、拒否ログに出てくる FQDN や Storage をポリシーに反映する流れを作ってください。特に Model Serving は、推論時だけでなくコンテナ ビルド時の依存関係取得にもネットワーク ポリシーが効くため、必要なパッケージ リポジトリを許可していないとエンドポイント作成に失敗する可能性があります。(Microsoft Learn)
Private Link は「入口」「出口」「クラシック」の3種類で考える
Azure Databricks の Private Link は、1種類だけではありません。公式情報では、Inbound、Outbound、Classic compute plane の 3 種類の Private Link が整理されています。Inbound はユーザーからワークスペースへの接続、Outbound はサーバーレスから Azure リソースへの接続、Classic はクラシック クラスターからコントロール プレーンへの接続を保護します。(Microsoft Learn)
| Private Link の種類 | 守る通信 | 主な用途 |
|---|---|---|
| Inbound / front-end | ユーザー、REST API、Databricks Connect からワークスペース | 社内ネットワークからのみ Databricks UI / API を使わせる |
| Outbound / serverless | Serverless compute から Azure Storage、Azure SQL、Key Vault など | データソースを public internet に出さず接続する |
| Classic / back-end | クラシック クラスターから Databricks コントロール プレーン | 規制業界や閉域構成でクラスタ制御通信を私設化する |
Inbound Private Link を使う場合は、databricks_ui_api endpoint だけでなく、ブラウザ SSO 用の browser_authentication endpoint が重要です。公式手順では、プロダクション リージョンごとに専用の “private web auth workspace” を作成し、削除ロックをかけることが推奨されています。このワークスペースを削除すると、同じリージョンで依存しているワークスペースの Web ログインが失敗する可能性があります。(Microsoft Learn)
DNS の検証を省略すると Private Link は失敗しやすい
Private Link の構成で最も多い失敗は、Private Endpoint の作成後に DNS 検証を省略することです。Inbound Private Link では、privatelink.azuredatabricks.net の Private DNS zone にワークスペース UI/API と browser authentication の A レコードが作成され、ワークスペース URL が private IP に解決される必要があります。カスタム DNS を使う場合は、*.azuredatabricks.net、*.privatelink.azuredatabricks.net、*.databricksapps.com などの条件付きフォワーディングを確認します。(Microsoft Learn)
本番切替前には、VPN または ExpressRoute で接続された端末、もしくは transit VNet 上のテスト VM から、ログイン、REST API、SQL 接続、Notebook 実行まで確認してください。nslookup で private IP に解決されていても、SSO、プロキシ、ブラウザ認証 endpoint の設定が不足していると、実際のログインで失敗することがあります。
Ingress 制御は IP access lists だけに頼らない
ユーザーから Azure Databricks へのアクセス制御では、IP access lists に加えて、Context-based ingress control が重要になっています。Context-based ingress control は Public Preview の機能で、ID、リクエスト種別、ネットワーク送信元を組み合わせて、ワークスペース UI、API、Apps、Lakebase Compute などへのアクセスを制御します。(Microsoft Learn)
従来の IP access lists は、固定の社内 IP からのみアクセスを許可する用途では有効です。一方で、SaaS クライアントや自動化基盤のように送信元 IP が変わりやすい環境では、IP だけでは運用が難しくなります。Context-based ingress control を使うと、特定のサービス プリンシパルは高信頼ネットワークからの API アクセスだけ許可する、といった制御ができます。
導入時は、まず dry-run mode で開始し、system.access.inbound_network の拒否ログを確認します。公式情報では、Workspace IP access lists と context-based ingress policy は併用され、両方が許可しなければリクエストは通らないと説明されています。また、Allow Public Network Access を Disabled にした場合、public ingress はすべてブロックされ、ingress policy は評価されません。(Microsoft Learn)
クラシック ワークスペースは VNet injection と SCC を前提にする
クラシック コンピューティングを使う Azure Databricks では、VNet injection と Secure Cluster Connectivity（SCC / No Public IP）を前提に設計する流れが強まっています。Classic compute plane networking の公式情報では、将来のリリースで Azure Databricks 管理 VNet によるクラシック ワークスペース作成を非推奨化する予定であり、新しいクラシック ワークスペースでは VNet injection が求められる方向であると説明されています。(Microsoft Learn)
VNet injection を使うと、Azure Databricks のクラシック コンピューティング リソースを自社管理の VNet に配置できます。これにより、サービス エンドポイントや Private Endpoint による Azure サービス接続、オンプレミス接続、Network Virtual Appliance による検査、カスタム DNS、NSG による追加の egress 制御が可能になります。(Microsoft Learn)
SCC を有効にすると、クラシック コンピューティング プレーンのリソースに public IP が付かず、クラスターからコントロール プレーンへアウトバウンドで接続します。既存ワークスペースに SCC を追加する場合は、VNet injection が前提で、クラシック クラスター、プール、クラシック SQL Warehouse などを停止してから更新する必要があります。ネットワーク更新には 15分を超える時間がかかる場合があります。(Microsoft Learn)
2026年3月31日以降の新規 VNet は NAT Gateway を確認する
Microsoft は、2026年3月31日以降、新しい Azure VNet が既定で outbound internet access を持たない private configuration になることを案内しています。Azure Databricks の公式情報でも、同日以降に新しい Azure Databricks ワークスペースをデプロイする場合、正常なクラスタ動作のために NAT Gateway などの明示的なアウトバウンド接続方式が必要になると説明されています。既存ワークスペースはこの変更の影響を受けないとされています。(Microsoft Learn)
新規構築時は、次の項目を標準チェックに入れてください。
| 項目 | 確認内容 |
|---|---|
| VNet とワークスペースのリージョン | 同一リージョンか |
| サブネット | host subnet と container subnet を分離し、十分な CIDR を確保しているか |
| NAT Gateway | 両方のワークスペース サブネットに関連付けているか |
| NSG | Databricks が必要とする管理ルールを削除していないか |
| DNS | Private Link や社内 DNS と矛盾していないか |
| SCC | No Public IP が有効か |
| 既存自動化 | ARM / Terraform が古い enableNoPublicIp=false や NAT 未設定を前提にしていないか |
ネットワーク コストも設計段階で見積もる
Azure Databricks の Networking は、セキュリティだけでなくコストにも影響します。公式情報では、ネットワーク料金は Azure Databricks serverless compute を使う顧客に適用され、サーバーレスがユーザー リソースと通信するときにデータ転送と接続コストが発生すると説明されています。クラシック コンピューティングのネットワーク コストは、顧客が Azure 側で直接管理・負担する扱いです。(Microsoft Learn)
特に注意すべきなのは、Private Link を使えばすべて無料になるわけではない点です。公式情報では、Private Connectivity の時間課金、Public Connectivity の GB 課金、Data Transfer の GB 課金などが整理されています。一方で、Storage を NSP に追加し、AzureDatabricksServerless サービス タグを許可して service endpoints 経由で通信する場合、当該通信にはデータ処理料金が発生しないと説明されています。ただし、クロスリージョン Storage アクセスではデータ転送料金が引き続き発生します。(Microsoft Learn)
コストを抑える基本は、ワークスペースとデータソースを同一リージョンにそろえることです。グローバル企業では、米国、欧州、日本、アジア太平洋などのリージョンごとに NCC、NSP、Private Endpoint、サービス タグを分けて管理し、中央集約型の 1 リージョン設計にしすぎない方が、性能・コスト・データ所在の面で安定します。
管理者が今すぐ確認すべきチェックリスト
Azure Databricks Networking の変更点を実務に落とし込むなら、次の順で確認すると抜け漏れを減らせます。
| 優先度 | 確認項目 | 具体的な作業 |
|---|---|---|
| 高 | サーバーレスから Storage への接続 | Storage firewall、NSP、AzureDatabricksServerless 地域別タグを確認 |
| 高 | 古い IP 許可リスト | 手動コピーした stable IP や NCC IP が残っていないか確認 |
| 高 | 本番ワークスペースのリージョン | NCC、NSP、Storage、Private Endpoint が同一リージョン前提で設計されているか確認 |
| 高 | ワークロード検証 | Serverless SQL、Jobs、Notebooks、Model Serving の代表処理を実行 |
| 中 | Network policies | Dry-run で拒否ログを集め、必要な FQDN / Storage を許可 |
| 中 | Private Link | databricks_ui_api、browser_authentication、DNS、SSO を確認 |
| 中 | クラシック compute | VNet injection、SCC、NAT Gateway、NSG を確認 |
| 中 | コスト | Private Endpoint 時間課金、public connectivity、cross-region transfer を確認 |
| 低 | 将来変更への備え | 管理 VNet 非推奨化予定、SCC 必須化予定に合わせ IaC を更新 |
このチェックリストで重要なのは、Databricks 管理者だけで完結させないことです。Storage firewall はデータ基盤チーム、NSP は Azure ネットワーク チーム、Private Endpoint 承認はリソース所有者、ネットワーク ポリシーはセキュリティ管理者が関わることが多いため、変更手順とロールバック手順を共有してから適用してください。
移行期限と対応優先度
2026年7月時点で、すでに対応期限を過ぎているものがあります。未対応の場合は、障害が起きてから調べるのではなく、現在の設定を先に確認する必要があります。
| 日付・時期 | 内容 | 状態 | 対応 |
|---|---|---|---|
| 2026年3月31日以降 | 新しい Azure VNet は既定で outbound internet access を持たない構成へ | すでに適用時期 | 新規 Databricks VNet には NAT Gateway などを明示 |
| 2026年5月25日 | 旧 stable IP / NCC 画面コピー IP から JSON 取得方式へ移行 | 期限到来済み | ファイアウォール許可リストを棚卸し |
| 2026年6月9日 | Storage で Databricks serverless subnet ID を許可している場合、NSP と AzureDatabricksServerless タグへ移行 | 期限到来済み | Storage account ごとに NSP 関連付けを確認 |
| 将来リリース | Secure Cluster Connectivity が classic workspace で必須化予定 | 詳細期限未公表 | enableNoPublicIp=false のワークスペースを洗い出す |
| 将来リリース | Azure Databricks 管理 VNet による classic workspace 作成が非推奨化予定 | 詳細期限未公表 | 新規 classic workspace は VNet injection 前提で設計 |
この表で最も危険なのは、2026年5月25日と6月9日の項目です。どちらも「新機能を使うかどうか」ではなく、既存のサーバーレス通信が将来のネットワーク更新で不安定になる可能性に関係します。特に本番だけでなく、バックアップ環境、DR 環境、検証環境、海外リージョンのワークスペースまで同じ基準で確認してください。
よくある失敗と回避策
旧 IP 許可のまま運用している
サーバーレスの送信元 IP を一度だけ登録して放置すると、IP 更新時に接続できなくなる可能性があります。公開 JSON の定期取得と差分反映を自動化し、変更履歴を残してください。
Storage 側だけ直して classic compute を忘れる
Storage firewall を変更すると、serverless compute だけでなく classic compute からの接続にも影響します。公式情報でも、リソース ファイアウォールを作成すると classic compute plane からの接続にも影響するため、classic compute 用のネットワークも許可する必要があると説明されています。(Microsoft Learn)
Private Endpoint を作っただけで完了したと思っている
Private Endpoint は承認、DNS、ポリシー、実ワークロード検証まで終えて初めて意味があります。Private endpoint rule は PENDING、REJECTED、DISCONNECTED、EXPIRED などの状態を持ち、PENDING のままでは使えません。また、private endpoint rule は接続状態に関係なく存在時間に対して Azure 側で課金されるため、不要な rule は削除する必要があります。(Microsoft Learn)
Inbound Private Link で SSO 用 endpoint を忘れる
databricks_ui_api だけを作成して、browser_authentication endpoint を作らないと、ブラウザ SSO が失敗する可能性があります。プロダクションでは専用の private web auth workspace を作り、削除ロックを設定して、業務ワークスペースの削除や再構築に巻き込まれないようにしてください。(Microsoft Learn)
ネットワーク ポリシーをいきなり強制適用する
Restricted Access や blocked destinations は強力ですが、ライブラリ取得、モデル ビルド、外部 API、BI ツール連携を壊すことがあります。まず dry-run でログを取り、必要な宛先を明示的に許可してから段階的に適用してください。
SCC のファイアウォール許可を IP 固定で考える
Secure Cluster Connectivity の relay endpoint では、FQDN の許可が推奨されています。IP アドレスはインフラ更新で変わるため、個別 IP だけを許可するとサービス中断のリスクがあります。(Microsoft Learn)
実務での進め方：まずはワークスペース別の棚卸しから
最初にやるべきことは、設定変更ではなく棚卸しです。次の項目をワークスペース単位で一覧化してください。
| 項目 | 記録する内容 |
|---|---|
| ワークスペース名 | 本番、検証、DR、部門別などの用途 |
| リージョン | Japan East、East US、West Europe など |
| プラン | Premium かどうか |
| compute 種別 | Serverless、Classic、両方 |
| Storage | ADLS Gen2 / Blob / workspace storage account |
| ネットワーク保護 | Firewall、NSP、Private Endpoint、service tag |
| Inbound 制御 | IP access lists、Context-based ingress、Private Link |
| Outbound 制御 | NCC、network policy、NAT Gateway、UDR |
| 管理方法 | Portal、ARM、Terraform、CLI、手動 |
| 検証結果 | SQL、Notebook、Job、Model Serving の接続確認日 |
棚卸しが終わったら、サーバーレス ワークロードがあるワークスペースから優先して対応します。Storage firewall と古い IP 許可リストは接続障害につながりやすいため最優先です。その後、Private Link、network policies、SCC、NAT Gateway、コスト監視の順で固めると、短期間でリスクを下げられます。
まとめ：Azure Databricks Networking は「接続できる」から「制御して接続できる」へ
Azure Databricks Networking の更新ポイントは、単なるネットワーク機能の追加ではありません。サーバーレス化が進むほど、通信元が従来の自社 VNet だけではなくなり、Storage firewall、NSP、サービス タグ、NCC、Private Link、ネットワーク ポリシーを組み合わせて制御する必要があります。
管理者が次に取るべき行動は明確です。まず、サーバーレスを使っているワークスペースと Storage アカウントを洗い出し、2026年5月25日と6月9日の移行対象が残っていないか確認してください。次に、NCC と NSP の設定、Private Endpoint の承認状態、DNS、dry-run ログ、NAT Gateway、SCC を順番に確認します。
「通信を許可する」だけでなく、「どのワークロードが、どのリージョンから、どのデータソースへ、どの経路で接続しているか」を説明できる状態にすることが、2026年以降の Azure Databricks 運用で重要になります。
コメント