SnowflakeでAWS PrivateLinkを利用する

Snowflake における AWS PrivateLinkの役割

AWS上のSnowflakeサービス(VPC)に、AWSの閉域からアクセスするための機能です。

自分専用のシングルテナントのSnowflake環境が作成されるものではなく、マルチテナントの環境に閉域でアクセスするための専用の入り口が用意されます。

PrivateLinkを使う場合であっても、インターネットからSnowflakeにアクセスすることができます。
つまりセキュリティ的な観点でいえばPrivateLinkを使ったからといって完全に閉域でSnowflakeを利用できるわけではありません。インターネットからのアクセスを制限したい場合はIPアドレス制限ができるSnowflakeの[ネットワークポリシー]機能を使う必要があります。

• AWS PrivateLinkの使用条件は以下の通りです。

  • SnowflakeをBusinessCritical以上のエディションで利用していること
  • AWS VPCのリージョンとSnowflakeのリージョンが一致していること

• 大まかな手順

  1. Snowflakeへの利用申請(アクセス元AWSアカウントID、SnowflakeアカウントIDを伝える)
  2. AWSでVPCエンドポイントの作成(Snowflakeから指示のあったエンドポイント名を検索して作成)
  3. 権威DNSにCNAMEレコードの設定
  4. S3のVPCエンドポイント(ゲートウェイ型)の作成

３番目の「権威DNSにCNAMEレコードの設定」という部分が気になるところです。
というのもVPCエンドポイントを作成すれば、専用のDNS名が作成されるはずです。
VPCエンドポイントのDNS名にアクセスすればいいはずなのに、なぜCNAMEレコードを追加する必要があるのでしょうか。
公式サイトを見ると、以下のように記載されています。

①AWSPrivateLinkエンドポイントを介してSnowflakeにアクセスするには、DNSにCNAME記録を作成して、 SYSTEM$GET_PRIVATELINK_CONFIG 関数からの privatelink-account-url 値と privatelink-ocsp-url 値を許可する必要があります。

②一部のSnowflake機能では、AWSPrivateLinkで機能を使用するために、DNSに追加のCNAME記録が必要です。
Snowflake Data MarketplaceまたはSnowsight：app.<地域ID>.privatelink.snowflakecomputing.com
組織：<組織名>-<アカウント名>.privatelink.snowflakecomputing.com

公式の説明が少し分かりづらいため、番号は私が振りました。
①が必須であり、②は任意という理解であっているようです。

①の必須レコードを使わず、VPCエンドポイント名でSnowflakeにアクセスしたらどうなるのでしょうか。そのへんも検証してみます。
②のSnowsightはクエリ結果の単純な可視化ができて便利なので登録してみます。組織機能はまだ使っていないので登録は見合わせます。

手順の詳細は公式の以下ページもご確認ください。

具体的な手順

では検証していきます。
※この手順はAWSもSnowflakeも東京リージョンにあることを前提としたものです。

まず、SnowflakeのアカウントURLについて少し説明します。

Snowflakeのアクセス用URLは上記リンクにあるとおり、(「組織」機能を使っていない場合は)以下のような形式になっており、このアカウントロケータがユーザ固有の名前になっています。
https://<account_locator>.<region_name>.snowflakecomputing.com

①Snowflakeへの利用申請

Snowflake Communityアカウントにログインし、サポートケースを起票します。
サポートケースの起票の仕方は以下のページを参考にしてください。

• サポートケースのDescriptionでは以下の情報を記載します。
  • SnowflakeアカウントのURL
  • AWSのアカウントID(12桁)
  • AWSのアカウントのリージョン

申請後、最大2営業日でサポートケースからのメールが来ます。(私の場合は翌営業日にメールが来ました)
メッセージには以下のようにselect文で情報を取得してね、と記載されています。

You can get the VPCE ID by running the system function SYSTEM$GET_PRIVATELINK_CONFIG.

Snowflakeのワークシートにてクエリを実行します。

以下のようなJSONデータが出力されます。

上記のデータを分解すると、以下のようなデータになります。

