Zenn
❄️

複数のSnowflakeアカウントでPrivateLinkを構成する際のSnowsightのURLについて

2025/02/27に公開
Snowflake
tech

はじめに

複数のSnowflakeアカウント（同一リージョン）でPrivateLinkを構成する際、SYSTEM$GET_PRIVATELINK_CONFIG関数で取得する「snowsight-privatelink-url」の値が同一になってしまいます。例えば東京リージョンの場合、app.ap-northeast-1.privatelink.snowflakecomputing.comという値になります。
※この関数の出力結果や、SnowflakeのPrivateLink構成そのものについての解説は行わないため、必要に応じて公式ドキュメントをご確認ください。

この際、1つのAWSアカウントで複数のPrivateLinkを構成したり、PrivateLinkで使用するCNAMEレコードの名前解決をオンプレミスのDNSサーバで実施させたりする場合には、「snowsight-privatelink-url」をどのVPCエンドポイントに名前解決すればよいか分からなくなってしまうな、、、と思いました。

ざっくり絵に起こしてみれば、以下のような構成です。

1つのAWSアカウントのRoute53で名前解決



1つのAWSアカウントのRoute53で名前解決

そこでSnowflakeサポートに問い合わせてみたところ、以下の回答をいただきました。
（迅速に対応いただけるサポートの皆様には日々感謝です！！）

  • CNAMEの名前解決はいずれのVPCエンドポイントでも可能
  • ネットワークを完全に分離させたい場合には、サポートに連絡してSnowsightアクセス時のプライマリURLを「regionless-snowsight-privatelink-url」に変更可能

ということで、上記の内容を確かめるべく自分でも検証を行ってみました。

検証結果サマリ

サポート回答の通りでしたが、検証結果のサマリは以下の通りです。結果だけ知りたい方はここまでで大丈夫です。

  1. 複数のSnowflakeアカウント（同一リージョン）でPrivateLinkを構成する際、「snowsight-privatelink-url」の名前解決先となるVPCエンドポイントは、どれか1つを選択すれば問題なし

複数のSnowflakeアカウントでPrivateLinkを構成すると、AWS側でVPCエンドポイントもその分作成することになります。一方で、DNS（今回はRoute53）を使ってそのVPCエンドポイントに対するCNAMEでの名前解決をしなければいけない「snowsight-privatelink-url」は、app.ap-northeast-1.privatelink.snowflakecomputing.comのようにリージョンで同一の値になってしまいます。
しかし、これをCNAMEで名前解決させる先のVPCエンドポイントはどれか1つを選択すれば問題ない、ということが今回の検証で分かりました。

そもそもCNAMEで同一の値を複数レコード登録することはできないため、この構成にならざるを得ないのですが、詳細は本記事の続きを読んでいただければと思います。

なお、Snowflakeアカウント側の「privatelink-vpce-id」の値が同一である、という前提条件が必要な可能性はあります。この辺りはSnowflakeのサービスの裏側の話になるので追及は難しいのと、これが別値になる環境を作成できなかったため未検証です。

  1. 各アカウント毎にSnowsightのURLを分けなければいけない場合は、サポートに連絡してSnowsightのプライマリURLを「regionless-snowsight-privatelink-url」に変更することで対応可能

「snowsight-privatelink-url」と異なり、「regionless-snowsight-privatelink-url」は、app-{組織名}-{アカウント名}.privatelink.snowflakecomputing.comという形式のため、アカウント毎に一意のURLとなります。この値をそれぞれのVPCエンドポイントに対応するようCNAME登録をすれば、2つの環境のSnowsightにそれぞれ別経路でアクセスできます。
※「regionless-snowsight-privatelink-url」の有効化はSnowflakeサポートへの問い合わせが必要です。

Snowsightへの接続経路を完全に分けなければいけない場合は、こちらの方法を選択する必要があります。

今回の検証で実施すること

それでは、ここから実際に検証した内容について書いていきます。
ざっくりと図にすると、今回は以下のような構成で検証をしてみました。

検証構成
※Snowsight接続はVPC内のプライベートサブネットにEC2を立てて確認しました

こちらの構成で、以下のことを検証しています。

SnowsightプライマリURL変更前：
「snowsight-privatelink-url」を片方のVPCエンドポイントに紐づけた際に、もう片方のSnowsightアクセスに問題が発生しないか

SnowsightプライマリURL変更後：
「privatelink-account-url」、「privatelink-ocsp-url」、「regionless-snowsight-privatelink-url」のCNAME登録をして、2つの環境のSnowsightにそれぞれログインできるようになるか確認。

検証①（プライマリURL変更前）

まずは、通常通りPrivateLinkの構成を確立するために、以下のドキュメントの「VPC エンドポイント（VPCE）を作成および構成する」までは実施しておきます。
https://docs.snowflake.com/ja/user-guide/admin-security-privatelink
※検証対象外のため、内部ステージのPrivateLinkは構成しません。

まだRoute53のプライベートホストゾーンを登録していないため、現段階では以下のような構成になっています。
（今回たまたまSnowflake側の「privatelink-vpce-id」は同じでした。具体的な値はぼかしています）


次に、Route53でプライベートホストゾーンを作成します。今回はホストゾーンのドメイン名を「privatelink.snowflakecomputing.com」とします。これは、リージョンまで含めて「ap-northeast-1.privatelink.snowflakecomputing.com」をドメインとすると検証②で行うリージョンレスURLの名前解決のところでホストゾーンを追加しないといけなくなるためです。


