Configure DNS for AWS inbound Private Link

Preview

Private access to account-level resources is in Beta.

Private access to workspaces using context-based ingress is in Beta.

Configure DNS to route user requests through your private network when using inbound Private Link for Databricks workspaces and account-level resources. This page covers DNS configuration patterns and step-by-step setup instructions. Although you can configure DNS for AWS Private Link in multiple ways, this page defaults to a recommended approach that works for most deployments.

note

Back-end Private Link endpoints automatically use AWS DNS resolution when you enable the Enable DNS name option on the VPC endpoint. This page focuses on inbound Private Link DNS configuration.

Architecture overview

The following diagrams illustrate the two DNS resolution patterns for AWS Private Link. The pattern you choose depends on your organizational requirements for endpoint management and isolation.

The single endpoint approach routes all workspaces in any region and account-level resources through one shared VPC endpoint, which simplifies DNS configuration and management. This page defaults to this recommended approach for all configuration instructions.

The multi-endpoint approach lets you route requests for each workspace and account-level resource to dedicated VPC endpoints for network isolation, but increases management complexity.

DNS resolution with Private Link

Without Private Link, workspace-specific URLs (for example, dbc-<workspace-deployment-id>.cloud.databricks.com) resolve to public IP addresses through a regional hostname like sydney.cloud.databricks.com, which points to a public AWS Elastic Load Balancer. For example:

Bash

$ nslookup myworkspace.cloud.databricks.com

myworkspace.cloud.databricks.com    canonical name = sydney.cloud.databricks.com
sydney.cloud.databricks.com         canonical name = public-ingress-xxxxx.elb.ap-southeast-2.amazonaws.com
Name:    public-ingress-xxxxx.elb.ap-southeast-2.amazonaws.com
Address: 3.26.4.13

After you attach a private access settings object to a workspace, Databricks updates the DNS resolution chain to include the privatelink subdomain:

Bash

$ nslookup myworkspace.cloud.databricks.com

myworkspace.cloud.databricks.com    canonical name = sydney.privatelink.cloud.databricks.com
Name:    sydney.privatelink.cloud.databricks.com
Address: 10.176.10.182

The workspace-specific URL now resolves to sydney.privatelink.cloud.databricks.com, which you configure to point to your VPC endpoint's private IP address. This allows you to override only the privatelink.cloud.databricks.com domain without affecting other Databricks services.

Custom URLs (<my-custom-account-name>.databricks.com) and accounts.cloud.databricks.com do not include the privatelink subdomain in their DNS resolution chain and should be forwarded separately.

Bash

$ nslookup <my-custom-account-name>.databricks.com
Name: my-custom-account-name.databricks.com
Address: 3.26.4.13

$ nslookup accounts.cloud.databricks.com
Name:    accounts.cloud.databricks.com
Address: 3.26.4.13

important

After you attach a private access settings object to a workspace, you cannot remove it. You can only replace it with a different private access settings object. This configuration is permanent.

DNS resolution

The specific DNS records you need depend on your configuration approach, but all configurations should resolve Databricks URLs (both custom and non-custom URLs) to the private IP address of your inbound VPC endpoint. For simplicity, Databricks recommends routing all URLs to a single VPC endpoint to access all of Databricks. If you have network isolation requirements, you can also route different URLs to different VPC endpoints, where each endpoint is granted different access in your context-based ingress policies (see Configure inbound PrivateLink for workspaces).

Single endpoint approach (recommended)

For most deployments, configure DNS to resolve all URLs to a single VPC endpoint's private IP. All workspaces in any region and your account-level resources can share the same VPC endpoint. This unified endpoint can serve resources using both non-custom and custom URLs. This is the recommended approach for simplified management.

On-premises DNS configuration

Configure conditional forwarding in your corporate DNS to forward Databricks domain queries to AWS:

Domain	Forwarding target	Purpose
*.privatelink.cloud.databricks.com OR dbc-<workspace-deployment-id>.cloud.databricks.com (one override per workspace) OR *.cloud.databricks.com	AWS DNS endpoint (Route 53 inbound resolver)	Always required. Forwards workspace-specific URLs for workspaces with a private access setting attached. This is always required, since certain workspace services, such as Databricks Apps and Model Serving, still rely on the workspace-specific URL, not the <my-custom-account-name>.databricks.com custom URL. Instead of forwarding *.privatelink.cloud.databricks.com, you can alternatively forward every workspace-specific URL individually or *.cloud.databricks.com. This is required if your users cannot access the public internet for DNS resolution, or if you require different VPC endpoints for different workspaces.
<my-custom-account-name>.databricks.com	AWS DNS endpoint (Route 53 inbound resolver)	Required (if you use custom URLs). Forwards your custom URL, which can include both workspace and account-level traffic.
accounts.cloud.databricks.com	AWS DNS endpoint (Route 53 inbound resolver)	Optional. Forwards your non-custom account-level resource URL (also used for unified login). Only required if your users cannot access the public internet for DNS resolution or requests (see Configure inbound Private Link with unified login). This can also be useful if you do not want to use your custom URL but still want inbound Private Link to account-level resources.
*.aws.databricksapps.com	AWS DNS endpoint (Route 53 inbound resolver)	Optional. Forwards Databricks Apps requests. Only required if your users cannot access the public internet for DNS resolution (that is, you use manual DNS configuration). Otherwise, workspace-specific URL forwarding is sufficient.

Domain	Forwarding target	Purpose
*.privatelink.cloud.databricks.com OR dbc-<workspace-deployment-id>.cloud.databricks.com (one override per workspace) OR *.cloud.databricks.com	AWS DNS endpoint (Route 53 inbound resolver)	Always required. Forwards workspace-specific URLs for workspaces with a private access setting attached. This is always required, since certain workspace services, such as Databricks Apps and Model Serving, still rely on the workspace-specific URL, not the <my-custom-account-name>.databricks.com custom URL. Instead of forwarding *.privatelink.cloud.databricks.com, you can alternatively forward every workspace-specific URL individually or *.cloud.databricks.com. This is required if your users cannot access the public internet for DNS resolution, or if you require different VPC endpoints for different workspaces.
<my-custom-account-name>.databricks.com	AWS DNS endpoint (Route 53 inbound resolver)	Required (if you use custom URLs). Forwards your custom URL, which can include both workspace and account-level traffic.
accounts.cloud.databricks.com	AWS DNS endpoint (Route 53 inbound resolver)	Optional. Forwards your non-custom account-level resource URL (also used for unified login). Only required if your users cannot access the public internet for DNS resolution or requests (see Configure inbound Private Link with unified login). This can also be useful if you do not want to use your custom URL but still want inbound Private Link to account-level resources.
*.aws.databricksapps.com	AWS DNS endpoint (Route 53 inbound resolver)	Optional. Forwards Databricks Apps requests. Only required if your users cannot access the public internet for DNS resolution (that is, you use manual DNS configuration). Otherwise, workspace-specific URL forwarding is sufficient.

note

For Databricks on AWS GovCloud, forward *.cloud.databricks.us and *.aws-gov.databricksapps.us instead. For AWS GovCloud DoD, forward *.cloud.databricks.mil and *.aws-dod.databricksapps.mil. See Databricks on AWS GovCloud.

Private Hosted Zone configuration

You need to create Private Hosted Zones to route the following URLs to VPC endpoints:

• Required if you use custom URLs: your custom URL.
• Always required: workspace-specific URLs, such as dbc-<workspace-deployment-id>.cloud.databricks.com or <region>.privatelink.cloud.databricks.com.
• Optional: accounts.cloud.databricks.com. Only required if your users cannot access the public internet for DNS resolution or requests. If that is the case, you need to route accounts.cloud.databricks.com to enable private unified login (see Configure inbound Private Link with unified login). This can also be useful if you do not want to use your custom URL but still want inbound Private Link to account-level resources.

In the single endpoint approach, you can route all of these URLs to a single shared General Access VPC endpoint.

First, create a Private Hosted Zone for your custom URL. Your custom URL can serve the UI and API of all of your workspaces in any region, and account-level resources.

Configuration	Value
Private Hosted Zone	<my-custom-url>.databricks.com
Record name	leave blank
Record type	A (Alias)
Record value	VPC endpoint ID

Configuration	Value
Private Hosted Zone	<my-custom-url>.databricks.com
Record name	leave blank
Record type	A (Alias)
Record value	VPC endpoint ID

