Skip to main content

Configure private connectivity to AWS-managed resources

Preview

This feature is in Public Preview. To join this preview, contact your Databricks account team.

note

Databricks charges for networking costs when serverless workloads connect to customer resources, and when performance-intensive services egress data cross-region back to clients. See Understand Databricks networking costs.

This page explains how to configure private connectivity from serverless compute to AWS-managed resources using the Databricks account console UI.

Private connectivity to AWS-managed resources.

Configuring private connectivity for serverless compute provides:

  • A dedicated and private connection: Ensures secure and isolated access between your serverless workspaces and the AWS resource, limiting access to authorized connections only.
  • Enhanced data exfiltration mitigation: While serverless compute with Unity Catalog provides built-in data exfiltration protection, PrivateLink adds an extra layer of network defense. Using AWS PrivateLink, your data traffic remains entirely in the AWS network, never traversing the public internet. This architecture, combined with controlled access through VPC endpoints, reduces the attack surface for data exfiltration.
note

Databricks control plane access is used for certain metadata operations, whereas the dedicated VPC endpoint configured in this procedure handles access to the AWS resource. If you also allow access to the resource from within your company's network, include your corporate VPN IPs in the resource's policy.

note

When you access an S3 bucket through this private connection, like from a notebook or query, refer to the bucket using its regional DNS, such as {your-s3-bucket}.s3.{region}.amazonaws.com. Legacy global endpoints like {your-s3-bucket}.s3.amazonaws.com are not supported.

Supported resources

Private connectivity from serverless compute supports the following AWS-managed resources:

Resource

Endpoint DNS

Bedrock

bedrock.{region}.amazonaws.com

Bedrock Agent

bedrock-agent.{region}.amazonaws.com

Bedrock Agent Runtime

bedrock-agent-runtime.{region}.amazonaws.com

Bedrock Runtime

bedrock-runtime.{region}.amazonaws.com

DynamoDB

dynamodb.{region}.amazonaws.com

EMR

elasticmapreduce.{region}.amazonaws.com

Glue

glue.{region}.amazonaws.com

Key Management Service (KMS)

kms.{region}.amazonaws.com

Lambda

lambda.{region}.amazonaws.com

RDS

rds.{region}.amazonaws.com

RDS Data API

rds-data.{region}.amazonaws.com

RDS Performance Insights

pi.{region}.amazonaws.com

Redshift

redshift.{region}.amazonaws.com

Redshift Data API

redshift-data.{region}.amazonaws.com

Redshift Serverless

redshift-serverless.{region}.amazonaws.com

S3 (same region or cross-region)

s3.{region}.amazonaws.com

Secrets Manager

secretsmanager.{region}.amazonaws.com

Security Token Service (STS)

sts.{region}.amazonaws.com

Simple Notification Service (SNS)

sns.{region}.amazonaws.com

Simple Queue Service (SQS)

sqs.{region}.amazonaws.com

note

S3 is the only resource that supports per-bucket scoping and cross-region private connectivity. For all other resources, the private endpoint applies to all traffic from workspaces attached to the NCC that targets the resource type — there is no per-instance scoping.

note

When you access your S3 bucket through this private connection (for example, from a notebook or query), refer to the bucket using its regional DNS, such as {your-s3-bucket}.s3.{region}.amazonaws.com. Legacy global endpoints like {your-s3-bucket}.s3.amazonaws.com are not supported.

Requirements

  • The workspace is on the Enterprise plan.
  • You are the account administrator of your Databricks account.
  • You have at least one functional workspace using serverless compute.
  • You have appropriate AWS IAM permissions to create and modify the AWS resource's policy and to create VPC endpoints.
  • Each Databricks account can have up to 10 NCCs per region.
  • Each region can have 30 private endpoints, distributed as needed across 1-10 NCCs.
  • Each NCC can be attached to up to 50 workspaces.
  • For S3, each NCC can have one S3 private endpoint rule per region, and each rule can include up to 100 bucket names.

Step 1: Create a network connectivity configurations (NCC) object

You can skip this step if you have an existing NCC in the same region and AWS account that you want to use.

  1. In the account console, click Security.
  2. Select the Network connectivity configurations tab.
  3. Select Add network configuration.
  4. Enter a name for the NCC.
  5. Select the region. This must match your workspace region.
  6. Click Add.

Step 2: Create an AWS interface endpoint

important

