<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Serverless egress - public internet access issues in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163192#M55109</link>
    <description>&lt;P&gt;Hey, thanks for confirming that and for the extra detail!&lt;/P&gt;&lt;P&gt;You're right — official support tickets with SLA require an active Databricks support contract, which typically isn't available for personal/free-tier usage (Free Trial credits or Free Edition). For projects like this, the best path is sticking with the Community here, or the Databricks Community Slack — plenty of product folks hang around there too.&lt;/P&gt;&lt;P&gt;That said, since you're already seeing&amp;nbsp;&lt;SPAN class=""&gt;DROP&lt;/SPAN&gt;&amp;nbsp;entries in&amp;nbsp;&lt;SPAN class=""&gt;system.access.outbound_network&lt;/SPAN&gt;, you can actually self-diagnose without needing a ticket. Try drilling into the exact blocked destination and reason:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;SELECT destination_type, destination, dns_event, storage_event.rejection_reason, event_time&lt;BR /&gt;FROM system.access.outbound_network&lt;BR /&gt;WHERE access_type = 'DROP'&lt;BR /&gt;ORDER BY event_time DESC&lt;BR /&gt;LIMIT 20;&lt;/PRE&gt;&lt;P&gt;This usually shows whether the policy is missing a rule for that specific domain/IP/storage path — which is a much more common cause than the policy simply not being attached. If the destination looks like it should be allowed and still shows DROP, that's worth flagging as a bug report on the Community rather than a support ticket, since it'd help others too.&lt;/P&gt;</description>
    <pubDate>Thu, 16 Jul 2026 14:01:05 GMT</pubDate>
    <dc:creator>GabFernandes</dc:creator>
    <dc:date>2026-07-16T14:01:05Z</dc:date>
    <item>
      <title>Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163165#M55104</link>
      <description>&lt;P&gt;I've just setup a new Databricks account on AWS with a workspace with "Serverless compute and default storage"&amp;nbsp;and I am unable to access the public internet from notebooks and jobs for all but a handful of domains.&lt;BR /&gt;&lt;BR /&gt;A subset works fine, I've identified it can connect to pypi.org, github.com, docker.com, databricks.com&lt;/P&gt;&lt;LI-CODE lang="python"&gt;response = requests.get("https://www.databricks.com/robots.txt")
display({"status_code": response.status_code, "ok": response.ok})

Returns...
{'status_code': 200, 'ok': True}&lt;/LI-CODE&gt;&lt;P&gt;But others fail...&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;response = requests.get("https://www.google.com/robots.txt")
display({"status_code": response.status_code, "ok": response.ok})