このホストゾーンに、まずはSnowflakeアカウント①分のCNAMEを以下のように登録します。


追加した3つのCNAMEレコードは上から順番に、SYSTEM$GET_PRIVATELINK_CONFIG関数出力結果の以下の値に対応したものです。

  • snowsight-privatelink-url
  • privatelink-account-url
  • privatelink_ocsp-url

※今回は検証にあたって必要最小限のレコードを記録していますが、実際には要件に合わせて構成する必要があります。また、おそらくですが「privatelink_ocsp-url」がなくても通ります。

次に、Snowflakeアカウント②分は以下の2つを登録します。



こちらは以下の2つに対応しています。

  • privatelink-account-url
  • privatelink_ocsp-url

ちなみに、CNAMEレコードは同じレコード名を登録できないため、「app.ap-northeast-1.privatelink.snowflakecomputing.com」のレコードをSnowflakeアカウント②のVPCエンドポイント用にもう1つ登録しようとすると、以下のエラーになります。


では、この状態（CNAMEレコードを計5つ追加した状態）でSnowsight接続用EC2インスタンスからSnowflakeの各アカウントに対してSnowsight接続を試みます。

Snowflakeアカウント①：

↓


Snowflakeアカウント②：

↓


ということで、「snowsight-privatelink-url」に対応するCNAMEレコードは、Snowflakeアカウント①の分のみを追加していましたが、どちらのアカウントのSnowsightにも接続できることが分かりました。

ブラウザのURLから察するに、Snowflakeアカウント②にログインする際には、以下の2つの経路が使われたのかと思われます。

ログイン画面はアカウントURLを利用するためこちらの経路
↓

ログイン後はSnowsightのURL（appから始まるもの）を利用するのでこちらの経路

ちなみに、「snowsight-privatelink-url」のCNAMEレコードを削除して「regionless-snowsight-privatelink-url」のCNAMEレコードを2アカウント分登録しても、名前解決に失敗して接続できませんのでご注意ください。
この場合、Snowsightログイン画面まではアクセスできますが、「Sign in」ボタンをクリックすると名前解決エラーになります。

ログイン画面まではアカウントURLを利用するため到達できる
↓

「snowsight-privatelink-url」の名前解決ができないためエラー

「regionless-snowsight-privatelink-url」を利用してそれぞれのアカウントのSnowsightに別経路でアクセスさせるためには、サポートへの連絡が必要となります。
ということで、検証②に移ります。

検証②（プライマリURL変更後）

事前にサポートへ、SnowsightのPrivateLink用のプライマリURLを「regionless-snowsight-privatelink-url」に変更いただくように依頼します。
サポートから変更を実施した旨の返信が来たら、「regionless-snowsight-privatelink-url」を利用したアクセスの動作確認に移ります。

まず、CNAMEレコードを検証①の状態から変更せずに、そのままSnowsightへのログインを試みるとどうなるかを確認してみます。
両アカウントとも結果は同じだったため、1つのSnowflakeアカウントでのキャプチャイメージを以下に貼ります。

↓


名前解決エラーになりました。キャプチャでは隠してしまっていますが、Snowsightログイン後のURLがapp-{組織名}-{アカウント名}.privatelink.snowflakecomputing.comという値になっており、URLが「regionless-snowsight-privatelink-url」に変更されていることが分かります。
また、Snowsightログイン画面までは変わらずアクセスできることから、「regionless-snowsight-privatelink-url」に変更しても「privatelink-account-url」への影響はないということも分かりました。

ということで、ここから「regionless-snowsight-privatelink-url」用にCNAMEレコードを追加していきます。
※「app.～」から始まる「snowsight-privatelink-url」のCNAMEレコードの方は使用しないため、事前に削除しておきます。

まずはSnowflakeアカウント①の分だけ、「regionless-snowsight-privatelink-url」用のCNAMEレコードを登録します。


これでSnowflakeアカウント①のSnowsightにログインを試みると、、、


ログインできました！
ブラウザのURLでは「regionless-snowsight-privatelink-url」でアクセスしていることが確認できます。

もちろん、この状態ではSnowflakeアカウント②のSnowsightは名前解決エラーになり、ログインできません。（キャプチャ略）
以下のようにアカウント②分のCNAMEレコードも追加で登録することで無事にログインできるようになりました。

↓

ということで、サポートに連絡してSnowsightのプライマリURLを「regionless-snowsight-privatelink-url」に変更することで、2つの環境のSnowsightにそれぞれ個別の経路でログインできるということが分かりました。

まとめ

改めてになりますが、今回の検証を通して以下のことが分かりました。

  • 複数のSnowflakeアカウント（同一リージョン）でPrivateLinkを構成する際、「snowsight-privatelink-url」の名前解決先となるVPCエンドポイントは、どれか1つを選択すれば問題ありません。

  • 各アカウント毎にSnowsightのURLを分けなければいけない場合は、サポートに連絡してSnowsightのプライマリURLを「regionless-snowsight-privatelink-url」に変更することで対応可能です。
    • 「regionless-snowsight-privatelink-url」はアカウント毎に一意のURLとなるため、この値をそれぞれのVPCエンドポイントに対応するようCNAME登録をすれば、2つの環境のSnowsightにそれぞれ別経路でアクセスできるようになります。

特に2つ目の方法については、PrivateLinkを構成した2つの環境のSnowsightに対して、それぞれ完全に別経路でアクセスさせたいケースで有用かと思いますので、本記事の内容を参考にしてみてください！

Discussion