Second, create a Private Hosted Zone for the privatelink.cloud.databricks.com domain, to route your workspace-specific URLs (for example, dbc-<workspace-deployment-id>.cloud.databricks.com). This is always required, since certain workspace services, such as Databricks Apps and Model Serving, still rely on the workspace-specific URL, not the custom URL.

Configuration	Value
Private Hosted Zone	privatelink.cloud.databricks.com
Record name	leave blank or <region>
Record type	A (Alias)
Record value	VPC endpoint ID

Configuration	Value
Private Hosted Zone	privatelink.cloud.databricks.com
Record name	leave blank or <region>
Record type	A (Alias)
Record value	VPC endpoint ID

For simplicity, Databricks recommends routing all URLs to a single endpoint. However, you can use the <region> value if you require different routing for workspaces in different regions. The region value is the Databricks region name, for example, sydney, virginia, oregon, not the AWS region name. To find the correct region name for your workspace, see the Control plane services, including webapp row in Inbound IPs.

If your AWS setup cannot access the public internet for DNS resolution, or if you require different VPC endpoints for different workspaces, create a Private Hosted Zone for each workspace URL instead of privatelink.cloud.databricks.com.

Configuration	Value
Private Hosted Zone	dbc-<workspace-deployment-id>.cloud.databricks.com (your workspace-specific URL)
Record name	leave blank
Record type	A (Alias)
Record value	VPC endpoint ID

Configuration	Value
Private Hosted Zone	dbc-<workspace-deployment-id>.cloud.databricks.com (your workspace-specific URL)
Record name	leave blank
Record type	A (Alias)
Record value	VPC endpoint ID

Optionally, create a Private Hosted Zone for accounts.cloud.databricks.com. Only required if your users cannot access the public internet. If that is the case, you need to route accounts.cloud.databricks.com to enable private unified login (see Configure inbound Private Link with unified login). This can also be useful if you do not want to use your custom URL but still want inbound Private Link to account-level resources.

Configuration	Value
Private Hosted Zone	accounts.cloud.databricks.com
Record name	leave blank
Record type	A (Alias)
Record value	VPC endpoint ID

Configuration	Value
Private Hosted Zone	accounts.cloud.databricks.com
Record name	leave blank
Record type	A (Alias)
Record value	VPC endpoint ID

Multi-endpoint approach

Using separate endpoints for different workspaces, regions, or account-level resources requires additional DNS configuration and increases operational complexity. Use this approach only when you need isolated VPC endpoints for specific security, compliance, or networking requirements.

If you need separate VPC endpoints for individual workspaces or account-level resources, follow the same general steps as the single-endpoint approach. However, instead of routing all Databricks URLs to one VPC endpoint, configure DNS so different URLs resolve to different VPC endpoints based on your requirements.

After the endpoints are registered, use context-based ingress to control which workspaces and account-level resources each registered private endpoint can access. For more information, see Configure inbound PrivateLink for workspaces and Configure inbound Private Link for account-level resources.

Example configurations

The following examples illustrate common routing patterns. You can choose any routing model that fits your security, compliance, or networking requirements.

Example 1: Unified endpoint for production, non-production, and account-level resources (single-endpoint approach)

In this example, all workspaces and account-level resources are accessed through a single VPC endpoint.

Configure the following routing and context-based ingress policies:

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
*.privatelink.cloud.databricks.com	*.privatelink.cloud.databricks.com	Registered endpoint 1	Create a workspace policy that allows ingress from endpoint 1, and attach it to all workspaces.

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
*.privatelink.cloud.databricks.com	*.privatelink.cloud.databricks.com	Registered endpoint 1	Create a workspace policy that allows ingress from endpoint 1, and attach it to all workspaces.

With this configuration, users can access over inbound Private Link:

• Account-level resources, such as the account console and account-level Genie, using your custom URL.
• All workspaces using your custom URL.
• All workspaces using workspace-specific URLs.

Example 2: Separate endpoints for production, non-production, and account-level resources (multi-endpoint approach)

In this example, production workspaces, non-production workspaces, and account-level resources are accessed through separate isolated VPC endpoints.

