Azure DatabricksのIPアドレスとドメイン情報は、ファイアウォール、NSG、UDR、Private Link、サーバーレス利用環境の接続可否に直結します。結論から言うと、管理者が最初に確認すべきなのは「ワークスペースのリージョン」「SCCの有効/無効」「サービス タグを使えるか」「UK Southやサーバーレス ファイアウォール プレビューに該当するか」の4点です。
特に、個別IPアドレスを手作業で許可している環境では注意が必要です。Microsoft Learnの公式情報では、Azure Databricksの許可設定は個別IPよりもAzure Databricksサービス タグの利用が推奨されており、SCCリレーについてはIPではなくFQDNを許可する方針が示されています。これは、IP変更によるサービス停止を避けるためです。(Microsoft Learn)
Azure DatabricksのIPアドレスとドメイン情報で何が変わるのか
公式ドキュメント「IP addresses and domains for Azure Databricks services and assets」は、Azure Databricksの各リージョンで必要になるコントロール プレーン、SCCリレー、ストレージ、メタストア、Event HubsなどのIPアドレスやFQDNを整理したものです。自社VNetにAzure Databricksワークスペースをデプロイし、UDRやファイアウォール、仮想アプライアンスで通信を制御している場合に重要になります。(Microsoft Learn)
今回の確認ポイントは、単に「IP一覧が更新された」という話ではありません。実務上は、次のようなネットワーク設計・運用に影響します。
| 確認ポイント | 管理者への影響 | すぐ確認すべき設定 |
|---|---|---|
| Azure Databricksサービス タグの利用 | 個別IPの追跡・更新作業を減らせる | NSG、Azure Firewall、UDRでAzureDatabricksを使えるか |
| SCCリレー | IP固定許可だと将来の変更で接続断の恐れ | SCCリレーはFQDNで許可しているか |
| UK Southリージョン | 新規ワークスペースと既存ワークスペースで必要な値が異なる可能性 | UK South値とUK West値の両方が必要か |
| サーバーレス コンピューティング ファイアウォール プレビュー | 静的IPリスト依存のワークロードで接続エラーの恐れ | JSONベースのIP更新運用に移行しているか |
| DBFS root、メタストア、Blob、Event Hubs | サービスごとにFQDN、ポート、プロトコルが異なる | Storage、EventHub、MySQL 3306、HTTPS 443、TCP 9093の許可 |
| DCSやカスタムCIDR | Databricks内部利用範囲と衝突する可能性 | 予約済みIP範囲やDocker既定範囲を使っていないか |
まず棚卸しすべきワークスペースの条件
Azure Databricksのネットワーク設定は、全ワークスペースに同じルールを貼ればよいものではありません。最初に、対象ワークスペースを次の軸で分類してください。
| 分類項目 | 確認内容 | 判断のポイント |
|---|---|---|
| リージョン | Japan East、Japan West、UK Southなど | リージョンごとに必要なIP/FQDNが異なる |
| VNet構成 | 自社VNetへデプロイしているか | UDRやNVAを使う環境は影響を受けやすい |
| SCC | Secure Cluster Connectivityが有効か | 有効ならSCCリレー、無効ならControl Plane NATも確認 |
| Private Link | ワークスペースでPrivate Linkを使っているか | UDRで必要な通信先が変わる |
| サーバーレス | サーバーレス コンピューティング ファイアウォール プレビューを使うか | JSONファイルによるアウトバウンドIP管理が必要 |
| 許可方式 | サービス タグか、個別IPか、FQDNか | 個別IP運用は自動更新の仕組みが必要 |
| IaC管理 | Terraform、Bicep、ARMテンプレートなどで管理しているか | ハードコードされたIPやリージョン値を見直す |
運用チームが見落としやすいのは、「ワークスペースのリージョン」と「通信先サービスのリージョン」が常に一致するとは限らない点です。たとえば公式ドキュメントでは、リージョンスコープのサービス タグを使う場合、セカンダリ ストレージが別リージョンにあると、その別リージョンのStorageタグも追加する必要があると説明されています。(Microsoft Learn)
基本方針は「個別IP」より「サービス タグ」と「FQDN」
Azure Databricksの通信許可では、可能な限りサービス タグを使うのが安全です。サービス タグは、Azureサービスが利用するIPプレフィックスの集合をMicrosoftが管理し、変更に応じて更新する仕組みです。NSG、Azure Firewall、UDRで利用でき、頻繁なIP変更を手作業で追いかける負担を減らせます。(Microsoft Learn)
Azure Databricksで特に重要なのは、次の組み合わせです。
| 用途 | 推奨される指定 | 補足 |
|---|---|---|
| Databricksコントロール プレーン、SCC、Webアプリ | AzureDatabricksサービス タグ | Databricks側のIP変更に追従しやすい |
| Artifact Blob storage、Log Blob storage、DBFS関連 | StorageまたはリージョンスコープのStorage.<Region> | セカンダリ ストレージのリージョンも確認 |
| Event Hubsログ送信 | EventHubまたはリージョンスコープのEventHub.<Region> | TCP 9093が必要なケースを確認 |
| SCCリレー | FQDN許可 | IPではなくドメイン名で許可する |
| 外部Hive metastoreなど | 必要なFQDNとポート | DNS設定の競合にも注意 |
UDRの公式ガイドでも、Azure Databricks、Storage、EventHubのサービス タグを使う構成が示されています。Private Linkを有効にしている場合はAzure Databricksサービス タグが不要になるケースもありますが、メタストア、Artifact Blob storage、Log Blob storage、Event Hubsなどの通信は引き続き確認が必要です。(Microsoft Learn)
SCCが有効か無効かで確認するIPが変わる
Azure Databricksのコントロール プレーン通信は、SCCの有効/無効で確認対象が変わります。
SCCが有効な場合は、ワークスペース リージョンのSCCリレー値とコントロール プレーンIPを確認します。ここで重要なのは、SCCリレーの許可を個別IPではなくFQDNで行うことです。公式情報でも、SCCリレー エンドポイントはFQDNを許可リストに入れるよう明記されています。(Microsoft Learn)
SCCが無効な場合は、コントロール プレーン関連の値に加えて、Control Plane NATの値も確認します。SCC無効環境では、Control Plane NATからの通信に対する戻り通信が必要になるため、UDRやファイアウォールで該当IPを落としていないかを確認してください。(Microsoft Learn)
日本リージョンで確認する場合の例
日本リージョンでは、公式表にJapan EastとJapan Westのコントロール プレーンIP、SCCリレーFQDNが掲載されています。2026年5月時点の公式表では、Japan Eastは52.246.160.72/32、4.189.194.16/28、4.150.168.160/28など、Japan Westは52.246.160.72/32、138.91.16.64/28、4.150.168.160/28などが示されています。また、SCCリレーはJapan East/Westともにtunnel.japaneast.azuredatabricks.netが示されています。(Microsoft Learn)
ただし、この記事の値をそのまま恒久的な設定値として扱わないでください。IPアドレスは変更される可能性があります。実際の本番設定では、必ず最新の公式表、サービス タグ、DNS解決結果を確認し、可能であればサービス タグまたはFQDNベースの許可に寄せるべきです。
UK South利用者は「新規」と「既存」を分けて考える
UK Southを利用している企業は、特に注意が必要です。2026年4月30日以降、Azure UK Southには専用のリージョナル コントロール プレーンが用意され、この日以降に作成された新しいUK SouthワークスペースではUK Southの値が必要になります。一方、既存のUK Southワークスペースは、移行しない限りUK Westベースのコントロール プレーンと対応する値を使い続けます。新旧ワークスペースを併用する場合は、UK SouthとUK Westの両方の値を許可する必要があります。(Microsoft Learn)
この変更で失敗しやすいのは、リージョン名だけを見て一律にUK Southの値へ切り替えてしまうケースです。実際には、次のように整理してください。
| ワークスペース | 必要な対応 |
|---|---|
| 2026年4月30日以降にUK Southで作成 | UK SouthのSCCリレー、Control Plane NAT、Metastore、Log Blob storage、Event Hubsを許可 |
| それ以前に作成されたUK Southワークスペース | 移行していない限り、UK Westベースの値を継続確認 |
| UK Southで新旧ワークスペースが混在 | UK SouthとUK Westの両方の値を許可 |
| IaCで一括管理している環境 | 作成日、移行状態、リージョンを変数化する |
特にTerraformやBicepでネットワークルールをテンプレート化している場合、「リージョンがUK SouthならUK South値だけ」という単純な条件分岐は危険です。作成日や移行状態を管理項目に加え、例外が残らないようにしてください。
サーバーレス コンピューティング ファイアウォール プレビューの注意点
サーバーレス コンピューティング ファイアウォールは、2026年5月時点ではPrivate Previewとして扱われています。対象ワークスペースでは、アウトバウンドIPを含むJSONファイルのURLを受け取り、そのJSONを基に許可・拒否ルールを管理します。公式情報では、JSON内のservice、platform、type、regionを条件にフィルターし、timestampSecondsで変更を検出する運用が示されています。(Microsoft Learn)
ここで重要なのは、静的IPリストへの依存をやめることです。公式情報では、レガシー版プレビューで共有されていたサーバーレス送信IPの静的リストは廃止され、2026年5月25日以降に削除されると説明されています。従来の許可リストに依存したワークロードでは接続エラーが起きる可能性があるため、対象環境ではJSONベースの更新運用へ移行してください。(Microsoft Learn)
実務では、次のような自動化を組むと安全です。
| 手順 | 実施内容 |
|---|---|
| JSON取得 | 定期的に提供URLからJSONを取得 |
| フィルター | service=Databricks、platform=azure、type=outbound、対象regionで抽出 |
| 差分検出 | timestampSecondsとIP一覧を前回保存分と比較 |
| 変更レビュー | 変更内容をPull Requestや変更申請に自動添付 |
| 反映 | Azure Firewall、NVA、外部ファイアウォールへ反映 |
| 保管 | 過去バージョンを保存し、障害時に比較できるようにする |
サーバーレスは「クラシック クラスターと同じネットワーク運用でよい」と考えると見落としが出ます。特に外部SaaS、外部データベース、社内APIへ接続しているノートブックやジョブでは、送信元IP制御の扱いを個別に確認してください。
DBFS root、メタストア、Blob、Event Hubsで見るべきポート
Azure Databricksの許可設定では、コントロール プレーンだけを見ても不十分です。DBFS root storage、Hive metastore、Artifact Blob storage、System tables storage、Log Blob storage、Event Hubsなど、ワークスペースが利用する周辺サービスも確認する必要があります。
公式手順では、DBFS root storageのIPを確認するには、Azureポータルでワークスペースのマネージド リソース グループを開き、dbstorage************形式のストレージ アカウントを確認し、<storage-account-name>.blob.core.windows.netと<storage-account-name>.dfs.core.windows.netのドメインを解決してUDRを作成する流れが示されています。(Microsoft Learn)
また、メタストアや各種ストレージ、Event Hubsについては、リージョン別にFQDN、ポート、プロトコルが一覧化されています。代表的には、メタストアはTCP 3306、Blob/DFS系はHTTPS 443、Event HubsはTCP 9093を確認します。IPは時間とともに変わる可能性があるため、サービス タグや定期的なDNS解決ジョブで更新する運用が推奨されます。(Microsoft Learn)
管理者が実施すべき設定確認チェックリスト
変更対応では、いきなりファイアウォールルールを修正するのではなく、影響範囲を明確にしてから進めます。次のチェックリストを使うと、抜け漏れを減らせます。
| チェック項目 | 確認方法 | 見落とした場合のリスク |
|---|---|---|
| ワークスペース一覧 | Azureポータル、Databricksアカウント、IaC管理台帳で照合 | 一部ワークスペースだけ接続不能になる |
| リージョン | 各ワークスペースのAzureリージョンを確認 | 誤ったリージョンのIP/FQDNを許可する |
| SCC状態 | ワークスペースのネットワーク設定を確認 | SCCリレーまたはControl Plane NATの設定漏れ |
| UDR | ルート テーブルの宛先プレフィックスと次ホップを確認 | Databricks通信がNVAやオンプレミス側へ誤転送される |
| NSG/Azure Firewall | サービス タグ、FQDN、ポートの許可を確認 | クラスター起動、ライブラリ取得、ログ送信が失敗 |
| Private Link | Private endpoint、DNS、Public Network Accessを確認 | private経路を作ってもpublic経路が残る、または名前解決に失敗 |
| サーバーレス利用 | サーバーレス ジョブ、SQL、ノートブックの外部接続を確認 | 外部接続先のIP許可リストでブロックされる |
| セカンダリ ストレージ | 公式表で別リージョンのArtifact Blob storageを確認 | 一部のライブラリ、アーティファクト、ログ処理が失敗 |
| CIDR衝突 | VNet、オンプレミス、コンテナネットワークを確認 | クラスターやDCSで予期しない通信不具合 |
変更後は、単にポータル上でルールが入ったことを確認するだけでは不十分です。実際にクラスター起動、ノートブック実行、DBFSアクセス、外部接続、ログ出力、ジョブ実行まで確認してください。
失敗しやすい設定ミスと回避策
| よくあるミス | 起きる症状 | 回避策 |
|---|---|---|
| SCCリレーをIPで固定許可する | インフラ更新後にクラスター接続が不安定になる | SCCリレーはFQDNで許可する |
| SCC無効環境でControl Plane NATを見落とす | 戻り通信が遮断され、接続エラーが出る | SCC有無ごとに必要な値を分けて確認 |
| Storageのプライマリ リージョンだけ許可する | Artifactやログ関連の通信が失敗する | セカンダリ ストレージのリージョンも許可 |
| UK Southを一律に新値へ切り替える | 既存ワークスペースだけ通信不可になる | 新規、既存、移行済みを分けて管理 |
| サーバーレスの旧静的IPリストを使い続ける | 2026年5月25日以降に接続エラーの可能性 | JSON取得と差分反映を自動化 |
| Private Linkを設定しただけでpublic経路が閉じたと思い込む | 意図せずpublic accessが残る | Public Network Access設定も確認 |
| Databricks内部予約範囲と社内CIDRが重なる | クラスターやコンテナ通信で競合する | 予約済みIP範囲を設計段階で除外 |
Databricksでは内部利用のために127.187.216.0/24、192.168.216.0/24、198.18.216.0/24が予約されています。また、Databricks Container ServiceクラスターではDocker既定の172.17.0.0/16も避けるべき範囲として示されています。VNet設計やオンプレミス接続、コンテナネットワーク設計時に衝突しないか確認してください。(Microsoft Learn)
開発者が確認すべきポイント
ネットワーク更新はインフラ担当だけの作業に見えますが、開発者にも影響があります。特に次のような処理を持つジョブやノートブックは、接続先と送信元制御を確認してください。
| 開発・運用シーン | 確認すること |
|---|---|
| 外部APIを呼ぶジョブ | 外部API側でDatabricksの送信元IPを許可しているか |
| パッケージをインストールするノートブック | PyPI、Maven、社内リポジトリへの経路があるか |
| Event HubsやStorageへ出力する処理 | 必要なサービス タグ、FQDN、ポートが許可されているか |
| サーバーレス ノートブック | クラシック クラスターと同じ送信元IP前提になっていないか |
| IaCでワークスペースを展開する処理 | リージョン別の固定IPをハードコードしていないか |
| CI/CDでDatabricks Asset Bundlesなどを使う処理 | デプロイ元ネットワークとDatabricks側通信の両方を確認 |
また、Azure Databricksのリリースは段階的に展開されるため、すべてのアカウントに同じタイミングで反映されるとは限りません。リリースノート上でも、初回リリース日から1週間以上たってから更新される場合があると説明されています。検証環境で問題がない場合でも、本番環境の反映タイミングやワークスペース差分を確認してください。(Microsoft Learn)
安全に移行・展開する進め方
Azure DatabricksのIPアドレスとドメイン設定を見直す場合は、次の順序で進めるのが現実的です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 棚卸し | ワークスペース、リージョン、SCC、Private Link、サーバーレス利用を整理 | 影響対象一覧 |
| 方針決定 | サービス タグ、FQDN、個別IPのどれで許可するか決める | ネットワーク許可方針 |
| 設計 | UDR、NSG、Azure Firewall、NVA、DNSの変更内容を作る | 変更設計書 |
| 検証 | 検証環境でクラスター起動、ジョブ、DBFS、ログ出力を確認 | テスト結果 |
| 段階反映 | 影響の小さいワークスペースから反映 | 変更履歴 |
| 監視 | 接続エラー、DNS解決、ファイアウォールログを監視 | 運用監視ルール |
| 自動化 | サービス タグやJSON差分を定期確認 | 継続運用フロー |
個別IPを使わざるを得ない組織ポリシーがある場合でも、手作業更新は避けるべきです。DNS解決、サービス タグ情報、サーバーレス用JSONを定期的に取得し、変更差分をレビューできる形にしておくと、将来のIP変更に強くなります。
まとめ：次に取るべき行動
Azure DatabricksのIPアドレスとドメイン情報は、ネットワーク制御を厳格にしている環境ほど重要です。まずは、対象ワークスペースをリージョン、SCC、Private Link、サーバーレス利用有無で棚卸ししてください。
そのうえで、可能な限りAzureDatabricks、Storage、EventHubなどのサービス タグを使い、SCCリレーはFQDNで許可します。UK Southを使っている場合は新規ワークスペースと既存ワークスペースを分け、サーバーレス コンピューティング ファイアウォール プレビューを使っている場合は旧静的IPリストからJSONベースの更新運用へ移行します。
最後に、変更後はクラスター起動だけでなく、DBFS、メタストア、Blob storage、Event Hubs、外部接続、サーバーレス ジョブまで確認してください。ネットワーク許可は「一度設定して終わり」ではなく、Azure Databricksのリージョン拡張や基盤更新に合わせて継続的に見直す運用が必要です。
コメント