Hardened connectivity

Hardened connectivity builds on Managed security to add layered ingress and egress controls: context-based ingress (CBI), VPC endpoints, serverless egress controls, and an optional external firewall. Workspace access stays on the public internet, gated by CBI.

This architecture has:

• Context-based workspace ingress: Users sign in over the internet, and CBI policies restrict workspace access by network source, identity, authentication mechanism, and access scope. This is a simplicity trade-off compared to VPN-gated architectures.
• Private cloud service access: VPC endpoints (AWS) or service endpoints (Azure) keep cloud service traffic off the public internet.
• Serverless egress control: Network policies and NCC private endpoints govern outbound traffic from serverless compute.
• Optional egress inspection: Deploy an external firewall to inspect and log classic compute egress.
• No VPN required: Simplified user access without corporate network dependency.

Use this architecture when:

• Data security is the primary concern, not workspace access control.
• VPN complexity is a barrier to user productivity.
• IP-based access controls are sufficient for compliance.
• Your organization prefers cloud-first access patterns.

Prerequisites

• Databricks Enterprise plan.

• List of IP ranges for workspace access control.

Architecture overview

The Hardened connectivity architecture secures network traffic and simplifies user access:

Traffic type	Path
User access	Users → Internet → CBI policy → Workspace
Classic compute → control	Compute → Classic PrivateLink → Databricks control plane
Classic compute → cloud	Compute → VPC endpoints → AWS services (S3, STS, Kinesis)
Serverless → your resources	Serverless compute → NCC private endpoints → Your S3 buckets or VPC
Classic compute → egress	Compute → External firewall (optional) → Inspected internet

note

Workspace access is not private in this architecture. Users connect over the public internet, restricted by CBI policies. If your organization requires private workspace access, use the Isolated environment architecture instead.

Required components

Inbound

No inbound PrivateLink. Public internet access is restricted by context-based ingress policies and, optionally, IP access lists. Follow standard IAM for authentication. See Authentication and access control.

Workspace ingress controls

Configure workspace ingress through context-based ingress (CBI), the recommended ingress policy framework. CBI rules combine network source (IP ranges), identity, authentication mechanism, and access scope into a single allow/deny model, so the network-source attribute does the same job as the standalone IP access list feature, plus more.

IP access lists remain supported and can be configured alongside CBI. When both are configured, a request must be allowed by both controls.

Configuration levels:

• Account-level CBI policies: Apply to all workspaces in the account. See Manage context-based ingress policies.
• Workspace-level IP access lists: Apply to a single workspace. See Configure IP access lists for workspaces.
• Account-level IP access lists: Apply to the account console. See Configure IP access lists for the account console.

Best practices:

• Start broad, refine based on actual usage.
• Document IP ranges with purpose and expiration dates.
• Maintain administrator access through a known-good IP range.
• Review quarterly and remove obsolete ranges.

warning

Ingress policies and IP access lists can lock you out of your workspace if misconfigured. Always maintain administrator access through a known-good IP range.

Delta Sharing recipient access control

Delta Sharing uses its own IP access lists configured on recipient objects. This is separate from context-based ingress and workspace IP access lists. Applies to open sharing (non-Databricks recipients) only.

See Restrict Delta Sharing recipient access using IP access lists (open sharing).

Outbound

Serverless egress is governed by network policies and NCC private endpoints. Classic compute egress can optionally flow through an external firewall for inspection. Use Unity Catalog for data governance of outbound data access. See What is Unity Catalog?.

Serverless egress control

Configure network policies to control serverless compute outbound traffic. Define allowed destinations using IP ranges or FQDNs.

See What is serverless egress control?.

Serverless PrivateLink (NCC private endpoints)

Provides private connectivity from serverless compute to your resources through PrivateLink. Serverless data traffic stays off the public internet.

See Configure private connectivity to AWS-managed resources for private connectivity to S3 buckets and Configure private connectivity to resources in your VPC for private connectivity to resources in your VPC.

External firewall for classic compute (optional)

Route classic compute egress through an external firewall for inspection, logging, and policy enforcement. Required in Isolated environment; optional here.

Options include AWS Network Firewall (managed service, integrated with AWS routing) or a third-party appliance such as Palo Alto integrated with Gateway Load Balancer.

warning

Databricks control plane and SCC relay connections use TLS with certificate pinning. Do not enable TLS inspection (decrypt and re-encrypt) on traffic between your clusters and the Databricks control plane. Doing so causes cluster failures. See IP addresses and domains for Databricks services and assets for required endpoints.

Classic compute baseline

The classic compute baseline is inherited from Managed security. No additional classic compute components are required for this architecture.

The baseline includes customer-managed VPC, Secure Cluster Connectivity (SCC), and classic PrivateLink.

note

This architecture doesn't use inbound PrivateLink. Users access the workspace over the public internet, controlled by CBI policies. If your organization requires private workspace access, see the Isolated environment architecture, which adds inbound PrivateLink or VPN-gated access.

VPC endpoints