Configure the following routing and context-based ingress policies:

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
Individual production workspace-specific URLs or *.cloud.databricks.com	Individual production workspace-specific URLs	Registered endpoint 2	Create a workspace policy that allows ingress from endpoint 2, and attach it to your production workspaces.
Individual non-production workspace-specific URLs or *.cloud.databricks.com	Individual non-production workspace-specific URLs	Registered endpoint 3	Create a workspace policy that allows ingress from endpoint 3, and attach it to your non-production workspaces.

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
Individual production workspace-specific URLs or *.cloud.databricks.com	Individual production workspace-specific URLs	Registered endpoint 2	Create a workspace policy that allows ingress from endpoint 2, and attach it to your production workspaces.
Individual non-production workspace-specific URLs or *.cloud.databricks.com	Individual non-production workspace-specific URLs	Registered endpoint 3	Create a workspace policy that allows ingress from endpoint 3, and attach it to your non-production workspaces.

With this configuration, users can access over inbound Private Link:

• Account-level resources, such as the account console and account-level Genie, using your custom URL.
• Production workspaces using production workspace-specific URLs.
• Non-production workspaces using non-production workspace-specific URLs.

Example 3: Separate endpoints for workspaces in different regions, and account-level resources (multi-endpoint approach)

In this example, workspaces in region A, workspaces in region B, and account-level resources are accessed through separate isolated VPC endpoints.

Configure the following routing and context-based ingress policies:

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
*.privatelink.cloud.databricks.com	<region A>.privatelink.cloud.databricks.com	Registered endpoint 2	Create a workspace policy that allows ingress from endpoint 2, and attach it to your workspaces in region A.
*.privatelink.cloud.databricks.com	<region B>.privatelink.cloud.databricks.com	Registered endpoint 3	Create a workspace policy that allows ingress from endpoint 3, and attach it to your workspaces in region B.

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
*.privatelink.cloud.databricks.com	<region A>.privatelink.cloud.databricks.com	Registered endpoint 2	Create a workspace policy that allows ingress from endpoint 2, and attach it to your workspaces in region A.
*.privatelink.cloud.databricks.com	<region B>.privatelink.cloud.databricks.com	Registered endpoint 3	Create a workspace policy that allows ingress from endpoint 3, and attach it to your workspaces in region B.

With this configuration, users can access over inbound Private Link:

• Account-level resources, such as the account console and account-level Genie, using your custom URL.
• Workspaces in region A using workspace-specific URLs.
• Workspaces in region B using workspace-specific URLs.

Example 4: Shared endpoint for production and account-level resources, separate endpoint for non-production (multi-endpoint approach)

In this example, production workspaces and account-level resources share one isolated VPC endpoint, while non-production workspaces use a separate VPC endpoint.

Configure the following routing and context-based ingress policies:

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
Individual production workspace-specific URLs or *.cloud.databricks.com	Individual production workspace-specific URLs	Registered endpoint 1	Also create a workspace policy that allows ingress from endpoint 1, and attach it to your production workspaces.
Individual non-production workspace-specific URLs or *.cloud.databricks.com	Individual non-production workspace-specific URLs	Registered endpoint 2	Create a workspace policy that allows ingress from endpoint 2, and attach it to your non-production workspaces.

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
Custom URL	Custom URL	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.
Individual production workspace-specific URLs or *.cloud.databricks.com	Individual production workspace-specific URLs	Registered endpoint 1	Also create a workspace policy that allows ingress from endpoint 1, and attach it to your production workspaces.
Individual non-production workspace-specific URLs or *.cloud.databricks.com	Individual non-production workspace-specific URLs	Registered endpoint 2	Create a workspace policy that allows ingress from endpoint 2, and attach it to your non-production workspaces.

With this configuration, users can access over inbound Private Link:

• Account-level resources, such as the account console and account-level Genie, using your custom URL.
• Production workspaces using your custom URL.
• Production workspaces using production workspace-specific URLs.
• Non-production workspaces using non-production workspace-specific URLs.

Production and account-level traffic remain isolated from non-production workspace traffic by using separate VPC endpoints.

In all of the above configurations, you did not need to forward accounts.cloud.databricks.com, since it is optional (see Configure inbound Private Link with unified login). If you decide to forward this URL for unified login, you can resolve it to any registered VPC endpoint. If you decide to forward this URL to access account-level resources privately without using your custom URL, configure the following routing and context-based ingress policy:

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
accounts.cloud.databricks.com	accounts.cloud.databricks.com	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.

