Snowflake Account Identifiers: Account Names, Locators, Region IDs and Region Groups

1.Two ways to name an account

Every Snowflake account needs an identifier that is unique within your organization and also across the whole global network of Snowflake clouds and regions. Snowflake supports two formats for it. Format 1 (preferred) is the account name prefixed by the organization name, such as myorg-account123. Format 2 (legacy) is the *account locator*, which Snowflake assigns, such as xy12345, sometimes followed by region and cloud segments. Locators still work, but the documentation says plainly that this legacy format is not recommended.

The identifier matters because it appears almost everywhere you point at an account: the URLs for Snowflake's web interfaces, Snowflake CLI, SnowSQL and the connectors and drivers, third-party applications in the Snowflake ecosystem, security features that protect Snowflake's internal operations and its communication with external systems, and global features such as Secure Data Sharing and Replication and Failover/Failback. A wrong identifier is a broken connection, a share that goes to the wrong account, or a replication command that fails.

The rest of this lesson builds on this split. We look at account names first, then at locators, then at which form each situation needs, and finally at the region IDs and region groups that locators and replication depend on.

Sources1

2.Account names and organization names

You choose the account name when you create the account, and you can rename the account later. That flexibility is the main advantage over the locator: names can be short and meaningful. The uniqueness rule has limits, though. A name must be unique within your organization, whatever region the account is in, but two different organizations can both have an account called sales. That is why the organization name is always prepended: orgname plus account_name is what makes the identifier unique across all of Snowflake.

To avoid DNS resolution failures, the identifier must follow these rules:

- It must be unique within the organization, regardless of region. - It must start with an alphabetic character and can't contain spaces or special characters other than underscores (_). - It shouldn't end with _. - The full string (organization name, account name and the - characters) shouldn't exceed 63 characters, and names should follow the "Letter, Digit, Hyphen" (LDH) rule from RFC 952.

Underscores and hyphens behave differently, and exam questions often turn on this. An account name can contain underscores, for example MARKETING_TEST_ACCOUNT, but it can't contain a hyphen. Some features don't accept underscores, Okta SSO and SCIM among them. For those, Snowflake automatically accepts a second form of the identifier with each underscore replaced by a hyphen. You don't rename the account to get it. https://acme-marketing_test_account.snowflakecomputing.com and https://acme-marketing-test-account.snowflakecomputing.com reach the same account. The first hyphen separates organization from account, and the others stand in for underscores.

The organization name has its own rules. Self-service sign-ups get a system-generated organization name. Snowflake can assign a custom name, unique across all organizations, to customers who work with Snowflake personnel. An organization name must start with a letter and may contain only letters and numbers, with no underscores or other delimiters. Changing it requires Snowflake Support and changes the URL of every account in the organization, so review the name before you use it in identifiers.

Accounts that existed before the Organizations feature was enabled use their locator as their account name. If such accounts share a name across regions, the cloud and region are appended. Two accounts named TEST in organization ACME get new URLs such as https://acme-test_aws_us_east_2.snowflakecomputing.com and https://acme-test_azure_west_us_2.snowflakecomputing.com, and these names can be changed as long as the new ones are unique.

Sources1

3.The legacy account locator

Snowflake assigns the account locator when the account is created. If a Snowflake representative creates the account, you may be able to request a recognizable value such as a company acronym. If the account comes from self-service or an automated process, the locator is a random string such as xy12345. Unlike the account name, a locator can't be changed once the account exists. Snowflake still accepts locators for identifying accounts, but they are no longer the preferred method.

To look up the locator of the account you're connected to, call CURRENT_ACCOUNT. Despite its name, this function returns the locator, not the account name. Use CURRENT_ACCOUNT_NAME for the name and CURRENT_REGION for the region.

SELECT CURRENT_ACCOUNT();

A locator on its own often doesn't identify an account. Depending on the region and cloud platform, you add segments in the form account_locator.cloud_region_id or account_locator.cloud_region_id.cloud, where cloud is aws, azure or gcp. SnowGov regions also add a compliance segment (fhplus or dod) straight after the locator. The pattern isn't consistent: some AWS regions need only the cloud region ID, AWS US West (Oregon) needs nothing, and every GCP and Azure region needs both segments. Azure region IDs also gain hyphens in the locator form. Azure's westus2 becomes west-us-2. VPS accounts use a different locator format altogether, and the docs suggest using orgname-account_name for them instead.

Sources12

4.Which identifier form each situation needs

Even with the preferred format, the separator and suffix depend on where the identifier goes. Anything that takes a URL or hostname, such as Snowsight sign-in or the server URL in Tableau or PowerBI, uses a hyphen plus the domain: orgname-account_name.snowflakecomputing.com. Client configuration files (Snowflake CLI, SnowSQL) and driver or library settings (ODBC, JDBC) use the bare hyphenated form orgname-account_name. Inside a SQL statement, a fully qualified account name uses a period: orgname.account_name. The *data sharing account identifier* that a provider asks for before sharing a private listing with you uses the same period form.

You don't have to assemble any of these by hand. In Snowsight, open the account selector and choose View account details. The dialog shows the Data Sharing Account Identifier, the Account/Server URL, a Config File tab, a Connectors/Drivers tab and a SQL Commands tab. In SQL, you can build the client form yourself from two context functions.