Do not enable your private endpoint until you have completed Step 3.

  1. Go to the Private endpoint rules section in your NCC.
  2. Select Add private endpoint rule.
  3. Under Resource type, select the AWS resource you want to connect to (for example, S3 bucket, Bedrock, or RDS). For the full list, see Supported resources.
  4. Configure the rule settings:
    • Endpoint Service: This field is automatically populated to establish the connection to your private endpoint's destination resource.
    • S3 bucket names (S3 only): Enter the bucket names for your destination resources. For all other resource types, no bucket or resource name field appears — the private endpoint applies to all traffic to the selected resource type.
    • Region (S3 only): Optionally specify the region of the destination S3 buckets. If you don't specify a region, the NCC's region is used. This enables cross-region S3 private connectivity.

Step 3: Update the resource policy to accept traffic from the VPC endpoint

To allow serverless compute to access the AWS resource through the private endpoint, you might have to update the resource's policy in your AWS account to allow traffic from the VPC endpoint returned in Step 2. The policy mechanism depends on the resource type — for example, S3 uses bucket policies, KMS uses key policies, and Secrets Manager uses secret resource policies. Refer to the AWS documentation for your resource.

The following example shows an Allow clause for an S3 bucket policy:

JSON
{
"Sid": "AllowVpcEndpointAccess",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::{bucket-name}", "arn:aws:s3:::{bucket-name}/*"],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-12345" // This is the VPC endpoint returned in Step 2
}
}
}

If your policy is configured with a Deny clause instead, you might need to add an exception condition for the VPC endpoint ID returned in Step 2. An example condition is as shown:

JSON
  {
...
"Effect": "Deny",
...
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-12345"
}
}
}
note

This example policy does not include other public or private endpoints that you might want to allowlist, like corporate VPN IPs. Databricks control plane access uses separate gateway VPC endpoints for metadata operations — the dedicated VPC endpoint you configured handles access to the destination resource only.

Refresh the UI or make an API call to confirm the rule's status changes to ESTABLISHED.

Step 4: Enable private endpoint rule

  1. Click the kebab menu button.
  2. Click Update rule.
  3. Select Enable rule.
important

This step routes traffic for the configured AWS resource through PrivateLink for any workspace attached to the NCC. Before proceeding, verify you have completed Step 3 to allow resource access from the VPC endpoint.

Step 5: Attach the NCC to one or more workspaces

This step associates your configured private connectivity with your serverless workspaces. Skip this step if your workspace is already attached to the desired NCC. To attach the NCC to a workspace:

  1. Go to Workspaces in the left-hand navigation.
  2. Select an existing workspace.
  3. Select Update Workspace.
  4. Under Network connectivity configurations, select the drop-down menu and select the NCC you've created.
  5. Repeat for all workspaces you'd like this NCC to apply to.

Step 6: Verify connectivity

The way you verify connectivity depends on the resource type. For resources other than S3, simulate traffic from a notebook by making a call to the resource through the appropriate AWS SDK (for example, a Bedrock model invocation or a Lambda function call), then check the resource's access logs to confirm that the request arrives through the VPC endpoint.

The following example tests connectivity to an S3 bucket by registering it as an external location and running a query:

  1. Register your bucket as an external location. See external locations.
  2. Open the SQL editor.
  3. Run:
SQL
CREATE TABLE {catalog}.{schema}.test_connectivity LOCATION 's3://{your-s3-bucket}/test_connectivity'

It can take ten minutes for the connection to fully establish.

note

If your network policy restricts external access, direct connections to your AWS S3 bucket's FQDNs like {your-s3-bucket}.s3.{region}.amazonaws.com are blocked. You must explicitly add the required FQDNs to your network policy's Allowed domains to allow this access. See Manage network policies for serverless egress control.

Access to your S3 buckets must use regional endpoints like {your-s3-bucket}.s3.{region}.amazonaws.com. Legacy endpoints like {your-s3-bucket}.s3.amazonaws.com are not supported.

Next steps

  • Configure private connectivity to AWS resources in your VPC: Use PrivateLink to establish secure and isolated access to AWS services in your VPC from your serverless workspaces, bypassing the public internet. See Configure private connectivity to resources in your VPC.
  • Configure a firewall for serverless compute access: Configure your data source firewalls to permit traffic from the Databricks serverless compute plane. See Serverless compute firewall configuration.
  • Understand data transfer and connectivity costs: Data transfer and connectivity refer to moving data into and out of serverless environments. Networking charges for serverless products only apply to customers using serverless compute. See Understand Databricks networking costs.