アカウント識別子¶
アカウント識別子は、 組織 内だけでなく、Snowflakeがサポートする クラウドプラットフォーム と クラウドリージョン のネットワーク全体で、Snowflakeアカウントを一意に識別します。
優先アカウント識別子には、アカウントの 名前 とその組織（例: myorg-account123）が含まれます。Snowflakeが割り当てた ロケーター をアカウント識別子として使用することもできますが、このレガシ形式の使用は推奨されません。
このトピックの内容:
アカウント識別子が使用される場所¶
Snowflakeでは、使用しているアカウントを指定する必要がある場合は常に、次のような場合を含め、アカウント識別子が必要です。
Snowflake ウェブインターフェイスのいずれかにアクセスするための URLs。
Snowflakeに接続するための SnowSQL とその他のクライアント（コネクタ、ドライバーなど）。
Snowflakeエコシステムを構成するサードパーティのアプリケーションとサービス。
Snowflakeの内部操作と、外部システムとの通信/相互作用を保護するためのセキュリティ機能。
Secure Data Sharing、複製、フェールオーバー/フェールバックなどのグローバル機能。
たとえば、アカウントの URL は次の形式を使用します。
account_identifier.snowflakecomputing.com
組織で クライアントリダイレクト 機能を使用している場合は、アカウント識別子のアカウント名の代わりに 接続オブジェクトの名前 を使用し、SnowflakeアカウントにSnowflakeクライアントを使用して接続できます。詳細については、 接続 URL の使用 をご参照ください。
アカウント識別子と接続を使用してSnowflakeアカウントに接続する方法の詳細については、 アカウントへの接続 をご参照ください。
形式1（推奨）: 組織内のアカウント名。¶
組織 は、ビジネスエンティティが所有するアカウントをリンクするSnowflakeオブジェクトです。組織により、組織管理者（つまり、 ORGADMIN ロールを持つユーザー）は、さまざまなクラウドプラットフォームやリージョンで、すべてのアカウントを表示、作成、および管理できるようになります。
アカウント名は組織内で一意にする必要があり、変更できます。これにより、柔軟性が高まり、アカウント名が短く直感的になります。新しいアカウントを作成するときにアカウント名を指定します（アカウントの作成 を参照）。既存のアカウントの名前を変更するには、 アカウントの名前変更 をご参照ください。
アカウント名は組織内のアカウントを一意に識別しますが、Snowflake組織全体のアカウントの一意な識別子 ではありません。
アンダースコア付きのアカウント名には、Okta SSO/SCIM など、アンダースコア付きの URLs を受け入れない機能のために URL のダッシュ記号を使ったバージョンもあります。
アカウント名を識別子として使用する¶
組織内のアカウントのアカウント識別子は、識別子の使用場所と使用方法に応じて、次の形式のいずれかになります。
orgname-account_name（大半の URLs および他の一般的な用途の場合）orgname-account-name（アカウント名のアンダースコアがサポートされていないシナリオ/機能の場合）orgname.account_name（SQL コマンドおよび操作の場合）
条件:
orgnameは、Snowflake組織の名前です。account_nameは、組織内にあるアカウントの一意の名前です。
アカウントの組織名とアカウント名の検索¶
アカウントのアカウント名を検索するには、 Snowsight または SQL を使用します。
- Snowsight
アカウントセレクターを開き、以前にサインインしたアカウントのリストを確認します。
コピーするアカウント名を持つアカウントを探します。
アカウントにカーソルを合わせると詳細が表示され、コピーアイコンを選択すると、形式
<orgname>.<account_name>のアカウント識別子がクリップボードにコピーされます。
- SQL
現在のアカウント名を取得するには、 CURRENT_ACCOUNT_NAME 関数を実行します。
現在のアカウントの組織を検索するには、 CURRENT_ORGANIZATION_NAME 関数を実行します。
組織およびアカウント名¶
組織名¶
セルフサービスオプションを使用してSnowflakeアカウントにサインアップするユーザーの場合は、アカウントの作成時にシステムで生成された名前で組織が自動的に作成されます。Snowflakeの担当者と直接連携してアカウントを設定するエンティティの場合、Snowflakeは、組織にカスタム名を割り当てることができます。カスタム名は、Snowflakeの他のすべての組織で一意にする必要があります。名前は文字で始める必要があり、文字（小文字と大文字）と数字のみを含めることができます。名前にはアンダースコアやその他の区切り文字を含めることはできません。
システムで生成された名前をよりユーザーフレンドリーな名前に変更するなど、組織の名前を変更する場合は、 Snowflakeサポート にお問い合わせください。
ベストプラクティスとして、アカウント識別子で名前を使用する前に、必要に応じて組織名を確認および変更してください。将来、組織の名前を変更すると、Snowflakeアカウントのすべての URLs が新しい名前と一致するように変更されます。
組織の名前を表示するには、 組織およびそのアカウントの名前の表示 をご参照ください。
アカウント名¶
各アカウント名は、組織内で一意にする必要があります。アカウントを作成するときにアカウント名を指定します（アカウントの作成 を参照）。
アカウント名は組織内のアカウントを一意に識別しますが、Snowflake組織全体のアカウントの一意な識別子 ではありません。Snowflakeでアカウントを一意に識別するには、アカウント名の先頭に組織名を追加する必要があります。例:
orgname-account_name
識別子の SQL 標準と一致して、アカウント名には単語間の区切り文字としてアンダースコアを含めることができます（例: MARKETING_TEST_ACCOUNT）。
URLs にアンダースコアを使用すると、Okta SSO/SCIM などの特定の機能で問題が発生する可能性があります。このため、Snowflakeは、アンダースコア文字の代わりにハイフン文字（-）を使用するバージョンのアカウント名もサポートしています。たとえば、次の URLs の両方がサポートされています。
アンダースコア付きの URL:
https://acme-marketing_test_account.snowflakecomputing.comダッシュ付きの URL:
https://acme-marketing-test-account.snowflakecomputing.com
既存のアカウント¶
組織機能が有効になる前に存在していたアカウントがある場合は、アカウント名として 形式2（レガシー）: リージョン内のアカウントロケーター。 が使用されます。
加えて、異なるリージョンに同じ名前の既存アカウントがある場合は、クラウド名とリージョン名が新しい URL 形式でアカウント名の前に追加されます。
たとえば、組織名が ACME で、 TEST という名前のアカウントが2つあり、1つは AWS us-east-2 リージョンに、もう1つはAzure west-us-2 リージョンにある場合、新しい URLs は次の構造になります。
最初のアカウント:
- オリジナル URL
https://test.us-east-2.aws.snowflakecomputing.com- 新しい URL
https://acme-test_aws_us_east_2.snowflakecomputing.com
2番目のアカウント:
- オリジナル URL
https://test.west-us-2.azure.snowflakecomputing.com- 新しい URL
https://acme-test_azure_west_us_2.snowflakecomputing.com
これらのアカウント名は、新しい名前が一意である限り変更できます。アカウント名を変更する方法については、 アカウントの名前変更 をご参照ください。
形式2（レガシー）: リージョン内のアカウントロケーター。¶
アカウントロケーターは、アカウントの作成時にSnowflakeによって割り当てられる識別子です。
アカウントがSnowflakeの担当者によって作成されている場合は、会社名、頭字語、その他の認識可能な文字列など、ロケーターの特定の値をリクエストできる可能性があります。
アカウントがセルフサービスまたは自動化/バックグラウンドプロセスによって作成された場合、ロケーターは一意の文字と数字のランダムな文字列です（例:
xy12345）。
アカウントが作成されると、アカウントのロケーターは変更できません。
注釈
アカウントロケーターは、Snowflakeでアカウントを識別するために引き続きサポートされていますが、これは推奨される方法ではなくなりました。アカウントを識別するための推奨される方法は、組織内のアカウント名です（このトピック内で前述のとおり）。
アカウントロケーターを識別子として使用する¶
各Snowflakeアカウントは、地理的な リージョン の クラウドプラットフォーム でホストされています。
リージョンは、アカウントのデータが保存される場所と、アカウントで使用されるコンピューティングリソースがプロビジョニングされる場所を決定します。
アカウントロケーターを使用してアカウントを識別する場合、ロケーターだけではアカウントを識別するのに必ずしも十分ではありません。アカウントのリージョンとクラウドプラットフォームによっては、次の形式で 追加の セグメントが必要になる場合があります。
account_locator.cloud_region_id または
account_locator.cloud_region_id.cloud
条件:
cloud_region_idは、クラウドリージョンの識別子です（クラウドプラットフォームにより決定）。cloudは、クラウドプラットフォームの識別子です（aws、azure、またはgcp）。
たとえば、アカウントロケーターが xy12345 の場合:
アカウントが AWS US 西部（オレゴン）リージョンにある場合、追加のセグメントは必要なく、 URL は
xy12345.snowflakecomputing.comになります。アカウントが AWS US 東部（オハイオ）リージョンにある場合、追加のセグメントが必要であり、 URL は
xy12345.us-east-2.aws.snowflakecomputing.comになります。
リージョンとロケーターの形式の包括的なリストについては、 クラウドプラットフォームおよびリージョン別の非 VPS アカウントロケーター形式 （このトピック内）をご参照ください。
注釈
Snowflakeエディションが VPS の場合、アカウントロケーターは別の形式を使用します。 VPS アカウントのアカウントロケーター形式の検出 （このトピック内）をご参照ください。
アカウントのリージョンとロケーターを検索する¶
Snowflakeアカウントに接続できる場合は、次のコンテキスト関数をクエリして、接続しているSnowflakeアカウントのリージョンとアカウントロケーターを特定できます。
CURRENT_REGION は、アカウントが配置されているリージョンを取得します。
CURRENT_ACCOUNT は、アカウントロケーターを取得します。
Snowflakeに接続できない場合は、アカウントのSnowflake管理者に連絡して、この情報を取得します。
VPS アカウントのアカウントロケーター形式の検出¶
Snowflakeエディションが VPS の場合、アカウントロケーター形式は、他のSnowflakeエディションのアカウントとは異なる命名規則を使用します。このため、 VPS アカウントへのアクセスに使用されるホスト名と URLs の構造が異なります。
詳細については、 Snowflakeサポート またはSnowflakeの担当者にお問い合わせください。
別の方法として、アカウント識別子には organization_name-account_name の推奨形式を使用できます。この形式は、 VPS エディションを使用するアカウントで機能します。詳細については、 形式1（推奨）: 組織内のアカウント名。 （このトピック内）をご参照ください。
クラウドプラットフォームおよびリージョン別の VPS 以外のアカウントロケーター形式¶
次のテーブルは、特定のリージョンのアカウントロケーターに追加のセグメントが必要かどうかなど、サポートされている VPS 以外のリージョンすべてのアカウントロケーター形式をリストしています。
アカウントロケーターが xy12345 の場合:
クラウドプラットフォーム/リージョン |
アカウント識別子 |
メモ |
|---|---|---|
Amazon Web Services（AWS） |
||
US 西部（オレゴン）
|
|
追加のセグメントは必要ありません。 |
US 政府西部1
|
|
|
US 政府西部1（FedRAMP High Plus）
|
|
|
US 東部（オハイオ）
|
|
|
US 東部（バージニア北部）
|
|
必要な追加のセグメントはクラウドリージョン ID のみです。 |
US 東部（商業組織、バージニア政府北部）
|
|
|
カナダ（中部）
|
|
|
南米（サンパウロ）
|
|
|
EU （アイルランド）
|
|
必要な追加のセグメントはクラウドリージョン ID のみです。 |
ヨーロッパ（ロンドン）
|
|
|
EU （パリ）
|
|
|
EU （フランクフルト）
|
|
必要な追加のセグメントはクラウドリージョン ID のみです。 |
EU （ストックホルム）
|
|
|
アジア太平洋（東京）
|
|
|
アジア太平洋（大阪）
|
|
|
アジア太平洋（ソウル）
|
|
|
アジア太平洋（ムンバイ）
|
|
|
アジア太平洋（シンガポール）
|
|
必要な追加のセグメントはクラウドリージョン ID のみです。 |
アジア太平洋（シドニー）
|
|
必要な追加のセグメントはクラウドリージョン ID のみです。 |
アジア太平洋（ジャカルタ）
|
|
|
Google Cloud Platform（GCP） |
||
US 中央部1（アイオワ）
|
|
|
US 東部4（北部バージニア）
|
|
|
ヨーロッパ西部2（ロンドン）
|
|
|
ヨーロッパ西部4（オランダ）
|
|
|
Microsoft Azure |
Azureアカウントロケーターは、 AWS および GCP との整合性を保つためにハイフンを使用して実装されました。 |
|
西 US 2（ワシントン）
|
|
|
中部 US （アイオワ）
|
|
|
南中央 US （テキサス）
|
|
|
東 US 2（バージニア）
|
|
|
US 政府バージニア
|
|
|
カナダ中央部（トロント）
|
|
|
UK 南部（ロンドン）
|
|
|
北ヨーロッパ（アイルランド）
|
|
|
西ヨーロッパ（オランダ）
|
|
|
スイス北部（チューリッヒ）
|
|
|
UAE 北部（ドバイ）
|
|
|
インド中部（プネー）
|
|
|
日本東部（東京）
|
|
|
東南アジア（シンガポール）
|
|
|
オーストラリア東部（ニューサウスウェールズ）
|
|
プライベート接続のアカウント識別子¶
アカウントでSnowflakeサービスへのプライベート接続が有効になっており、この機能を使用してSnowflakeに接続する場合は、 SYSTEM$GET_PRIVATELINK_CONFIG 関数を実行して、使用するプライベート接続 URL を決定します。URL のアカウント名またはアカウントロケーターのいずれかを使用して、Snowflakeウェブインターフェイスに接続できます。
プライベート接続を使用して Snowsight に接続する場合は、 Snowsightへのサインイン にある次の手順を使用します。
複製およびフェールオーバーのアカウント識別子¶
複製およびフェールオーバー関連の SQL コマンド内でアカウントを識別するために推奨される方法では、組織名とアカウント名をアカウント識別子として使用します。代わりに従来のアカウントロケーターを使用するときは、アカウントを一意に識別するために追加のセグメントを含めることが必要になる場合があります。以下のテーブルをご参照ください。
アカウント識別子
リモートアカウントの場所
organization_name.account_nameプライマリデータベースを格納するアカウントのリージョンまたはリージョングループに関係なく使用できる優先アカウント識別子。
account_locatorプライマリデータベースを格納するアカウントと同じ地域ですが、アカウントは異なります。
snowflake_region.account_locatorプライマリデータベースを保存するアカウントと同じリージョングループですが、リージョンは異なります。
region_group.snowflake_region.account_locatorプライマリデータベースを保存するアカウントと リージョングループ が異なります。
snowflake_region と region_group の値は、 SHOW REPLICATION ACCOUNTS の出力にあります。
Snowflake Region IDs およびリージョングループ¶
Snowflake Regionは、他のSnowflake Regionから分離された別個のリージョン（AWS、Azure、または GCP クラウドリージョン内に展開）です。Snowflake Regionは、マルチテナント（複数の組織のアカウントを包含）またはシングルテナント（別名、単一の組織のVirtual Private Snowflake）のいずれかになります。
各Snowflake Regionは、一意の識別子を有し、リージョングループに属しています。これにより、データの共有や複製などのグローバル機能が有効になります。
地域 IDs¶
各クラウドプラットフォームでは、リージョンの命名に異なる規則と形式を使用するため、Snowflakeは、すべてのクラウドプラットフォームとそのリージョンにわたって一意に識別する正規の ID を各Snowflake Regionに割り当てます。
組織機能が有効になっている場合は、新しいアカウントを作成するときや、複製とフェールオーバーを構成するときに、アカウント識別子の一部としてSnowflake Region ID を指定する必要があります。
次のテーブルには、Snowflake Region IDs の包括的なリストが示されています。
クラウド リージョン |
クラウド 地域 ID |
Snowflake 地域 ID |
メモ |
|---|---|---|---|
Amazon Web Services（AWS） |
|||
US 西部（オレゴン）
|
|
|
|
US 政府西部1
|
|
|
Business Critical（またはそれ以上）のアカウントでのみ利用可能です。 AWS GovCloud （US） に配置されています。 |
US 政府西部1（FedRAMP High Plus）
|
|
|
Business Critical（またはそれ以上）のアカウントでのみ利用可能です。 AWS GovCloud （US） に配置されています。 |
US 東部（オハイオ）
|
|
|
|
US 東部（バージニア北部）
|
|
|
|
US 東部（商業組織、バージニア政府北部）
|
|
|
Business Critical（またはそれ以上）のアカウントでのみ利用可能です。 AWS GovCloud （US） ではなく、 US 東部1に配置されています。 |
カナダ（中部）
|
|
|
|
南米（サンパウロ）
|
|
|
|
EU （アイルランド）
|
|
|
|
ヨーロッパ（ロンドン）
|
|
|
|
EU （パリ）
|
|
|
|
EU （フランクフルト）
|
|
|
|
EU （ストックホルム）
|
|
|
|
アジア太平洋（東京）
|
|
|
|
アジア太平洋（大阪）
|
|
|
|
アジア太平洋（ソウル）
|
|
|
|
アジア太平洋（ムンバイ）
|
|
|
|
アジア太平洋（シンガポール）
|
|
|
|
アジア太平洋（シドニー）
|
|
|
|
アジア太平洋（ジャカルタ）
|
|
|
|
Google Cloud Platform（GCP） |
|||
US 中央部1（アイオワ）
|
|
|
|
US 東部4（北部バージニア）
|
|
|
|
ヨーロッパ西部2（ロンドン）
|
|
|
|
ヨーロッパ西部4（オランダ）
|
|
|
|
Microsoft Azure |
|||
西 US 2（ワシントン）
|
|
|
|
中部 US （アイオワ）
|
|
|
|
南中央 US （テキサス）
|
|
|
|
東 US 2（バージニア）
|
|
|
|
US 政府バージニア
|
|
|
Business Critical（またはそれ以上）のアカウントでのみ利用可能です。 Microsoft Azure Government に配置されています。 |
カナダ中央部（トロント）
|
|
|
|
UK 南部（ロンドン）
|
|
|
|
北ヨーロッパ（アイルランド）
|
|
|
|
西ヨーロッパ（オランダ）
|
|
|
|
スイス北部（チューリッヒ）
|
|
|
|
UAE 北部（ドバイ）
|
|
|
|
インド中部（プネー）
|
|
|
|
日本東部（東京）
|
|
|
|
東南アジア（シンガポール）
|
|
|
|
オーストラリア東部（ニューサウスウェールズ）
|
|
|
リージョングループ¶
リージョングループは、同様のセキュリティ制御、分離、およびコンプライアンスを提供するSnowflake Regionのグループです。Snowflake Regionが属するリージョングループは、リージョンによって異なります。
すべてのSnowflakeマルチテナント商用リージョン（サポートされているすべてのクラウドプラットフォーム全体）は、同じ共有/一般
PUBLICグループにあります。各Snowflakeマルチテナント政府リージョンは、そのリージョンに固有の個別のグループにあります。
各シングルテナントのVirtual Private Snowflake（VPS）は、 VPS に固有の個別のリージョングループにあります。組織に複数の VPS がある場合は、リージョングループごとに1つの VPS を持つか、複数の VPSs で同じリージョングループを共有できます。
異なるリージョングループにアカウントを作成する場合は、アカウント識別子の一部としてリージョングループを指定する必要があります。