SteveOstrowski
Databricks Employee
Databricks Employee

‎03-07-2026 04:33 PM

Hi mat723,

That approach is sound and is actually a fairly common pattern. Standing up a public-facing proxy/gateway that is locked down to only the partner's IP ranges, with the backend connecting to the Databricks workspace over Private Link, gives you a clean separation of concerns: your proxy handles partner authentication and ingress filtering, while the workspace itself remains fully private with no public network exposure.

A few things to keep in mind:

  • Security: Make sure your proxy enforces TLS termination and re-encryption on the backend leg to Databricks. Also ensure that the proxy is hardened -- it becomes the sole public entry point, so it needs to be kept patched and monitored. Consider adding WAF rules if using something like Azure Application Gateway or a third-party reverse proxy.
  • Authentication pass-through: The proxy needs to correctly forward Databricks authentication headers (typically a Bearer token for REST APIs, or JDBC auth parameters). Verify that the proxy does not strip or modify Authorization headers.
  • Cost: As you noted, there is a cost to running the proxy infrastructure. Depending on throughput, an Azure Application Gateway or a small VM-based NGINX/HAProxy setup could work. For lower traffic, a lightweight VM is usually sufficient. For production workloads with high concurrency, Application Gateway with autoscaling may be more appropriate.
  • DNS resolution: Since the proxy connects to the workspace via Private Link, it needs to resolve the workspace URL to the private endpoint IP. Make sure your proxy's DNS is configured to use a private DNS zone linked to the VNet where the Private Link endpoint lives.
  • Latency: Adding a proxy hop introduces some latency. For REST API calls this is usually negligible. For high-volume JDBC/ODBC workloads, measure the impact to make sure it meets your performance requirements.

Overall, this is a valid and well-architected pattern. It is essentially a variant of Options 3 and 4 from my earlier response, with the proxy replacing the need for a direct VPN or ExpressRoute connection to the partner. The key advantage is that the partner does not need any Azure infrastructure on their side -- they just need network access to your proxy endpoint.

Sources:

0 Kudos