Azure Databricks Serverless から社内アプリへ接続したいのに、送信元IPが固定できず Azure Firewall のホワイトリストで詰まる…という相談は多いです。リージョン別IPの落とし穴を整理し、Service Tag・IP Group 自動更新・Private Link（NCC）で解決する手順を具体例でまとめます。
なぜ「リージョン別 IP/ドメイン」を許可しても期待どおり動かないのか
最初に結論を言うと、Azure Databricks の「リージョン別 IP/ドメイン」一覧は、主にワークスペースの制御プレーン（control plane）まわりの通信（Web アプリや API、SCC など）を前提に整理されています。Serverless のワークロードが社内アプリへ出ていく通信は、同じ “Databricks” でも別の経路・前提が絡むため、ここだけを許可しても一致しないケースがあります。
さらに、Microsoft が公開している「Azure IP Ranges and Service Tags – Public Cloud」の JSON は網羅的である一方、運用で毎週のように大量の IP プレフィックスを追いかけることになりがちです。結果として「許可したはずなのに通らない」「更新に追従できず突然落ちる」の両方が起こりやすくなります。
| 混同しやすいもの | 主に守りたい対象 | 典型的な用途 | 今回（Serverless→社内アプリ）への効きやすさ |
|---|---|---|---|
| リージョン別 IP/ドメイン（Databricks ドキュメント） | Databricks 制御プレーン | UDR/ファイアウォール環境でのワークスペース運用 | △（目的がズレると効かない） |
| Azure IP Ranges and Service Tags（Microsoft 公開 JSON） | Azure 全体 | オンプレ/周辺 FW の許可リスト | ○（ただし範囲が広すぎて運用が重い） |
| サービス タグ（Service Tag） | 特定 Azure サービス | NSG / ルート / 一部 FW での “自動追従” 設計 | ◎（設計の中心にすると運用が楽） |
| NCC（Network Connectivity Configuration）と Private Link | Serverless の閉域接続 | Serverless→Azure リソース/社内リソースへのプライベート接続 | ◎（IP ではなく接続方式で解決） |
まず押さえる：Serverless は「固定送信元 IP を手で許可」しにくい
Serverless は、実行基盤（サーバレス コンピュート プレーン）が Databricks 側で管理され、必要に応じて動的にスケールします。つまり、従来の「この VM/サブネットの IP だけ許可すればよい」という発想が、そのまま当てはまりにくいのが前提です。
そのため、社内アプリ側をIP allowlist 前提で設計している場合ほど、どこで “固定点” を作るか（Private Link に寄せるのか、安定 NAT を使うのか、サービス タグを元に自動更新するのか）が重要になります。
サービス タグ（Service Tag）とは何か
サービス タグは、特定の Azure サービスが使用する IP プレフィックス群をタグ名としてまとめた仕組みです。ルールの送信元/宛先にタグ名を指定すると、IP レンジの増減は Microsoft 側で管理・更新されるため、個別 IP を手で追いかける負担を大きく減らせます。
Azure Databricks についても、Databricks 側ドキュメントで個別 IP ではなくサービス タグの利用が強く推奨されており、代表的なタグ名が AzureDatabricks です。
ただし、AzureDatabricks サービス タグが主に説明されるのは「classic compute（VNet injection）環境で、Databricks クラスターが制御プレーンへ到達するための必須通信」を成立させる文脈です。Serverless の社内アプリ向け通信を IP allowlist で成立させたい場合は、まず Serverless 専用の仕組み（NCC/Private Link/安定 NAT）を優先し、サービス タグは “補助線” として扱う方が安全です。
重要：Azure Firewall では “サービス タグを送信元にする” ことができない
サービス タグは NSG などでは送信元/宛先に使えますが、Azure Firewall のネットワーク ルールでサービス タグを指定できるのは宛先（Destination）のみで、送信元（Source）には使えません。つまり「Azure Firewall で Databricks の送信元 IP をサービス タグでホワイトリスト化したい」という要求は、設計上そのままでは実現しません。
ただし、だからといって “サービス タグは使えない” ではなく、サービス タグを元データとして IP プレフィックスを自動取得し、Azure Firewall が扱える形（IP Group など）に落とし込むのが現実的な落としどころです。後半で具体例を紹介します。
解決パターン早見表：どれを選ぶべきか
| 状況 | 推奨アプローチ | 理由 | 実装の要点 |
|---|---|---|---|
| 社内アプリが Azure VNet 内（VM/AKS 等）で、閉域で完結させたい | Private Link（社内側は LB + Private Link Service）＋ Databricks NCC | IP allowlist を捨て、閉域の “接続” で制御できる | Standard Load Balancer を前段にし、NCC に Private Endpoint ルールを作る |
| 社内アプリが Azure PaaS（Storage/Key Vault/SQL 等）で、FW 設定が可能 | NCC のネットワーク ID（安定 CIDR）を allowlist | Serverless 側の接続元を Databricks 管理の安定範囲に寄せられる | Account Console で NCC を作成し、ネットワーク ID を資源側 FW に登録 |
| 社内アプリが「送信元 IP allowlist しかできない」（既存 FW/アプライアンス制約） | （可能なら）Databricks が提供する安定 NAT を allowlist。難しければ、サービス タグ由来の IP プレフィックスを自動取得し、Azure Firewall の IP Group を自動更新 | “個別 IP 手管理” をやめつつ、Azure Firewall の制約も回避できる | Get-AzNetworkServiceTag / JSON を元に IP Group を更新し、Network Rule は IP Group を Source に |
パターン1：社内アプリを閉域化するなら「Private Link + NCC」が最短で堅い
社内アプリが Azure の VNet 内（VM、AKS、オンプレ連携の前段など）にあるなら、Serverless 側から “プライベートに入ってくる” 形を作るのが王道です。Databricks の Serverless は、NCC（Network Connectivity Configuration）を使って Private Link 経由で VNet 内のリソースへ接続でき、前段に Azure Load Balancer を置く構成が公式に案内されています。
前提条件（まずここで詰まりやすい）
- Databricks アカウントとワークスペースが所定のプラン要件を満たしている（例：Enterprise）
- 作業者が Databricks の account admin である
- Serverless ワークスペースが Private Link 接続をサポートするリージョンに存在する
- 社内側の Load Balancer が VNet/サブネットを持ち、社内アプリがその配下にある
- Private endpoint rule は、1 ルールあたり登録できるドメイン数に上限がある
- DNS 追跡（DNS chasing）や DNS リダイレクトはサポートされず、ドメインはバックエンドへ直接解決される必要がある
構成イメージ（要点だけ）
- 社内アプリの前に Standard Load Balancer（内部ロードバランサー）を配置する
- その LB を “公開” するために Private Link Service を作る
- Databricks 側で NCC を作成し、Private endpoint rule に Private Link Service のリソース ID と社内アプリの FQDN を登録する
- Azure 側（Private Link Center）で接続要求を承認する
手順（抜粋）
| 手順 | 操作場所 | やること | ハマりどころ |
|---|---|---|---|
| 1 | Azure Portal | 内部 Load Balancer を作成し、Backend pool に社内アプリを登録 | Health Probe と LB ルール（443/8443 等）を忘れやすい |
| 2 | Azure Portal | Private Link Service を作成（LB と同一リージョン） | 承認フロー（手動/自動）を事前に決める |
| 3 | Databricks Account Console | NCC を作成（ワークスペースと同一リージョン） | リージョン不一致だとアタッチできない |
| 4 | Databricks Account Console | Private endpoint rule を追加（Private Link Service の resource ID と FQDN） | ドメイン名は backend に直解決が必要（DNS 追跡/リダイレクト不可） |
| 5 | Azure Portal | Private endpoint 接続要求を承認し、状態が ESTABLISHED になることを確認 | 承認後に反映まで数分〜10分程度かかる |
| 6 | Databricks | NCC をワークスペースにアタッチし、Serverless を再起動して疎通確認 | 既に稼働中の Serverless リソースは再起動が必要 |
このパターンが強い理由
- 外部公開せずに閉域で完結でき、IP allowlist に依存しない
- 接続は Databricks アカウントに紐づく Private Endpoint となり、許可範囲を “接続単位” で制御しやすい
- Serverless のスケールや基盤更新に引きずられにくい
パターン2：Azure リソース側の FW なら「NCC の安定 CIDR（ネットワーク ID）」を使う
相手が Azure Storage や Key Vault、SQL などの Azure リソースで、リソース側に “ネットワーク許可リスト（FW）” 機能がある場合は、Serverless 用に用意される NCC のネットワーク ID（安定 CIDR ブロック）を allowlist するのが基本です。NCC は account admin が作成し、ワークスペースにアタッチすると Serverless はそのネットワーク ID を使って Azure リソースに接続します。
リソース種別によっては Private Link を使う方が適切な場合もありますが、少なくとも「大量の Azure IP を手で管理する」という状態からは抜けられます。なお、非 Storage のリソース FW で安定 NAT IP が必要な場合は、Databricks のアカウントチームへ相談する案内もあります。
パターン3：それでも “送信元 IP allowlist” しかできない場合の現実解
既存の社内アプリやオンプレ FW など、「送信元 IP の許可」しかできない環境では、最終的に IP プレフィックスの管理が避けられません。ここで “Azure 全体の IP 一覧” を運用するのではなく、サービス タグで範囲を絞り、そのタグの IP プレフィックスだけを自動取得して反映するのがポイントです。
サービス タグの IP プレフィックスは API / PowerShell / JSON で取得できる
サービス タグは、Azure の Service Tag Discovery API や PowerShell から取得できます。例えば PowerShell なら Get-AzNetworkServiceTag でタグ一覧と AddressPrefixes を取り出せます。また Microsoft は、サービス タグと IP プレフィックスを含む JSON を週次で公開しています。
重要なのは、これらを “人が目で見てコピペ” するのではなく、自動で取得 → 自動で反映 → 変更検知（ChangeNumber）までセットにして運用設計に落とすことです。
Azure Firewall での実装：IP Group を Source にして運用を固定化する
前述のとおり Azure Firewall はサービス タグを送信元にできません。そこで、Azure Firewall が送信元として扱える IP Group を使い、そこに “サービス タグ由来の IP プレフィックス” を同期させます。Network Rule は IP Group を Source に設定すれば、目的の「Databricks から社内アプリへの到達」を allowlist できます。
Azure Firewall（Network Rule）設定例
| 項目 | 設定例 | 意図 |
|---|---|---|
| Rule Collection | Allow-Databricks-To-Internal | Databricks→社内アプリ用に分けると追いやすい |
| Action | Allow | 許可ルール |
| Priority | Deny ルールより上 | 競合回避（先にマッチさせる） |
| Protocol | TCP（または Any） | 最小権限（使うプロトコルだけ） |
| Source | IP Group（例：ipg-azuredatabricks） | サービス タグ由来の IP を集約 |
| Destination | 社内アプリの IP（例：10.0.5.4/32） | 社内アプリの待受先 |
| Port | 443 / 8443 など | 社内アプリの待受ポートだけに絞る |
IP Group を “サービス タグから” 自動更新する（PowerShell 例）
以下は、サービス タグの AddressPrefixes を取得し、IP Group を作成/更新する最小構成の例です。実運用では、ChangeNumber の比較、例外時のロールバック、差分更新、監査ログなども組み合わせてください。
$location = "eastus2" # 取得 API 用の場所（例）
$tagName = "AzureDatabricks" # 取得したいサービス タグ
$rg = "rg-network"
$ipgName = "ipg-azuredatabricks"
# サービス タグの IP プレフィックスを取得
$serviceTags = Get-AzNetworkServiceTag -Location $location
$tag = $serviceTags.Values | Where-Object { $_.Name -eq $tagName }
$prefixes = $tag.Properties.AddressPrefixes
# IP Group を作成 or 更新
$ipg = Get-AzIpGroup -ResourceGroupName $rg -Name $ipgName -ErrorAction SilentlyContinue
if (-not $ipg) {
New-AzIpGroup -Name $ipgName -ResourceGroupName $rg -Location $location -IpAddress $prefixes
} else {
$ipg.IpAddresses = $prefixes
Set-AzIpGroup -IpGroup $ipg
}このスクリプトを Azure Automation の Runbook や GitHub Actions などで週次実行し、IP Group を更新すれば、手作業で IP を追いかける運用から抜けられます。
切り分け：到達しないときに見る順番（現場で効くチェックリスト）
| チェック観点 | よくある原因 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| ルール優先度 | Allow が Deny に負けている | Rule Collection の Priority を見直す | Allow を先に評価されるよう調整 |
| Azure Firewall の制約 | サービス タグを Source に指定しようとしている | Network Rule の Source が IP / IP Group になっているか | IP Group 方式へ切り替える |
| 社内アプリ側の受信許可 | NSG / OS FW / アプリ FW が拒否 | 宛先 VM/AKS の受信ルール、LB 健康状態 | 受信ポートと送信元レンジを合わせる |
| ルーティング | 経路が想定と違う（FW を通っていない） | UDR、サブネット関連付け、NVA 経路 | 経路設計を固定（Hub-Spoke など） |
| DNS/名前解決 | Private Link 構成で名前解決がズレる | Databricks から FQDN が期待 IP に解決されるか | Private DNS / カスタム DNS の整合を取る |
疎通確認とログ確認
ネットワークの問題は「通っている/通っていない」を可視化すると一気に楽になります。Azure Firewall を使っている場合は診断ログ（Network rule log）を有効化し、許可/拒否の実態を必ず確認してください。
Databricks 側からの疎通確認は、ノートブックから %sh で curl を叩くのが手軽です（以下は例）。
%sh
curl -v https://10.0.5.4:8443/healthcheckつまずきポイント（実務でハマりやすい順）
- 「どの IP を許可すべきか」の前提がズレている：制御プレーン向けの IP 一覧や説明は、Serverless→社内アプリの通信を保証しないことがある
- Azure Firewall の仕様を見落とす：サービス タグは宛先のみで、送信元には使えない
- allowlist を IP で頑張りすぎる：可能なら Private Link＋NCC の閉域接続に寄せた方が運用は安定する
- サービス タグを過信する：タグは “そのサービス全体” を表すため、追加の認証/認可・最小権限設計が前提になる
まとめ：おすすめの最短ルート
- まずは「Serverless→社内アプリ」を IP allowlist で解決しようとしていないかを見直す
- 閉域化できるなら Private Link（LB + Private Link Service）＋ NCC を最優先で検討する
- Azure リソース側 FW なら、NCC の安定 CIDR（ネットワーク ID） を allowlist して運用負荷を下げる
- IP allowlist が必要なら、サービス タグを元データにして IP Group を自動更新し、Azure Firewall の制約を回避する
- 最後に、ログ（FW/アプリ）で “実際に何が拒否されているか” を見て原因を潰す
コメント