#	Key	Value	備考
1	regionless-privatelink_ocsp-url	ocsp.ocsp-xxxxxxx-xxxxxxx.privatelink.snowflakecomputing.com
2	privatelink-account-name	xx12345.ap-northeast-1.privatelink
3	privatelink-vpce-id	com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxxxxxxxx	VPCエンドポイントで利用
4	privatelink-account-url	xx12345.ap-northeast-1.privatelink.snowflakecomputing.com	DNSにCNAME登録必須①
5	regionless-privatelink-account-url	xxxxxxx-xxxxxxx.privatelink.snowflakecomputing.com
6	privatelink_ocsp-url	ocsp.xx12345.ap-northeast-1.privatelink.snowflakecomputing.com	DNSにCNAME登録必須②
7	privatelink-connection-urls	[]

このあとのVPCエンドポイントの検索で利用するため、3番の[privatelink-vpce-id]の値をメモしておきます。
また、のちほどCNAMEに登録するため4番、6番もメモしておきます。

②AWSでVPCエンドポイントの作成

Snowflakeに申請したAWSのアカウントにログインします。マネジメントコンソールから[VPC]->[エンドポイント]を選択し、[エンドポイントの作成]をクリックすると、以下の画面が表示されます。
[サービスを名前で検索]を選択し、[サービス名]に先程メモしておいたprivatelink-vpce-idの値を入力すると、正常に申請が完了していればサービス名が発見できます。

紐付けたいVPCとサブネットを選択します。

VPCエンドポイントのセキュリティグループについては適切に変更してください。
https://docs.snowflake.com/ja/user-guide/admin-security-privatelink.html#step-1-create-and-configure-a-vpc-endpoint-vpce

443: 一般的なSnowflakeのトラフィックに必要です。
80 ：このポートですべてのSnowflakeのクライアント通信をリッスンする、Snowflake OCSP キャッシュサーバーで必要です。Snowflakeの顧客データが port 80 に流出することはありません。

VPCエンドポイントのステータスが「保留中」から「使用可能」になったことを確認します。

使用可能となったあと、対象のVPCエンドポイントを選択した際に右下に表示されるDNS名をメモします。
VPC単位のDNS名、サブネット単位のDNS名等が表示されます。ここでは一番上に表示されるVPC単位のDNS名をメモします。
このDNS名をのちほどDNSのCNAMEレコードの値として登録します。

③権威DNSにCNAMEレコードの設定

今回のテストではSnowflakeにPrivateLinkでアクセスするクライアントはAWS上にあるEC2を想定しています。
この環境ではWindowsServerをシンプルに立てただけですので、EC2のDNSリゾルバはAmazonProvidedDNS(最近の呼称でいうとRoute 53 Resolver )を指定しています。

AmazonProvidedDNSはRoute53を参照してくれます。
そのためこれからCNAMEレコードを追加する権威DNSは、Route53を利用します。

ユーザの利用環境によってはクライアントが参照するDNSリゾルバはRoute53ではない場合もありますので、その場合は手順を読み替えてください。

Route53でゾーンを新規作成します。先程のJSONデータのアカウントURLの以下のドメイン部分のプライベートホストゾーンを作成します。
ap-northeast-1.privatelink.snowflakecomputing.com
これはパブリックゾーンではないため、snowflakecomputing.comからのDNS委任は必要ありません。あくまでプライベートネットワークのみで通用するゾーンになります。

ホストゾーンを紐付けるVPCは、SnowflakeのPrivateLinkを展開したVPCを選択します。

プライベートホストゾーンが作成されました。
繰り返しますがプライベートゾーンであるためゾーン委任は必要なく、SOAレコードもNSレコードも変更する必要はありません。

ではレコードを登録していきます。
全体として下表のようなものを登録します。

#	レコード名	レコードタイプ	値	備考
1	(アカウントロケータ)	CNAME	(VPCエンドポイントのDNS名)	必須レコード①
2	ocsp.(アカウントロケータ)	CNAME	(VPCエンドポイントのDNS名)	必須レコード②
3	app	CNAME	(VPCエンドポイントのDNS名)	Snowflake Data MarketplaceまたはSnowsightで利用
4	(org_name)-(account_name)	CNAME	(VPCエンドポイントのDNS名)	「組織」機能。今回有効化していないため設定しない

4番はSnowflakeの「組織」機能を使う方は、事前に「組織」機能を申請・有効化し組織名・アカウント名を確認してから設定してください。今回の私の検証では組織機能を有効化していないため、設定しません。