SELECT CURRENT_ORGANIZATION_NAME() || '-' ||  ? ();

[connections]
[connections.myconnection]
account = "myorganization-myaccount"

Three special cases come up often.

Okta. Okta doesn't support underscores in URLs. For SSO, SCIM or OAuth through Okta, an account name with underscores must use the hyphen form described earlier (https://<orgname>-<account-name>.snowflakecomputing.com). Connection-name and locator URLs use the standard URL.

Private connectivity. With AWS PrivateLink or a similar service, add privatelink to the account identifier in the URL, for example https://<orgname>-<account_name>.privatelink.snowflakecomputing.com. Run SYSTEM$GET_PRIVATELINK_CONFIG to find the URL to use. You can use either the account name or the locator in it, and your DNS records must be updated to include the private connectivity URL.

Client Redirect. If your organization uses Client Redirect, a connection object's name replaces the account name: https://<orgname>-<connectionname>.snowflakecomputing.com. This connection name format is required for Client Redirect. To find your connection names, run SHOW CONNECTIONS.

Sources13

5.Snowflake Region IDs and region groups

A Snowflake Region is an isolated region deployed within an AWS, Azure or GCP cloud region. It can be multi-tenant, with accounts from many organizations, or single-tenant, which is Virtual Private Snowflake (VPS). Each cloud names its regions differently, so Snowflake gives every Snowflake Region a canonical ID that is unique across all clouds. The cloud region ID us-west-2 becomes the Snowflake Region ID aws_us_west_2, and Azure's westus2 becomes azure_westus2. With Organizations enabled, you need the Snowflake Region ID when you create a new account and when you configure replication and failover.

Every Snowflake Region belongs to a region group, a set of regions with similar security controls, isolation and compliance. Region groups are what make global features such as data sharing and replication possible. There are three kinds:

- All multi-tenant commercial regions, on every cloud, are in the single PUBLIC group. - Each multi-tenant government region has its own group. - Each single-tenant VPS has its own group, although an organization with several VPSs can place more than one in the same group.

You include the region group in an account identifier only when you create accounts in different region groups. Most organizations are entirely in PUBLIC, so the group stays hidden. CURRENT_REGION() returns a plain region such as AWS_US_WEST_2, but in an organization that spans several region groups it returns region_group.region, for example PUBLIC.AWS_US_WEST_2. SHOW REGIONS [ LIKE '<pattern>' ] lists the regions where accounts can be created, with snowflake_region, cloud, region and display_name columns. It adds a region_group column only for organizations that span multiple region groups.

SELECT CURRENT_REGION();

Replication brings all of this together. In replication and failover commands, the preferred target identifier is organization_name.account_name, which works wherever the target account is. If you use the legacy locator, how many segments you need depends on how far the target is from the account that stores the primary database. SHOW REPLICATION ACCOUNTS shows the snowflake_region and region_group values to use.

Sources145

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.CURRENT_ACCOUNT() returns the account name, so it is the function to concatenate with CURRENT_ORGANIZATION_NAME().Why is that wrong?

   CURRENT_ACCOUNT() returns the legacy account locator. CURRENT_ACCOUNT_NAME() returns the account name used in orgname-account_name.

   Covered in The legacy account locator

2. 2.An account whose name has underscores must be renamed with hyphens before Okta SSO or SCIM will work.Why is that wrong?

   Account names can't contain hyphens, and no rename is needed. Snowflake automatically accepts a version of the identifier with each underscore replaced by a hyphen.

   Covered in Account names and organization names

3. 3.The hyphenated orgname-account_name form is correct everywhere, including SQL statements and data sharing account identifiers.Why is that wrong?

   Fully qualified account names in SQL and data sharing account identifiers use a period: orgname.account_name. The hyphen form is for URLs and client or driver configuration.

   Covered in Which identifier form each situation needs

4. 4.A bare account locator is enough to name any replication target.Why is that wrong?

   A bare locator only works for a target in the same region. For other regions or region groups you have to add snowflake_region and region_group segments, or use organization_name.account_name.

   Covered in Snowflake Region IDs and region groups

Practise it for real

Find your own account's identifier in each form and see how they relate.

1. 1.Run SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME();

   Why: Builds the preferred identifier that client configs and drivers use.

   You should see: A single string in the form orgname-account_name.

2. 2.Run SELECT CURRENT_ACCOUNT();

   Why: Shows that this function returns the legacy locator, not the name.

   You should see: A locator value such as XY12345, different from the account name.

3. 3.Run SELECT CURRENT_REGION();

   Why: Gives the Snowflake Region ID you would need to qualify the locator or configure replication.

   You should see: A Snowflake Region ID such as AWS_US_WEST_2, or PUBLIC.AWS_US_WEST_2 if your organization spans several region groups.

4. 4.Run SHOW REGIONS;

   Why: Lists the Snowflake Region IDs where accounts can be created, next to each cloud's own region name.

   You should see: Rows with snowflake_region, cloud, region and display_name columns, plus region_group only if your organization spans multiple region groups.