Configure routing for cloud service access to keep traffic private and reduce costs. S3 gateway VPC endpoints provide same-region storage access without traversing the public internet.

Create VPC endpoints for S3 (gateway), STS, and Kinesis. See Step 5: Add VPC endpoints for other AWS services.

VPC endpoint policies

Restrict which S3 buckets your VPC endpoints can access. Without a policy, the S3 gateway endpoint permits connections to any S3 bucket in any AWS account, including external or attacker-controlled buckets. A VPC endpoint policy limits the endpoint to only your approved buckets, blocking a key S3 data exfiltration path.

See Configure a customer-managed VPC for working policy examples and the required Databricks bucket access.

S3 bucket policies

Apply bucket policies to restrict access to your Databricks S3 buckets by source VPC or VPC endpoint. This prevents access to your data from outside your approved network paths, even if credentials are compromised.

See Configure a customer-managed VPC for requirements, working policy examples, and guidance on pairing bucket policies with VPC endpoint policies.

Implementation

Start from a deployed Managed security baseline. The following phases add the ingress and egress controls that define this architecture.

Phase 1: Inbound access control

1. Configure account-level context-based ingress (CBI) policies to restrict workspace access by network source, identity, authentication mechanism, and access scope. See Context-based ingress control and Manage context-based ingress policies.
2. Optionally, configure workspace-level IP access lists alongside CBI for backwards compatibility or per-workspace overrides. When both are configured, a request must be allowed by both. See Configure IP access lists for workspaces.
3. Configure account-level IP access lists to control access to the account console. See Configure IP access lists for the account console.
4. If you use Delta Sharing open sharing, configure recipient-level IP access lists on each share recipient. See Restrict Delta Sharing recipient access using IP access lists (open sharing).
5. Document each configured IP range with owner, purpose, and review/expiration date in your change management or documentation system.
6. Test access from both allowed and blocked IP addresses (for example, office, VPN, and home networks) to verify that the ingress policies behave as expected.

Phase 2: Cloud service endpoints

1. Create a gateway VPC endpoint for S3 and interface VPC endpoints for STS and Kinesis so cluster traffic to these services stays on the AWS network. See Step 5: Add VPC endpoints for other AWS services.
2. Apply VPC endpoint policies to restrict which S3 buckets the gateway endpoint can reach. See Configure a customer-managed VPC.
3. Apply S3 bucket policies to restrict access to your Databricks S3 buckets by source VPC or VPC endpoint.

Phase 3: Serverless egress controls

1. Configure serverless network policies to restrict serverless compute outbound traffic to approved destinations using IP ranges or FQDNs. See What is serverless egress control?.
2. Configure NCC private endpoints for private connectivity from serverless compute to your S3 buckets and resources in your VPC. See Configure private connectivity to AWS-managed resources and Configure private connectivity to resources in your VPC.
3. Test that serverless workloads can reach approved destinations and are blocked from unapproved ones.

Phase 4 (optional): External firewall for classic compute

1. Deploy AWS Network Firewall or a third-party appliance and integrate it with your workspace VPC.
2. Configure route tables to send 0.0.0.0/0 to the firewall while keeping VPC endpoint and PrivateLink traffic on direct routes.
3. Configure firewall rules to allow required Databricks endpoints (see IP addresses and domains for Databricks services and assets) without TLS interception on control plane and SCC relay traffic.

The Databricks Terraform SRA provides Infrastructure-as-Code templates that automate this deployment.

Validation

After you deploy the architecture, run the following checks to confirm classic compute plane traffic stays private and that your IP access list restricts workspace access as configured.

Check	Expected result
Workspace accessible from allowed IPs	Yes
Workspace blocked from unauthorized IPs	Yes
Clusters launch with SCC	Yes, no public IPs
Data access through private connections	Yes
Package installation from private artifact repos	Yes

Troubleshooting

If a validation check fails or a workload behaves unexpectedly, use the following table to diagnose common issues.

Issue	Cause	Resolution
Can't access workspace	IP not in access list	Add IP to workspace list
Cluster fails to start	Routing or endpoint misconfiguration	Check route tables and private endpoint connectivity
S3/ADLS access fails	VPC endpoint or routing issue	Check endpoint configuration and security groups
Package installation fails	Private artifact repository unreachable	Check VPC endpoint configuration and DNS resolution for your artifact repository
Intermittent access issues	Dynamic IP addresses	Use VPN with static egress IP or widen IP ranges

Ongoing maintenance

• IP access list management: Review monthly, add new locations, remove obsolete ranges.
• Endpoint monitoring: Track private endpoint health and data transfer costs.
• Artifact repository management: Maintain private package mirrors and monitor availability.
• User support: Maintain process for IP access issues.

Previous and next steps

• • Managed security
  • Previous step. If IP-based access controls, VPC endpoints, and serverless egress controls are more than your workloads require. The baseline includes customer-managed VPC, SCC, and classic PrivateLink.
• • Isolated environment
  • Next step. If IP-based access control proves insufficient, regulations require private workspace access, or compliance requires data exfiltration prevention.