1つ目のレコードを登録します。

レコード名	レコードタイプ	値	備考
(アカウントロケータ)	CNAME	(VPCエンドポイントのDNS名)	必須レコード①

アカウントロケータとは先に説明したとおり、アカウントURLのうち、以下の太字の部分を指します。
xx12345.ap-northeast-1.privatelink.snowflakecomputing.com
このアカウントロケータは例ですので、値は環境毎で読み替えてください。

2つ目のレコードを登録します。

レコード名	レコードタイプ	値	備考
ocsp.(アカウントロケータ)	CNAME	(VPCエンドポイントのDNS名)	必須レコード②

こちらはJSONで取得した[privatelink_ocsp-url]の値の以下の太字の部分をレコードで指定します。
ocsp.xx12345.ap-northeast-1.privatelink.snowflakecomputing.com
このアカウントロケータは例ですので、値は環境毎で読み替えてください。

3つ目のレコードを登録します。

レコード名	レコードタイプ	値	備考
app	CNAME	(VPCエンドポイントのDNS名)	Snowflake Data MarketplaceまたはSnowsightで利用

最終的にこのようなレコードになりました。

④S3のVPCエンドポイント(ゲートウェイ型)の作成

こちらは省略します。
公式には以下のように記載されています。

Snowflakeクライアント（SnowSQL、 JDBC ドライバー、 ODBC ドライバーなど）は、さまざまなランタイム操作を実行するためにS3へのアクセスを必要とします。 PrivateLink VPC ネットワークはインターネット経由のS3アクセスを許可しないため、Snowflakeクライアントに必要なS3ホスト名に1つ以上のゲートウェイエンドポイントを構成する必要があります。
このステップは、SnowflakeクライアントからのS3トラフィックが AWS バックボーンにとどまるために必要です。

SnowflakeクライアントがS3にアクセスすることがあるようです。
その経路も閉域網化したい場合は、Snowflakeクライアントが存在するVPC上にS3のゲートウェイ型VPCエンドポイントを置くようです。
ただしゲートウェイ型のエンドポイントはVPC外からアクセスすることができないため、あくまでSnowflakeクライアントがAWSのVPC内にあることを想定した手順のようです。

今回検証したEC2のサブネットにはすでにVPCエンドポイントのS3ゲートウェイ型が設置済みでした。
もしVPC外からアクセスした場合、S3の経路だけインターネットで接続できればいいということかもしれませんが、そこまでは検証していません。

動作確認

CLIによるテスト

まず、今回SnowflakeクライアントとしているEC2で、VPCエンドポイントのDNS名がプライベートIPで名前解決できるか確かめます。

$ nslookup vpce-xxxxxxxxxx-xxxxxxxx.vpce-svc-xxxxxxxxxxxxxxxxx.ap-northeast-1.vpce.amazonaws.com

CNAMEで登録したレコードも名前解決でプライベートIPが返ってくるか試します。

$ nslookup xxxxxxxx.ap-northeast-1.privatelink.snowflakecomputing.com

問題なければ、まずはVPCエンドポイントのDNS名で、ワークシートのURLにたいしてcurlコマンドでHTTPアクセスを試してみます。

$ curl https://vpce-xxxxxxxxxx-xxxxxxxx.vpce-svc-xxxxxxxxxxxxxxxxx.ap-northeast-1.vpce.amazonaws.com/console#/internal/worksheet
curl: (51) SSL: no alternative certificate subject name matches target host name 'vpce-xxxxxxxxxx-xxxxxxxx.vpce-svc-xxxxxxxxxxxxxxxxx.ap-northeast-1.vpce.amazonaws.com'

SSL/TLS証明書エラーで怒られてしまいましたね。
ホスト名が一致せず、このようなエラーが出る場合、証明書を自分で持っている場合は証明書側のSAN(Subject Alternative Name)に代替ホスト名を登録するような対応をしますが、証明書管理はSnowflake側なのでどうにもしようがないです。
苦し紛れに、警告を無視するオプション -k をつけて試してみます。

$ curl -k https://vpce-xxxxxxxxxx-xxxxxxxx.vpce-svc-xxxxxxxxxxxxxxxxx.ap-northeast-1.vpce.amazonaws.com/console#/internal/worksheet
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
</body>
</html>