Forwarding	Private Hosted Zone Record	Routed to VPC endpoint	Context-based ingress configuration
accounts.cloud.databricks.com	accounts.cloud.databricks.com	Registered endpoint 1	In the account-policy, add an allow rule for endpoint 1 to access account-level resources.

tip

Keep the following guidelines in mind:

• Your custom URL, workspace-specific URLs, and the account URL can all route to the same VPC endpoint, or to separate VPC endpoints based on your isolation requirements.
• Your custom URL can be used to access both workspaces and account-level resources.
• Use context-based ingress to control which workspaces and account-level resources each registered endpoint can access. See Context-based ingress control.

Configuration options

Conditional forwarding to Route 53 (recommended)

Configure your corporate DNS to forward queries for Databricks domains to Amazon Route 53. AWS automatically resolves workspace URLs to private IPs without manual record management. This approach uses a single VPC endpoint for all workspaces in any region.

Benefits of conditional forwarding

• Automatic resolution: Route 53 automatically resolves URLs to private IPs when the VPC endpoint has the Enable DNS name option enabled.
• No manual updates: If VPC endpoint IPs change, Route 53 automatically updates DNS records.
• Simplifies management: A single configuration handles all workspaces in any region.

Prerequisites

Before you begin, verify that you have:

• An inbound Private Link VPC endpoint with Enable DNS name enabled
• Network connectivity between your corporate network and AWS using Direct Connect or VPN
• Permissions to create Route 53 resources and modify your corporate DNS

Step 1: Create a private hosted zone

Create a private hosted zone in Route 53 for Databricks DNS records.

1. Go to the Route 53 Hosted zones page in the AWS Management Console.
2. Click Create hosted zone.
3. For Domain name, enter the PHZ name. For example, my-custom-account-name.databricks.com.
4. For Type, select Private hosted zone.
5. In the VPCs to associate section, select the VPC where your inbound VPC endpoint is located. This is typically your transit VPC.
6. Click Create hosted zone.

Step 2: Create a DNS A record

Create an A record that maps the regional endpoint to your VPC endpoint's private IP address.

1. In the Route 53 console, select the hosted zone you created (for example, <my-custom-account-name>.databricks.com).

2. Click Create record.

3. For Record name, enter the appropriate value (see previous sections).

4. For Record type, select A - Routes traffic to an IPv4 address.

5. For Value, enter the private IP address of your inbound VPC endpoint.

   To find the private IP:

   1. Go to the VPC endpoints page.
   2. Select your inbound VPC endpoint.
   3. In the Subnets tab, note the IPv4 address.

6. Click Create records.

tip

Repeat Steps 1 and 2 for each PHZ required above.

Step 3: Create a Route 53 inbound resolver endpoint

Create an inbound resolver endpoint so your corporate DNS can forward queries to Route 53.

1. Go to the Route 53 Resolver page.
2. In the left navigation, click Inbound endpoints.
3. Click Create inbound endpoint.
4. Provide a name for the endpoint, such as databricks-privatelink-resolver.
5. Select your VPC.
6. For Security group, select or create a security group that allows inbound TCP and UDP traffic on port 53 from your on-premises network.
7. In the IP addresses section:
   • Select at least two subnets in different Availability Zones for high availability.
   • For each subnet, either let AWS automatically assign an IP address or choose a specific IP address within the subnet range.
8. Click Create inbound endpoint.
9. Note the IP addresses of the inbound resolver endpoint for use in the next step.

Step 4: Configure conditional forwarding in your corporate DNS

Configure your corporate DNS server to forward queries for Databricks domains to the Route 53 inbound resolver endpoint.

The exact steps depend on your DNS software, such as BIND, Windows DNS, or Infoblox. See your DNS server documentation for specific configuration steps.

Configure conditional forwarding for the domains listed in the On-premises DNS configuration section above.

Forward these domains to the IP addresses of your Route 53 inbound resolver endpoint.

Verification

After you complete the configuration, test DNS resolution for each URL from your corporate network. For example:

Bash

$ nslookup <my-custom-account-name>.databricks.com

Name:    <my-custom-account-name>.databricks.com
Address: 10.176.10.182

The URL should resolve to the private IP address of your VPC endpoint. If you see a public IP address, verify your conditional forwarding rules and Route 53 configuration.

