Simpler, Safer URLs: Introducing Per-Account Hostnames for Snowflake App Services
In modern enterprise cloud architecture, the network boundary is no longer just a firewall—it is the fundamental unit of trust. As data platforms evolve to host diverse workloads, the traditional model of shared-everything infrastructure is giving way to granular, policy-driven isolation. For security-conscious organizations, true isolation requires clear, programmable boundaries that map directly to internal trust zones rather than generic network segments.
When application services like Streamlit in Snowflake or Snowpark Container Services run on shared infrastructure, the "noisy neighbor" or "overlapping namespace" problem can become a significant roadblock to adoption. By introducing better isolation boundaries, we are fundamentally changing how Snowflake handles application networking. Today, we're simplifying the complex by giving every account its own network identity—replacing broad wildcards with scoped, per-account hostnames that reflect the modern enterprise's need for strict, reliable segmentation.
Snowflake-hosted app services like Streamlit, Snowflake Notebooks and Snowpark Container Services run third-party and customer-authored code on Snowflake infrastructure. Unlike SQL queries, which operate within Snowflake's core engine, these services expose publicly reachable endpoints where external users and applications connect directly. Different app services within a single account need unique-per-application hostnames to get security benefits from the same-origin policy or to give full control of the URL path to the application. That makes hostname scoping a security-critical concern: the URL format determines whose traffic can reach whose code.
Until now, these hostnames were either direct subdomains of a single global domain or scoped to a region, not an individual account. That meant broad firewall wildcards, overlapping DNS namespaces for multi-account organizations, and limited ability to restrict traffic to a single account. For services running third-party code, this created an uncomfortable gap between the network controls customers expected and what the URL architecture could enforce.
Per-account URLs close that gap by giving every Snowflake account a unique hostname pattern for all app services. Whether you access them over the public internet or through PrivateLink, the same account-scoped format applies:
<app-id>.<orgname>-<accountname>.<region>.<cloud>.snowflake.appWildcard SANs in TLS certificates only cover the value on the leftmost DNS label, so our certificate infrastructure has been enhanced to provide per-account certificates to cover this naming scheme.
This single change delivers benefits across the board:
- Simplified firewall rules: A single wildcard entry scoped to your account replaces broad wildcards like
*.snowflakecomputing.app. After enabling, the account-specific wildcard appears inSYSTEM$ALLOWLISTasAPP_SERVICE_PUBLIC_WILDCARD, making firewall configuration straightforward. - Reduced data exfiltration risk: Because the wildcard is account-scoped, users are prevented from reaching app services hosted by other Snowflake accounts through your network allowlist — the account-scoped wildcard enforces this at the DNS layer. This is especially important when those services are running third-party or user-authored code that may interact with external systems.
- Consistent URL format: Streamlit, Notebooks and Snowpark Container Services all share the same hostname pattern, making DNS and certificate management simpler.
Per-account PrivateLink URLs
For organizations using PrivateLink, the benefits of per-account URLs are especially significant. The previous region-scoped model required a wildcard CNAME like *.abc123.privatelink.snowflake.app, which offered a single CNAME that was not account specific. This added two issues — operational friction where every new service required a new DNS entry and a customer using the same private DNS for all their PrivateLink account CNAMEs would have routing conflicts
Per-account PrivateLink URLs eliminate both issues:
<app-id>.<orgname>-<accountname>.<region>.<cloud>.privatelink.snowflake.app| Before (region-scoped) | After (per-account) | |
|---|---|---|
| PrivateLink wildcard | *.abc123.privatelink.snowflake.app |
*.orgname-accountname.us-east-2.aws.privatelink.snowflake.app |
| Resolves traffic for | Your account and other accounts within that region | Only your account |
| New service launched | New DNS entry needed | Works automatically |
| Multi-account DNS | Overlapping namespaces | Clean per-account separation |
One CNAME for all services: You configure a single wildcard CNAME per account that covers Streamlit, Notebooks and Snowpark Container Services. New services involving user-generated content are covered automatically. DNS configuration is no longer a blocker to adopting new Snowflake services privately.
Closed exfiltration vector: PrivateLink DNS resolution is explicitly bound to a single Snowflake account, closing the cross-account resolution gap entirely. This aligns with least-privilege principles.
Clean multi-account DNS: Each Snowflake account gets a dedicated, unique DNS namespace. No more conflicts between production, staging and development accounts sharing a DNS zone.
Multi-account DNS routing: If your private DNS zone is shared across multiple Snowflake accounts, per-account wildcards let you route traffic to the correct account without conflicting CNAME records.
After enabling, the account-scoped wildcard appears in SYSTEM$ALLOWLIST_PRIVATELINK as APP_SERVICE_PRIVATELINK_WILDCARD, and SYSTEM$GET_PRIVATELINK_CONFIG returns the new hostname in the app-service-privatelink-url key.
Getting started
Step 1: Issue the per-account certificate
SELECT SYSTEM$ISSUE_PER_ACCOUNT_APP_SERVICE_CERTIFICATE();This provisions a TLS certificate scoped to your account. Certificate issuance is asynchronous. Wait at least 30 minutes before proceeding to Step 2.
Step 2a: Enable per-account public URLs
ALTER ACCOUNT SET ENABLE_PER_ACCOUNT_APP_SERVICE_URL = TRUE;After enabling, use the APP_SERVICE_PUBLIC_WILDCARD entry from SYSTEM$ALLOWLIST to update your firewall allowlist.
Step 2b: Enable per-account PrivateLink URLs
First, retrieve the new DNS target for your account:
SELECT SYSTEM$GET_PRIVATELINK_CONFIG();Look for the app-service-privatelink-url-next key in the output. Create a wildcard CNAME in your private DNS zone pointing to this value, then update your firewall rules. Once DNS is in place:
ALTER ACCOUNT SET ENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URL = TRUE;Availability
| Dimension | Status |
|---|---|
| Services | Streamlit in Snowflake, Snowflake Notebooks, Snowpark Container Services |
| Cloud | All Snowflake regions other than US Gov West 1 (DoW) and China (Ningxia) |
| Status | Generally Available |
Simpler, Safer URLs: Introducing Per-Account Hostnames for Snowflake App Services
What's New in Apache Polaris™ 1.6
Beyond RAG: Enterprise Search Meets Analytics Over Unstructured Data