404 Not Foundになってしまいました。

ではCNAME登録した名前でアクセスしてみます。

$ curl https://xxxxxxxx.ap-northeast-1.privatelink.snowflakecomputing.com/console#/internal/worksheet
<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta charset="UTF-8" />
    <meta
(snip)

コンテンツが正常に取得できました。

ブラウザによるテスト

今度は同じEC2でブラウザからのアクセスを試してみます。

VPCエンドポイントのDNS名によるテスト

まずはVPCエンドポイントのDNS名でアクセスしてみます。

証明書不一致警告が出たため、不一致を無視してアクセスしてみると、、

404 Not Foundでアクセスに失敗しました。

この結果から推測すると、SnowflakeのWebサーバは(apacheでいう)VirtualHostのような機能をつかってアクセス時のドメイン名をチェックし、それでユーザ毎のテナントに振り分けていると考えられます。

そう考えると当初の疑問、「なぜCNAMEレコードを追加する必要があるのか」は、「SnowflakeのPrivateLinkを使う上で必須だから」といえそうです。

DNSに作成するゾーンは企業の独自ドメイン名ではなく、(東京リージョンの場合は)「ap-northeast-1.privatelink.snowflakecomputing.com」のようなsnowflake固有のドメイン名である必要があります。
ためしに独自ドメインでもテストを行いましたが、"403 Forbidden"が返ってきてエラーとなりました。

CNAMEを設定したDNS名によるテスト

Snowflakeコンソール

以下のようなURLにアクセスすると、問題なくログイン画面が表示され、ログインもできました。
https://xx12345.ap-northeast-1.privatelink.snowflakecomputing.com/console#/internal/worksheet

Snowsightコンソール

Snowsightも試してみます。
Snowflakeコンソールから「アプリをプレビュー」をクリックします。

CNAMEに登録したドメイン名にリダイレクトされます。
https://app.ap-northeast-1.privatelink.snowflakecomputing.com/ap-northeast-1.aws/(アカウントロケータ)

サインインすると、

Snowsightに正常にアクセスできました。

Snowsightのチャートも正常に表示されます。

システム連携テスト(Tableau)

AWS内のWindowsServerからテストするため、SnowflakeのODBCドライバをダウンロードしインストールします。
インストール後、Windowsの[ODBC データソースアドミニストレーター]を起動し、セットアップします。
(後ほどTableauからの接続でも同じような設定をするので、もしかしたらセットアップは不要で、ODBCドライバのインストールだけをすればよいのかもしれません)

CNAMEを設定したDNS名によるテスト

ODBCドライバのセットアップで指定するServerはCNAME登録済みのドメイン（以下例）です。

xx12345.ap-northeast-1.privatelink.snowflakecomputing.com

ODBCドライバをセットアップしたあとは、TableauのコネクタでSnowflakeを選択すればSnowflake専用の接続画面が出てきます。
Tableauの[サーバー]欄は先程ODBCドライバに入力したものと同じものを指定します。

xx12345.ap-northeast-1.privatelink.snowflakecomputing.com

無事プライベートリンクのドメイン名で接続ができました。
接続時の[役割]でACCOUNT ADMINを指定したため、SNOWFLAKEデータベースも見えています。

まとめ

• 以下の検証を行い、正常にアクセスできることを確認しました。

  • CNAMEを設定したDNS名でSnowflakeコンソールにブラウザから閉域接続できること
  • CNAMEを設定したDNS名でSnowsightコンソールにブラウザから閉域接続できること
  • CNAMEを設定したDNS名でTableauからSnowflakeにシステム的な閉域接続できること
  • CNAMEの登録せずにVPCエンドポイントのDNS名を使うと正常にアクセスができないこと(404 NotFoundになる)

• 今回の例では AWS(EC2) -> AWS(Snowflake)の通信でしたので、以下の公式FAQにあるとおり、仮にグローバルIPでアクセスしたとしてもAWS構内経路で完結するはずです(試してはいません)。しかしアクセス元がDirectConnectを通したオンプレにあるような場合では、やはりこのPrivteLinkの機能で閉域を通すのは有効な方法ではあります。

Q:2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスが AWS のサービスのパブリックエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?

いいえ。パブリックアドレススペースを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。

以上です。