Azure Databricksでファイアウォール、UDR、IP許可リストを管理している場合、2026年4月更新で最初に確認すべき結論は「個別IPの固定管理を減らし、可能な限りサービス タグとFQDNベースの許可に寄せる」ことです。
Microsoft Learn日本語版の「Azure Databricks サービスと資産の IP アドレスとドメイン」は2026年4月23日に更新されており、VNetにデプロイしたAzure Databricks、ユーザー定義ルート、SCC、サーバーレス コンピューティング、DBFS、Hiveメタストア、Event Hubsなどの通信許可を見直すうえで重要な情報が整理されています。特に、データエンジニア、DBA、分析基盤の責任者は「ジョブが突然外部サービスへ接続できない」「メタストアやログ出力だけ失敗する」といった障害を防ぐために、ネットワーク設定の棚卸しを行うべきタイミングです。(Microsoft Learn)
Azure DatabricksのIPアドレスとドメイン情報は何に使うのか
Azure Databricksの「IP addresses and domains for Azure Databricks services and assets」は、主に自社のVNet、ファイアウォール、仮想アプライアンス、ユーザー定義ルート（UDR）で通信を制御している環境向けのドキュメントです。
通常のワークスペース利用だけであれば、すべてのIPアドレスを手作業で管理する必要はありません。しかし、次のような構成では確認が必要になります。
| 利用シーン | 確認が必要な理由 |
|---|---|
| VNetインジェクションを使っている | クラシック コンピューティング プレーンからコントロール プレーン、Storage、Event Hubsなどへ正しく到達させる必要がある |
| UDRで通信経路を制御している | オンプレミス経由やNVA経由に流れた通信が、Azure Databricksの必須エンドポイントへ届かない可能性がある |
| ファイアウォールでIP許可リストを使っている | IP変更に追従できないと、クラスター起動、ジョブ実行、ログ出力、メタストア接続が失敗する可能性がある |
| サーバーレス コンピューティングを使っている | サーバーレス向けの送信IP管理がクラシック環境と異なる |
| 複数リージョンで展開している | リージョンごとにコントロール プレーン、Storage、Event Hubs、SCCリレーの扱いが異なる |
重要なのは、Azure Databricksの通信先は「WebアプリのURL」だけではないという点です。コントロール プレーン、SCCリレー、DBFSルートストレージ、アーティファクトBlob、ログBlob、システムテーブル、Hiveメタストア、Event Hubsなど、複数のサービスに分かれています。
2026年4月更新で押さえるべきポイント
今回の更新は、単にIP一覧を眺めるためのものではありません。実務上は、以下の観点で設定を見直すと効果的です。
| 確認ポイント | 実務で取るべき対応 | 放置した場合のリスク |
|---|---|---|
| 個別IPではなくサービス タグを優先する | UDR、NSG、Azure FirewallでAzureDatabricks、Storage、EventHubなどの利用を検討する | IP変更時にジョブやクラスター起動が失敗する |
| SCCリレーはFQDNで許可する | tunnel.<region>.azuredatabricks.netなどをFQDNベースで許可する | 背後のIP変更でSCC接続が切れる |
| SCC有効・無効で必要な経路が違う | ワークスペースごとにSCCの状態を確認する | NAT IPやSCCリレーの許可漏れが発生する |
| サーバーレス送信IPはJSONベースで追跡する | 静的な旧IPリストに依存しない | 2026年5月25日以降に接続エラーが起きる可能性がある |
| Storageのセカンダリリージョンを確認する | 例：東日本ならStorage.JapanEastだけでなくStorage.JapanWestも検討する | アーティファクトやログ関連の通信だけ失敗する |
| 予約済みIP範囲を避ける | IPAM、VNet設計、Dockerネットワーク範囲を確認する | Databricks内部利用範囲と衝突する |
個別IPの固定管理よりサービス タグを優先する
Azure Databricksのネットワーク設定で最も重要なのは、個別IPを許可リストに固定する運用をできるだけ避けることです。
Microsoftのサービス タグは、AzureサービスごとのIPアドレス プレフィックスをまとめたもので、Microsoft側でアドレス範囲が管理・更新されます。サービス タグは、NSG、Azure Firewall、UDRで利用でき、個別IPを追跡する負担を減らせます。(Microsoft Learn)
Azure DatabricksのUDR設定でも、サービス タグを使う場合は基本的に次のルートを考えます。
| アドレス プレフィックス | 目的 | ネクストホップ |
|---|---|---|
AzureDatabricks | コントロール プレーン、SCC、Webアプリへの必須接続 | Internet |
Storage または Storage.<Region> | アーティファクトBlob、ログBlob、DBFS関連 | Internet |
EventHub または EventHub.<Region> | ログ記録に必要なEvent Hubs接続 | Internet |
Azure DatabricksのUDR公式ドキュメントでも、AzureDatabricks、Storage、EventHubのサービス タグを使った構成が推奨されています。さらに、Azure Private Linkが有効なワークスペースではAzureDatabricksサービス タグが不要になるケースがある一方、StorageやEvent Hubsなど他の宛先は引き続き確認が必要です。(Microsoft Learn)
AzureDatabricks.JapanEastのようなリージョンタグは作れない
実務で間違えやすいのが、Storage.JapanEastと同じ感覚でAzureDatabricks.JapanEastのようなタグを想定してしまうことです。
Azureサービス タグの一覧では、AzureDatabricksはInbound/Outboundの両方で利用できる一方、リージョンスコープは「No」とされています。つまり、StorageやEventHubのようにリージョンを付けたタグ指定ができる前提で設計すると、ルール作成や検証でつまずきます。(Microsoft Learn)
サービス タグを使う場合の考え方は、次のように分けると整理しやすくなります。
| 対象 | 推奨される考え方 |
|---|---|
| Azure Databricks本体 | AzureDatabricksサービス タグを使う |
| Storage | 必要に応じてStorage.JapanEastなどのリージョンスコープを使う |
| Event Hubs | 必要に応じてEventHub.JapanEastなどのリージョンスコープを使う |
| SCCリレー | 個別IPではなくFQDNを許可する |
| 組織ポリシーでサービス タグが使えない場合 | 公式ページのIP・FQDNを使い、自動更新の仕組みを用意する |
ただし、サービス タグは「IP範囲の管理を簡単にする仕組み」であり、それだけで十分なセキュリティ対策になるわけではありません。認証、認可、Private Link、監査ログ、最小権限の設計と組み合わせて使うことが重要です。(Microsoft Learn)
SCC有効・無効で確認すべきIPとドメインが変わる
Azure Databricksでは、ワークスペースがセキュリティで保護されたクラスター接続（SCC）を使っているかどうかで、必要な通信許可が変わります。SCCは「No Public IP（NPIP）」とも呼ばれ、クラシック コンピューティング プレーンのリソースにパブリックIPを持たせず、クラスター側からコントロール プレーンのSCCリレーへHTTPSで接続します。(Microsoft Learn)
| ワークスペース状態 | 主に確認するもの | よくあるミス |
|---|---|---|
| SCC有効 | SCCリレーFQDN、コントロール プレーンIP、既定ストレージ、Webアプリ関連 | SCCリレーを個別IPで許可してしまう |
| SCC無効 | コントロール プレーン関連、Webアプリ関連、Control Plane NAT IP | Control Plane NAT IPの許可を忘れる |
| Private Link有効 | Private Link対象外のStorage、メタストア、ログ、Event Hubsなど | Private Linkだけで全通信が閉じたと誤解する |
| サーバーレス利用 | サーバーレス送信IP、Private Link、外部接続先の許可リスト | クラシック用のIP許可リストを流用する |
SCCリレーについては、公式ドキュメントでも個別IPではなくFQDNを許可リストに入れるよう警告されています。SCCリレーの背後にあるIPは、インフラ更新やマルチ可用性ゾーン構成により変わる可能性があります。やむを得ずIPで制御する場合は、DNS解決とファイアウォールルール更新を自動化する運用が必要です。(Microsoft Learn)
SCCは新規ワークスペースで既定有効になりやすい
現在のAzure Databricksでは、Azure portalやARMテンプレートで新規ワークスペースを作成する場合、SCCが自動的に有効になる構成が案内されています。既存ワークスペースにSCCを追加する場合は、ファイアウォールやNSGのルール更新が必要になることがあります。(Microsoft Learn)
つまり、古いワークスペースと新しいワークスペースが混在している企業では、同じAzure Databricksでも必要なネットワークルールが異なる可能性があります。分析基盤チームは、ワークスペース単位でSCCの状態を棚卸しするべきです。
サーバーレス コンピューティングの送信IP管理は別物として扱う
2026年4月更新で特に注意したいのが、サーバーレス コンピューティング ファイアウォールのアウトバウンドIPです。
公式ドキュメントでは、この機能はプライベートプレビューとして扱われています。対象ワークスペースでは、送信IPアドレスを含むJSONファイルのURLを受け取り、その情報をもとにAzure Databricksサービスからのトラフィックを許可または拒否します。送信IPは30日に1回程度更新される可能性があり、更新されたIPは公開から60日後にアクティブになる場合があります。(Microsoft Learn)
さらに重要なのは、レガシーな静的IPリストへの依存です。公式ドキュメントでは、サーバーレス送信IPの静的リストは使用停止となっており、2026年5月25日以降に削除されるとされています。従来の許可リストに依存しているワークロードでは、接続エラーが起きる可能性があります。(Microsoft Learn)
サーバーレスを使っている場合は、次の手順で確認してください。
| 手順 | 作業内容 |
|---|---|
| 1 | サーバーレス コンピューティングを使っているワークスペースを洗い出す |
| 2 | 外部DB、API、SaaS、オンプレミス接続先でIP許可リストを使っているか確認する |
| 3 | Azure Databricksアカウントチームから提供されるJSON URLの管理者を決める |
| 4 | JSONのservice、platform、type、regionを使って対象IPを抽出する |
| 5 | timestampSecondsを比較し、変更検知とファイアウォール更新を自動化する |
| 6 | 2026年5月25日より前に、旧静的IPリストへの依存を外す |
| 7 | 本番ジョブだけでなく、開発・検証ワークスペースでも疎通テストを行う |
特に、サーバーレスSQLウェアハウスやLakehouse Federation、外部APIアクセスを利用しているチームは、ネットワーク許可の責任分界が曖昧になりがちです。「Databricks側の設定」だけでなく、接続先システムのファイアウォール、WAF、DBアクセス制御まで含めて確認しましょう。
DBFS、メタストア、Blob、Event Hubsは「本体とは別の通信」として見る
Azure Databricksの通信トラブルで多いのは、ワークスペース画面は開けるのに、ジョブ、ログ、メタストア、DBFSの一部だけが失敗するケースです。これは、Azure Databricks本体以外にも複数のAzureサービスへ通信しているためです。
DBFSルートストレージはBlobとDFSの両方を確認する
DBFSルートストレージのIPアドレスを取得する場合、Azure portalでワークスペースのマネージドリソースグループを開き、dbstorage************形式のストレージアカウントを確認します。そのうえで、<storage-account-name>.blob.core.windows.netと<storage-account-name>.dfs.core.windows.netの両方のドメインを確認し、必要に応じてUDRを作成します。(Microsoft Learn)
| エンドポイント | 用途のイメージ |
|---|---|
.blob.core.windows.net | Blob Storageとしてのアクセス |
.dfs.core.windows.net | ADLS Gen2互換のDFSエンドポイント |
| UDR | Storageサービスへ正しくルーティングするために利用 |
片方だけ許可していると、ノートブックやジョブの一部操作は通るのに、特定のデータアクセスだけ失敗することがあります。
メタストア、アーティファクト、ログ、Event HubsはFQDNとポートも見る
Hiveメタストア、アーティファクトBlob、システムテーブル、ログBlob、Event HubsのIPアドレスは、公式表に示されるドメイン名を使って確認します。ただし、これらのIPは時間とともに変わる可能性があるため、公式ドキュメントではルートテーブルでAzureサービス タグを使うか、定期的にIPを自動取得して更新する運用が示されています。(Microsoft Learn)
DBAやデータ基盤担当者が特に見落としやすいのは、Hiveメタストアの接続です。レガシーHiveメタストアを使う場合、NSGのエグレスでポート3306を開く必要があります。また、外部Hiveメタストアを使う場合は、Databricksに関連付けられたVNetのドメインコントローラーやPrivate DNS Zoneにmysql.database.azure.comの既存DNSレコードがないか確認する必要があります。(Microsoft Learn)
日本リージョンではセカンダリストレージに注意する
日本の読者にとって特に重要なのは、東日本リージョンの扱いです。
公式ドキュメントでは、リージョンスコープのサービス タグを使う場合、プライマリとは別リージョンにセカンダリストレージが存在するケースでは追加のサービス タグが必要になると説明されています。例として、東日本のワークスペースでは西日本にセカンダリアーティファクトストレージがあるため、Storage.JapanEastだけでなくStorage.JapanWestもルートテーブルに含める必要があります。(Microsoft Learn)
これはグローバル展開でも同じ考え方です。米国、欧州、アジア太平洋など複数リージョンにワークスペースを持つ企業では、「ワークスペースのリージョン」だけでなく「関連ストレージやログ基盤がどのリージョンにあるか」まで確認しましょう。
予約済みIP範囲とDockerネットワーク範囲を避ける
Azure Databricksでは、内部アプリケーション用に予約されたIP範囲があります。顧客側のネットワーク構成では、次の範囲を使わないようにする必要があります。(Microsoft Learn)
| 避けるべき範囲 | 理由 |
|---|---|
127.187.216.0/24 | Databricks内部利用との競合を避ける |
192.168.216.0/24 | Databricks内部利用との競合を避ける |
198.18.216.0/24 | Databricks内部利用との競合を避ける |
172.17.0.0/16 | Databricks Container Serviceクラスターで既定Dockerネットワーク範囲との競合を避ける |
特に192.168.216.0/24は、社内ネットワークや検証環境のIP設計でうっかり使われやすい範囲です。Azure Databricksの導入後にVNetやサブネットを変更するのは手間が大きいため、IPAMの段階で除外しておくのが安全です。
役割別に見る確認ポイント
Azure DatabricksのIPアドレスとドメイン更新は、ネットワーク担当者だけの作業ではありません。データ基盤の運用では、役割ごとに見るべき観点が異なります。
| 役割 | 重点的に確認すること | 具体的なアクション |
|---|---|---|
| データエンジニア | ジョブ、ノートブック、外部接続、サーバーレス接続 | 本番ジョブの接続先を洗い出し、許可リスト変更後にスモークテストを行う |
| DBA | Hiveメタストア、外部DB、ポート3306、DNS | メタストア接続、Private DNS、DB側ファイアウォールを確認する |
| 分析基盤リーダー | 停止リスク、変更期限、運用責任 | 2026年5月25日までのサーバーレス許可リスト移行計画を立てる |
| ネットワーク担当 | UDR、NSG、Azure Firewall、サービス タグ | 個別IP管理からサービス タグ中心の構成へ移行する |
| セキュリティ担当 | 最小権限、監査、Private Link、例外管理 | サービス タグ利用時も認証・監査・出口制御を組み合わせる |
分析基盤の障害は、単なる通信断ではなく、BIレポート遅延、データパイプライン失敗、監査ログ欠落、SLA違反につながります。IP許可リストの更新を「ネットワーク作業」としてだけ扱わず、データ運用全体のリスク管理として見ることが重要です。
実務での見直し手順
Azure Databricks環境を運用している場合は、次の順番で見直すと抜け漏れを減らせます。
ワークスペースを棚卸しする
まず、すべてのAzure Databricksワークスペースについて、次の情報を一覧化します。
| 項目 | 確認内容 |
|---|---|
| ワークスペース名 | 本番、開発、検証を分ける |
| リージョン | Japan East、West US、West Europeなど |
| VNetインジェクション | 有効かどうか |
| SCC | 有効か無効か |
| Private Link | 有効かどうか |
| サーバーレス利用 | SQL Warehouse、サーバーレスコンピュートなど |
| UDR | どのルートテーブルに関連付けられているか |
| ファイアウォール | IPベースかFQDNベースか |
| 外部接続先 | DB、API、SaaS、オンプレミスなど |
サービス タグに置き換えられる部分を探す
次に、個別IPで管理しているルールを洗い出します。組織ポリシーで許可される範囲では、AzureDatabricks、Storage、EventHubなどのサービス タグへ置き換えます。
ただし、サービス タグへ置き換える前に、次の点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| ルールの方向 | InboundなのかOutboundなのか |
| 対象サービス | Databricks本体、Storage、Event Hubsのどれか |
| リージョンスコープ | StorageやEventHubでリージョン指定が必要か |
| セカンダリリージョン | 東日本と西日本のような追加タグが必要か |
| Private Link | Databricks本体向けのルールが不要になる構成か |
| 監査要件 | IP範囲の広がりが社内基準に合うか |
SCCリレーはFQDN許可を優先する
SCCリレーを使っている場合、個別IPではなくFQDNを許可します。どうしてもIPで制御する必要がある環境では、手作業更新を前提にしないでください。
最低限、次の仕組みを用意します。
| 仕組み | 目的 |
|---|---|
| 定期DNS解決 | FQDN背後のIP変更を検知する |
| 差分比較 | 追加・削除されたIPを記録する |
| ファイアウォール更新自動化 | 変更を迅速に反映する |
| 変更履歴保存 | 障害時にいつ何が変わったか追えるようにする |
| 疎通テスト | クラスター起動、ジョブ実行、メタストア接続を確認する |
サーバーレスの旧静的IPリストを廃止する
サーバーレス コンピューティングを使っていて、外部システム側にDatabricksのIPを許可している場合は、旧静的IPリストへの依存を必ず確認します。
2026年5月25日以降に静的リストが削除されると案内されているため、対象ワークロードがある場合は、JSONベースの送信IP管理へ移行する計画が必要です。(Microsoft Learn)
実務では、次のような運用にすると安定します。
| 運用項目 | 推奨内容 |
|---|---|
| 更新頻度 | 少なくとも週次でJSONを確認する |
| 差分検知 | timestampSecondsを比較する |
| 対象抽出 | service=Databricks、platform=azure、type=outbound、対象regionで絞る |
| 反映先 | Azure Firewall、オンプレミスFW、DB許可リスト、SaaS側のアクセス制御 |
| テスト | 外部DB接続、API呼び出し、ジョブ実行を確認する |
| ロールバック | 変更前IPリストを一定期間保存する |
よくある失敗と回避策
東日本だけ許可して西日本のストレージを忘れる
東日本ワークスペースだからといって、Storage.JapanEastだけを許可すれば十分とは限りません。セカンダリアーティファクトストレージが西日本にあるケースでは、Storage.JapanWestも必要になります。(Microsoft Learn)
回避策は、リージョン名だけで判断せず、公式表にあるFQDNとサービス列を確認することです。
SCC有効化後に古いNAT前提のルールを残す
SCC有効化により、通信の向きや必要な許可対象が変わります。既存ワークスペースにSCCを追加する場合、ファイアウォールやNSGのルール更新が必要になる可能性があります。(Microsoft Learn)
回避策は、SCC有効化を単なる設定変更ではなく、ネットワーク変更作業として扱うことです。すべてのクラシック コンピューティングリソースを停止する計画や、疎通確認の手順も用意しておきましょう。
サービス タグを「セキュリティ対策そのもの」と誤解する
サービス タグはIP範囲管理を簡単にする仕組みです。アクセス制御を完全に代替するものではありません。Microsoftのサービス タグ概要でも、サービス タグだけではトラフィックの性質まで考慮した十分な保護にはならないと説明されています。(Microsoft Learn)
回避策は、Private Link、IDベースの認可、監査ログ、ネットワーク分離、最小権限を組み合わせることです。
予約済みIP範囲を社内ネットワークに割り当てる
192.168.216.0/24のような範囲は、検証用VNetやオンプレミス側で使ってしまいやすいアドレスです。Databricks内部利用範囲と競合すると、原因特定が難しいネットワーク障害につながります。(Microsoft Learn)
回避策は、Azure Databricks用のIP設計ルールをIPAMに登録し、VNet作成時のチェック項目に入れることです。
次に取るべきアクション
Azure DatabricksのIPアドレスとドメイン更新で最も大切なのは、公式一覧をコピーすることではありません。自社環境の通信制御が、IP変更やサーバーレス移行に追従できる状態になっているかを確認することです。
まずは、次の4点を優先してください。
- すべてのAzure Databricksワークスペースについて、リージョン、SCC、Private Link、サーバーレス利用状況を棚卸しする。
- 個別IPで管理しているUDR、NSG、Azure Firewall、外部DB側の許可リストを洗い出す。
- 可能な範囲で
AzureDatabricks、Storage、EventHubなどのサービス タグへ移行する。 - サーバーレス送信IPの旧静的リストに依存している場合は、2026年5月25日より前にJSONベースの更新運用へ切り替える。
Azure Databricksは、データパイプライン、BI、機械学習、ログ分析などの中核になりやすいサービスです。IPアドレスとドメインの管理を後回しにすると、ある日突然「クラスターは起動するがデータに接続できない」「本番ジョブだけ外部DBに到達できない」という障害につながります。今回の2026年4月更新を、ネットワークルールと運用手順を見直すきっかけにしましょう。
コメント