Manual DNS zone and records

If conditional forwarding to Route 53 isn't available in your environment, you can manually create a DNS zone and records in your corporate DNS server. This approach requires manual updates if VPC endpoint IP addresses change.

Benefits of manual DNS zone

Use manual DNS configuration when:

• You can't configure conditional forwarding to AWS Route 53
• Your corporate DNS policies require all DNS records to be managed internally
• You need full control over DNS record management

warning

With manual DNS configuration, update the A records whenever your VPC endpoint IP addresses change. This can lead to connectivity issues if records become outdated.

Step 1: Create a DNS zone

In your corporate DNS server, create a zone for the domains listed in the On-premises DNS configuration section above.

For Databricks on AWS GovCloud, create a zone for privatelink.cloud.databricks.us instead. For AWS GovCloud DoD, use privatelink.cloud.databricks.mil.

Step 2: Add A records

Create an A record that maps the regional endpoint to your VPC endpoint's private IP. For example:

Record name	Record type	Value
<my-custom-account-name>.databricks.com	A	Private IP of your inbound VPC endpoint

Record name	Record type	Value
<my-custom-account-name>.databricks.com	A	Private IP of your inbound VPC endpoint

For AWS GovCloud, the region name is pendleton and the domain is privatelink.cloud.databricks.us. For AWS GovCloud DoD, use privatelink.cloud.databricks.mil. Also add forwarding or records for *.aws-gov.databricksapps.us (GovCloud) or *.aws-dod.databricksapps.mil (DoD) if you use Databricks Apps.

Verification

Test DNS resolution from your corporate network. For example:

Bash

$ dig +short <my-custom-account-name>.databricks.com

<my-custom-account-name>.databricks.com
10.176.10.182

The URL should resolve to the private IP address of your VPC endpoint.

Special deployment scenarios

Mixed deployments

You can have some workspaces using inbound Private Link and others using public endpoints in the same account. DNS resolution automatically handles this scenario.

Workspaces without a private access settings object resolve to public IP addresses using <region>.cloud.databricks.com. Workspaces with a private access settings object resolve to <region>.privatelink.cloud.databricks.com and use the private IP.

No additional DNS configuration is required for mixed deployments.

Hybrid access (private and public endpoints)

You can configure a workspace to be accessible from both private endpoints using Private Link and public endpoints using the internet.

To enable hybrid access:

1. When creating a Private Access Settings object, set Public access enabled to True.
2. The workspace is now accessible through both Private Link and public internet.
3. Users on your corporate network with private DNS configured automatically use the private endpoint.
4. Users outside your corporate network use the public endpoint.

To restrict which public IP addresses can access the workspace, configure IP access lists. This allows you to allowlist specific source IP addresses, such as those from trusted third-party SaaS applications.

Databricks Apps domains

Databricks Apps use the domain *.aws.databricksapps.com. These domains use a CNAME record that resolves to dbc-<workspace-deployment-id>.cloud.databricks.com, which resolves to the regional endpoint.

For example:

Bash

$ nslookup natural-language-to-qdrant-1016658646341465.aws.databricksapps.com

natural-language-to-qdrant-1016658646341465.aws.databricksapps.com
    canonical name = dbc-35bfa1f1-1292.cloud.databricks.com
dbc-35bfa1f1-1292.cloud.databricks.com
    canonical name = oregon.cloud.databricks.com

If you use conditional forwarding for *.cloud.databricks.com, apps domains automatically resolve correctly. If you use manual DNS configuration, you also need to forward *.aws.databricksapps.com or create corresponding records.

AWS GovCloud: Apps use the domain *.aws-gov.databricksapps.us, which CNAMEs to dbc-<id>.cloud.databricks.us. If you use conditional forwarding for *.cloud.databricks.us, apps domains automatically resolve correctly. If you use manual DNS configuration, also forward *.aws-gov.databricksapps.us.

Bash

$ nslookup myapp-5271208389338040.aws-gov.databricksapps.us

myapp-5271208389338040.aws-gov.databricksapps.us
    canonical name = dbc-a1b2c3d4.cloud.databricks.us
dbc-a1b2c3d4.cloud.databricks.us
    canonical name = pendleton.cloud.databricks.us