Responds...
(": Failed to resolve 'www.google.com' ([Errno -3] Temporary failure in name resolution)"))&lt;/LI-CODE&gt;&lt;P&gt;&lt;BR /&gt;What I've verified so far...&lt;/P&gt;&lt;P&gt;Network policy: Serverless egress control is on the default policy, set to Full access (unrestricted outbound).&lt;BR /&gt;NCC: No Network Connectivity Configuration is attached to the workspace.&lt;BR /&gt;There are no entries in the&amp;nbsp;system.access.outbound_network table.&lt;BR /&gt;&lt;BR /&gt;Bypassing DNS entirely does not help, connecting directly to a resolved IP address fails with "Network is unreachable" so this isn't a resolver problem, I think it's a routing/egress problem at the network layer.&lt;BR /&gt;&lt;BR /&gt;I have tried defining a custom Network policy in the account testing both&amp;nbsp;&lt;SPAN&gt;Serverless egress control&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;with "Allow access to all destinations" and "Restricted access to specific destinations" with a subset of domains but that has not had any impact (I have been terminating and restarting the serverless compute between each change and executing the notebook).&lt;BR /&gt;&lt;BR /&gt;I have also tried setting up new workspaces in different AWS regions but the same problem persists.&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;My understanding of Serverless compute is that it is running within a Databricks managed network environment and not my AWS account is that correct? i.e. it's not running within a VPC where I have control over ingress/egress&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Any help or suggestions appreciated.&lt;/P&gt;</description>
      <pubDate>Thu, 16 Jul 2026 09:17:04 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163165#M55104</guid>
      <dc:creator>MPD2</dc:creator>
      <dc:date>2026-07-16T09:17:04Z</dc:date>
    </item>
    <item>
      <title>Re: Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163188#M55106</link>
      <description>&lt;P&gt;Great debugging so far! A few things to check:&lt;/P&gt;&lt;P&gt;Yes, serverless runs in Databricks-managed infrastructure, not your AWS account or VPC — so you have no direct control over the underlying network routing. This is by design.&lt;/P&gt;&lt;P&gt;The domains that work for you (pypi.org, github.com, docker.com, databricks.com) are Databricks system-level allowlisted domains that are hardcoded at the infrastructure layer for platform operations (package installs, runtime setup, etc.) — regardless of your network policy settings. The fact that&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;EM&gt;only&lt;/EM&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;those work is actually the fingerprint of a restricted policy being in effect, not "Full access."&lt;/P&gt;&lt;P&gt;The most likely culprit:&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;your custom network policy was created at the account level but never attached to the workspace&lt;STRONG&gt;.&lt;/STRONG&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;Creating it doesn't auto-apply it. You need to explicitly associate the policy with the workspace in the account console (Account Console → Workspaces → select your workspace → Network Policy). Check this for both the "Full access" and the custom policies you tried.&lt;/P&gt;&lt;P&gt;One more gotcha from the docs: changing the internet access mode requires an explicit compute restart — just terminating the serverless cluster between changes should be enough, but confirm the policy attachment is showing on the workspace detail before restarting.&lt;/P&gt;&lt;P&gt;If the policy IS attached and you're still blocked, this is worth opening a support ticket — new AWS accounts with the simplified "Serverless compute and default storage" setup occasionally have account-level provisioning issues that support needs to fix on the backend.&lt;/P&gt;&lt;P&gt;As an immediate workaround, Classic compute running inside your own AWS VPC will give you full egress control.&lt;/P&gt;</description>
      <pubDate>Thu, 16 Jul 2026 12:42:17 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163188#M55106</guid>
      <dc:creator>GabFernandes</dc:creator>
      <dc:date>2026-07-16T12:42:17Z</dc:date>
    </item>
    <item>
      <title>Re: Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163191#M55108</link>
      <description>&lt;P&gt;Thanks for the suggestions&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/238151"&gt;@GabFernandes&lt;/a&gt;&amp;nbsp;&lt;BR /&gt;I double checked that I had explicitly attached the policy to my workspace.&lt;/P&gt;&lt;P&gt;One amendment to my original post, I am seeing entries in the &lt;SPAN&gt;system.access.outbound_network table with lots of entries with&amp;nbsp;access_type DROP.&lt;/SPAN&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Am I correct in thinking I can only open a support ticket if I have a support contract with Databricks? This is only for a personal project so I don't.&lt;/P&gt;</description>
      <pubDate>Thu, 16 Jul 2026 13:49:03 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163191#M55108</guid>
      <dc:creator>MPD2</dc:creator>
      <dc:date>2026-07-16T13:49:03Z</dc:date>
    </item>
    <item>
      <title>Re: Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163192#M55109</link>
      <description>&lt;P&gt;Hey, thanks for confirming that and for the extra detail!&lt;/P&gt;&lt;P&gt;You're right — official support tickets with SLA require an active Databricks support contract, which typically isn't available for personal/free-tier usage (Free Trial credits or Free Edition). For projects like this, the best path is sticking with the Community here, or the Databricks Community Slack — plenty of product folks hang around there too.&lt;/P&gt;&lt;P&gt;That said, since you're already seeing&amp;nbsp;&lt;SPAN class=""&gt;DROP&lt;/SPAN&gt;&amp;nbsp;entries in&amp;nbsp;&lt;SPAN class=""&gt;system.access.outbound_network&lt;/SPAN&gt;, you can actually self-diagnose without needing a ticket. Try drilling into the exact blocked destination and reason:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;SELECT destination_type, destination, dns_event, storage_event.rejection_reason, event_time&lt;BR /&gt;FROM system.access.outbound_network&lt;BR /&gt;WHERE access_type = 'DROP'&lt;BR /&gt;ORDER BY event_time DESC&lt;BR /&gt;LIMIT 20;&lt;/PRE&gt;&lt;P&gt;This usually shows whether the policy is missing a rule for that specific domain/IP/storage path — which is a much more common cause than the policy simply not being attached. If the destination looks like it should be allowed and still shows DROP, that's worth flagging as a bug report on the Community rather than a support ticket, since it'd help others too.&lt;/P&gt;</description>
      <pubDate>Thu, 16 Jul 2026 14:01:05 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163192#M55109</guid>
      <dc:creator>GabFernandes</dc:creator>
      <dc:date>2026-07-16T14:01:05Z</dc:date>
    </item>
    <item>
      <title>Re: Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163197#M55110</link>
      <description>&lt;P&gt;They're all showing this...&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;DNS	www.google.com	{"domain_name":"www.google.com","rcode":5,"rdata":[]}	null	2026-07-16T13:22:02.000+00:00&lt;/LI-CODE&gt;&lt;P&gt;The rejection reasons are all `null`. The policy I am using has egress configured as "&lt;SPAN&gt;Allow access to all destinations" so I would not be expecting &lt;A href="http://www.google.com" target="_blank"&gt;www.google.com&lt;/A&gt;&amp;nbsp;to be dropped. I'm assuming this indicates it is probably a bug.&lt;BR /&gt;&lt;BR /&gt;You mentioned...&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;new AWS accounts with the simplified "Serverless compute and default storage" setup occasionally have account-level provisioning issues that support needs to fix on the backend.&lt;/LI-CODE&gt;&lt;P&gt;&lt;SPAN&gt;I'm guessing without a support contract I'm a bit stuck with this if it is a bug&amp;nbsp;&lt;span class="lia-unicode-emoji" title=":grinning_face_with_sweat:"&gt;😅&lt;/span&gt;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 16 Jul 2026 14:49:30 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163197#M55110</guid>
      <dc:creator>MPD2</dc:creator>
      <dc:date>2026-07-16T14:49:30Z</dc:date>
    </item>
    <item>
      <title>Re: Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163338#M55127</link>
      <description>&lt;P&gt;Hi there, from your note and comments, I couldn't gather if you have tried standard compute. Did you experience the same issues with standard compute? With serverless, you might experience some snags since the infrastructure is owned by Databricks and you will need to work their infra team to unpack some of the roadblocks.&lt;/P&gt;</description>
      <pubDate>Sat, 18 Jul 2026 19:53:43 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163338#M55127</guid>
      <dc:creator>binlogreader</dc:creator>
      <dc:date>2026-07-18T19:53:43Z</dc:date>
    </item>
    <item>
      <title>Re: Serverless egress - public internet access issues</title>
      <link>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163342#M55129</link>
      <description>&lt;P&gt;I hadn't tried standard compute at the time, I have now and internet access works for all domains from the EC2 instances. So I'm using a mix of Serverless for workloads where I don't need to access the internet and standard for the places I do.&lt;/P&gt;</description>
      <pubDate>Sat, 18 Jul 2026 22:03:46 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/serverless-egress-public-internet-access-issues/m-p/163342#M55129</guid>
      <dc:creator>MPD2</dc:creator>
      <dc:date>2026-07-18T22:03:46Z</dc:date>
    </item>
  </channel>
</rss>

