DataHub Cloud Egress IPs for Snowflake Network Policy Configuration – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: Network Policy & Firewall Allowlisting

Issue

Organizations implementing CIS benchmark hardening or other network-level security controls in Snowflake may need to configure per-user or account-level network policies that restrict inbound connections to a known set of IP addresses. When a dedicated Snowflake service account is used by DataHub Cloud for metadata ingestion, administrators need an authoritative list of egress IPs to allowlist — rather than relying solely on IPs observed in Snowflake query history or access logs, which may be incomplete or change over time.

You Might Be Asking

Does DataHub Cloud publish a static list of egress IPs used for Snowflake connector connections?
Which IP addresses should I add to my Snowflake network policy to allow DataHub Cloud to connect?
Are the egress IPs I see in my Snowflake access logs reliable enough to use in a locked-down network policy?
Can DataHub Cloud connect to Snowflake through a NAT gateway with fixed IPs?

Solution

Understand the egress IP architecture.
DataHub Cloud routes all outbound connections to Snowflake through NAT gateways with static, fixed IP addresses. These IPs are managed by the DataHub Cloud infrastructure team and do not change dynamically during normal operations, making them safe to use in a locked Snowflake network policy.
Obtain the authoritative egress IP list for your environment.
DataHub Cloud does not currently publish a universal, self-service egress IP list in public documentation because the specific IPs are tied to the regional deployment of your DataHub Cloud instance. To get the correct and supported list of NAT gateway egress IPs for your environment, contact DataHub Support and provide your DataHub Cloud instance details (e.g., <your-instance>.datahubproject.io). Support will provide the complete and authoritative set of IPs for your region.
Configure a Snowflake network policy for the DataHub service account.
Once you have the confirmed egress IP list, create or update a Snowflake network policy scoped to your DataHub service account. The following is an example Snowflake SQL pattern:
```
-- Create a network policy allowing only DataHub Cloud egress IPs
CREATE NETWORK POLICY datahub_cloud_policy
  ALLOWED_IP_LIST = (
    '<egress-ip-1>',
    '<egress-ip-2>',
    '<egress-ip-3>'
  );

-- Apply the network policy to the DataHub service account user
ALTER USER <SERVICE_DATAHUB_USER>
  SET NETWORK_POLICY = datahub_cloud_policy;
```
Replace <egress-ip-1>, <egress-ip-2>, <egress-ip-3> with the IPs provided by DataHub Support, and replace <SERVICE_DATAHUB_USER> with the name of your Snowflake service account used by DataHub.
Validate connectivity after applying the policy.
After applying the network policy, trigger a test ingestion run from your DataHub Cloud instance and verify it completes successfully. You can also query Snowflake's login history to confirm connections are being accepted from the expected IPs:
```
SELECT
    event_timestamp,
    user_name,
    client_ip,
    reported_client_type,
    is_success
FROM snowflake.account_usage.login_history
WHERE user_name = '<SERVICE_DATAHUB_USER>'
ORDER BY event_timestamp DESC
LIMIT 50;
```

Additional Notes

The egress IPs provided by DataHub Support are attached to NAT gateways and are considered stable for the lifetime of your DataHub Cloud deployment in a given region. However, in the event of major infrastructure changes (such as a regional migration), DataHub Support will communicate any IP changes in advance. It is recommended to periodically verify your allowlist remains current with your DataHub Support contact. Do not rely exclusively on IPs observed in Snowflake query or login history logs, as a log-derived list may be incomplete if not all connection paths have been exercised. Always obtain the full list from DataHub Support to ensure your network policy does not inadvertently block ingestion traffic.

Issue

You Might Be Asking

Solution

Additional Notes

Related Documentation