AWS GovCloud DoD: Apps use the domain *.aws-dod.databricksapps.mil, which CNAMEs to dbc-<id>.cloud.databricks.mil. If you use conditional forwarding for *.cloud.databricks.mil, apps domains automatically resolve correctly. If you use manual DNS configuration, also forward *.aws-dod.databricksapps.mil.

For more information about Databricks Apps networking, see Ingress controls.

Verification

After configuring DNS, verify that your URLs resolve correctly to private IP addresses.

Use nslookup

From a machine on your corporate network, test DNS resolution:

Bash

$ nslookup myworkspace.cloud.databricks.com

Expected output:

myworkspace.cloud.databricks.com    canonical name = sydney.privatelink.cloud.databricks.com
Name:    sydney.privatelink.cloud.databricks.com
Address: 10.176.10.182

The URL should resolve through the privatelink subdomain to a private IP address, typically in the 10.x.x.x, 172.16.x.x, or 192.168.x.x range.

Use dig

You can also use dig for more detailed DNS information:

Bash

$ dig +short myworkspace.cloud.databricks.com

sydney.privatelink.cloud.databricks.com
10.176.10.182

Test workspace access

After verifying DNS resolution, test that you can access the workspace or account-level resources:

1. From a machine on your corporate network or connected through VPN, open a web browser.
2. Go to your URL (custom URL, or non-custom URLs).
3. Verify that you can log in and access the workspace or account-level resource.

If you can't access the workspace:

• Verify that your VPC endpoint has the Enable DNS name option enabled.
• Check that your Private Hosted Zone is associated with the correct VPC.
• Verify that your conditional forwarding rules are configured correctly in your corporate DNS.
• Confirm that network connectivity exists between your corporate network and the AWS VPC using Direct Connect or VPN.
• Check security group rules on your VPC endpoint allow inbound TCP traffic on port 443.

Common issues

DNS resolution returns public IPs: Your conditional forwarding rules aren't working correctly, or queries aren't reaching Route 53. Verify your DNS server configuration and Route 53 inbound resolver endpoint.

URL doesn't resolve: Your Private Hosted Zone may not have the correct A record, or the hosted zone isn't associated with the right VPC. Verify your Route 53 configuration.

Can't access workspace or account-level resource after DNS resolves: Check network connectivity and security group rules. Verify that your corporate network can reach the VPC endpoint's private IP on port 443.

Best practice: consistent DNS resolution for classic compute plane Private Link

If you also configure classic compute plane Private Link, ensure that the workspace URL and the intermediate Private Link URL resolve to the same VPC endpoint within your compute plane VPC. When compute starts, Databricks worker nodes use both the workspace URL and the intermediate Private Link URL to reach the control plane. If these URLs resolve to different VPC endpoints, this can conflict with your private access settings policy and cause compute failures.

To identify all DNS names in your workspace's resolution chain, do a public DNS lookup on your workspace URL using a tool such as Google Dig. The chain typically includes your workspace URL and the intermediate Private Link URL, which has the format dbc-dp-<workspace-id>.cloud.databricks.com.

Ensure both resolve to the same VPC endpoint using one of the following approaches:

• Override DNS for the intermediate Private Link URL only: Do not configure an explicit DNS override for the workspace URL. Use a DNS solution that supports DNS chaining, such as AWS Route 53. Because the workspace URL publicly resolves through the intermediate Private Link URL, DNS chaining intercepts the chain and resolves both to your VPC endpoint's private IP.
• Override DNS for the workspace URL: Configure the workspace URL to resolve to the same private IP as the intermediate Private Link URL. If your compute plane VPC has public DNS connectivity, remove any explicit overrides on the workspace URL. If your VPC uses private DNS only, add an explicit override to match the intermediate Private Link URL's resolution.

To verify, run the following from within your compute plane VPC. Both commands should return the same private IP address:

sh

nslookup <workspace-url>
nslookup dbc-dp-<workspace-id>.cloud.databricks.com

What's next

• Enable inbound (front-end)Private Link: If you haven't already set up Private Link, see Configure inbound PrivateLink for workspaces.
• Enable classic compute plane Private Link: Complete your private connectivity setup by configuring Private Link from your compute plane to the control plane. See Configure classic private connectivity to Databricks.
• IP access lists: Add an additional layer of security by controlling which public IP addresses can access your workspace. See Configure IP access lists for workspaces.