AWS PrivateLink とSnowflake¶
この機能には、Business Critical（またはそれ以上）が必要です。
このトピックでは、 AWS PrivateLink を構成して、Snowflakeアカウントを1つ以上の AWS VPCs に直接接続する方法について説明します。
AWS PrivateLink は、Snowflakeが提供するサービスでは ありません。PrivateLinkは、SnowflakeがSnowflakeアカウントでの使用をサポートしている AWS のサービスです。
Business Critical（またはそれ以上）を使用していて、アカウントで AWS PrivateLink を使用する場合は、 Snowflakeサポート に連絡して有効化をリクエストしてください。
このトピックの内容：
AWS PrivateLink とは¶
AWS PrivateLink は AWS のサービスで、プライベート VPC エンドポイントを作成するためのものです。これにより、パブリックインターネットを経由せずに、 AWS VPCs 間の直接的かつ安全な接続が可能になります。AWS 上のSnowflakeは VPC として実装されているため、 PrivateLink はSnowflakeと他の AWS VPCs （同じ AWS リージョン内）の間に安全なネットワークを作成して、不正な外部アクセスに対する十分な保護を提供します。
外部関数 の場合は、 プライベートエンドポイント で PrivateLink を使用することもできます。
さらに、オンプレミス環境（例: ホストされていないデータセンター）がある場合は、 AWS Direct Connect と AWS PrivateLink を組み合わせて使用し、すべての仮想環境と物理環境を単一のプライベートネットワークで接続することを選択できます。
注釈
AWS Direct Connectは独立した AWS のサービスで、 AWS PrivateLink とは独立して実装する必要があり、このトピックの範囲外です。AWS Direct Connectの実装については、Amazonにお問い合わせください。
AWS PrivateLink の有効化¶
注意
アカウントへの AWS PrivateLink の有効化には、最大2営業日かかる場合があります。AWS PrivateLink の有効化をリクエストする場合は、Snowflakeに直接接続したい 各 AWS VPC のアカウント ID を必ず提供してください。不正確または不完全な情報を提供すると、処理が遅れる場合があります。
AWS PrivateLink が有効化されたら、このトピックの次のセクションで説明されているように、 AWS VPC 環境を構成して処理を完了する必要があります。
ステップ1: Snowflakeに連絡してAWS VPCアカウントIDsとアカウントURLsを提供する¶
Snowflakeにアクセスするために使用する、AWS VPCアカウントのIDs および 対応するアカウントURLsのすべてのリストと、AWSPrivateLinkを有効にするメモを用意して、 Snowflakeサポート にご連絡ください。AWS VPCアカウントIDは、AWSが提供する12桁の文字列で構成されます。
AWS VPC アカウント ID の詳細については、 AWS アカウント ID とそのエイリアス をご参照ください。
ステップ2: Snowflakeにより、地域の VPC エンドポイントアドレスが提供される¶
Snowflakeは、AWS VPC アカウント ID を登録し、地域固有の VPC エンドポイント（つまり、 VPCE）アドレスを次の形式で提供します。
com.amazonaws.vpce.<地域ID>.vpce-svc-xxxxxxxxxxxxxxxxx
条件：
<地域ID>は、 AWS 地域 の ID であり、 VPCs とSnowflakeアカウントが置かれている場所です。
SYSTEM$GET_PRIVATELINK_CONFIG を実行すると、AWS VPCE にアクセスできます。
AWS VPC 環境の構成¶
注意
このセクションでは、 VPC 環境を設定するためのSnowflake固有の詳細のみを説明します。
また、必要な AWS VPC のエンドポイント、セキュリティグループルール、および DNS レコードの実際の構成に対し、Snowflakeは責任を 負いません 。これらの構成タスクのいずれかで問題が発生した場合は、 AWS サポートに直接お問い合わせください。
ステップ1： VPC エンドポイント（VPCE）を作成および構成する¶
AWS VPC環境で、
Snowflakeが提供する VPCE アドレスのエンドポイントを作成します。
VPCE セキュリティグループが以下のポートを受け入れる（つまり、「許可する」）ように設定します。
443: 一般的なSnowflakeのトラフィックに必要です。80：このポートですべてのSnowflakeのクライアント通信をリッスンする、Snowflake OCSP キャッシュサーバーで必要です。Snowflakeの顧客データがport 80に流出することはありません。
Snowflakeの発信接続において VPCE CIDR （クラスレスドメイン間ルーティング）のポート
443および80に接続する、サービスのセキュリティグループを許可します。
詳細については、AWS のドキュメントをご参照ください。
ステップ2: VPCネットワークを構成する¶
AWSPrivateLinkエンドポイントを介してSnowflakeにアクセスするには、DNSにCNAME記録を作成して、 SYSTEM$GET_PRIVATELINK_CONFIG 関数からの privatelink-account-url 値と privatelink-ocsp-url 値を許可する必要があります。
他のSnowflake機能を使用するためにDNSを構成する方法の詳細については、 追加のCNAME記録の作成 （このトピック内）をご参照ください。
DNS構成の詳細については、内部のAWS管理者にお問い合わせください。
重要
OCSPキャッシュサーバーのホスト名の構造は、 Snowflakeクライアントの構成 （このトピック内）のステップ1で説明されているように、インストールされているクライアントのバージョンによって異なります。
リストにあるバージョン（またはそれ以上）を使用している場合は、上記のフォームを使用します。これにより、同じ地域に複数のSnowflakeアカウント（例: 開発、テスト、運用）がある場合に DNS の解決度が向上します。クライアントドライバーを更新して OCSP を PrivateLink で使用する場合は、ファイアウォールルールを更新して OCSP ホスト名を許可します。
古いクライアントバージョンを使用している場合、 OCSP キャッシュサーバーのホスト名は
ocsp.<リージョンID>.privatelink.snowflakecomputing.com（つまり、 アカウント識別子 なし）の形式を取ります。また、 DNS 記録は、使用する VPC 内のプライベート IP アドレスで解決する必要があります。パブリックIPアドレスに解決される場合、記録は正しく構成されていません。
追加のCNAME記録の作成¶
一部のSnowflake機能では、AWSPrivateLinkで機能を使用するために、DNSに追加のCNAME記録が必要です。
次の機能のいずれかを使用している場合、または将来これらの機能を使用する可能性があり、AWSPrivateLinkエンドポイントを介してSnowflakeにアクセスしたい場合は、追加のCNAME記録を作成するか、 または 次の機能のURL値を SYSTEM$GET_PRIVATELINK_CONFIG 出力からの privatelink-account-url 値および privatelink-ocsp-url 値と組み合わせます。
- Snowflake Data MarketplaceまたはSnowsight
app.<地域ID>.privatelink.snowflakecomputing.com- 組織
<組織名>-<アカウント名>.privatelink.snowflakecomputing.com
詳細については、 アカウント識別子 をご参照ください。
ステップ3: Amazon S3用 AWS VPC インターフェイスエンドポイントを作成する¶
Snowflakeクライアント（SnowSQL、 JDBC ドライバー、 ODBC ドライバーなど）は、さまざまなランタイム操作を実行するために、Amazon S3へのアクセスを必要とします。PrivateLink VPC ネットワークはパブリックインターネット経由のAmazon S3アクセスを許可しないため、内部ステージへのプライベート接続を構成する、 または Snowflakeクライアントに必要なAmazon S3ホスト名に、1つ以上のゲートウェイエンドポイントを構成する必要があります。このステップは、SnowflakeクライアントからのAmazon S3トラフィックが AWS バックボーンにとどまるために必要です。
全体として、Amazon S3へのアクセスを設定するための3つのオプションがあります。最初の2つのオプションはパブリックインターネットを回避し、3番目のオプションは回避しません。
内部ステージ の AWS VPC インターフェイスエンドポイントを構成します。このオプションをお勧めします。
Amazon S3ゲートウェイエンドポイントを設定します。詳細については、以下の注意をご参照ください。
インターフェイスエンドポイントまたはゲートウェイエンドポイントを構成しないでください。これにより、パブリックインターネットを使用したアクセスが可能になります。
注意
Amazon S3バケットとSnowflakeを使用する AWS VPC の間の通信においてパブリックインターネットの使用を防止するには、Amazon S3ゲートウェイエンドポイントをAmazon S3バケットの AWS リージョンと同一の設定にします。この理由は、 AWS PrivateLink では VPCs 間での通信のみを許可し、Amazon S3バケットは VPC に含まれないためです。
Amazon S3ゲートウェイエンドポイントを構成して、特定のユーザー、S3リソース、ルート、およびサブネットへのアクセスを制限できますが、Snowflakeではこの構成を必要としません。詳細については、 Amazon S3用エンドポイント をご参照ください。
Amazon S3ゲートウェイエンドポイントポリシーを構成して、SnowflakeにAmazon S3リソースのみを使用するよう明確に制限するには、次のオプションのいずれかを選択します。
Snowflakeアカウントで使用される特定のAmazon S3ホスト名アドレスを使用します。アカウントで使用されるホスト名の包括的なリストについては、 SYSTEM$WHITELIST をご参照ください。
Snowflake S3ホスト名に一致するAmazon S3ホスト名パターンを使用します。このシナリオでは、Snowflakeへの接続には、 VPC ツー VPC または オンプレミスツー VPC の2種類の接続があります。
接続タイプに基づいて、次の点に注意します。
- VPC ツー VPC
Amazon S3ゲートウェイエンドポイントが存在することを確認します。オプションで、S3ゲートウェイエンドポイントポリシーを変更して、 Amazon S3ホスト名 テーブルに示されている特定のホスト名パターンに一致させます。
- オンプレミスツー VPC
Amazon S3トラフィックがパブリックゲートウェイで許可されて いない ときは、ファイアウォールまたはプロキシ構成にS3ホスト名パターンを含めるように設定を定義します。
アカウントのSnowflakeが管理するS3バケットに固有である必要がない場合に、ゲートウェイエンドポイントを作成できるAmazon S3ホスト名パターンを次のテーブルに示します。
Amazon S3ホスト名
メモ
すべての地域
sfc-*-stage.s3.amazonaws.com:443sfc-repo.snowflakecomputing.com:443SnowSQL 自動アップグレードを有効にします。
US 東部以外のすべての地域
sfc-*-stage.s3-<地域ID>.amazonaws.com:443パターンは、地域 ID の前にハイフン（
-）を使用します。sfc-*-stage.s3.<地域ID>.amazonaws.com:443パターンは、地域 ID の前にピリオド（
.）を使用します。
ゲートウェイエンドポイントの作成の詳細については、 ゲートウェイ VPC エンドポイント をご参照ください。
SnowCD を使用したSnowflakeへのネットワーク接続の検証 --- オプション¶
AWS PrivateLink を設定した後、 オプションで SnowCD （Snowflake Connectivity Diagnostic Tool）を活用して、Snowflakeおよび AWS PrivateLink とのネットワーク接続を評価できます。
詳細については、 SnowCD および SYSTEM$WHITELIST_PRIVATELINK をご参照ください。
パブリックアクセスのブロック --- オプション¶
Snowflakeとの AWSPrivateLink 接続をテストした後、 オプションで Snowflakeへのパブリックアクセスをブロックできます。パブリックアクセスをブロックするプロセスは、Snowflakeデプロイメントがプロキシプロトコルバージョン1（PPv1）を使用しているか、プロキシプロトコルバージョン2（PPv2）を使用しているかによって異なります。
パブリックアクセスのブロッキングの構成 --- PPv2 を使用したデプロイメント¶
組織の IP アドレス範囲 を使用してSnowflakeへのパブリックアクセスをブロックするように CIDR ブロック範囲を設定します。この範囲は、 VPC内から指定できます。
CIDR ブロック範囲が設定されると、 CIDR ブロック範囲内の IP アドレスのみがSnowflakeにアクセスできます。
ネットワークポリシーを使用してパブリックアクセスをブロックするには、
新しいネットワークポリシーを作成するか、既存のネットワークポリシーを編集します。組織の CIDR ブロック範囲を追加します。
アカウントのネットワークポリシーをアクティブにします。
詳細な手順については、 ネットワークポリシー をご参照ください。
パブリックアクセスのブロッキングの構成 --- PPv2 を使用 しない デプロイメント¶
重要
次の CIDR ブロック範囲は廃止され、Snowflakeのドキュメントから間もなく削除されます。
代わりに、組織の CIDR ブロック範囲を使用してください。
CIDR ブロック範囲を構成して、Snowflakeへのパブリックアクセスをブロックします。 CIDR ブロック範囲が設定されると、 CIDR ブロック範囲内の IP アドレスのみがSnowflakeにアクセスできます。
CIDR ブロック範囲にはネットワークポリシーが必要であり、Snowflakeアカウントが存在する地域に固有です。
地域 |
地域 ID |
CIDR ブロック範囲 |
|---|---|---|
US 西部 |
|
|
US 東部 |
|
|
EU （アイルランド） |
|
|
EU （フランクフルト） |
|
|
アジア太平洋（シドニー） |
|
|
注釈
このセクションの表の CIDR ブロック範囲は、非VPS （仮想プライベートSnowflake）アカウント専用です。
VPS を使用している場合は、 Snowflakeサポート に連絡して CIDR ブロック範囲を取得できます。
ネットワークポリシーを使用してパブリックアクセスをブロックするには、
新しいネットワークポリシーを作成するか、既存のネットワークポリシーを編集します。このセクションのテーブルに従って、地域の CIDR ブロック範囲を 許可された IP アドレスのリストに追加します。
アカウントのネットワークポリシーをアクティブにします。
詳細な手順については、 ネットワークポリシー をご参照ください。
Snowflakeクライアントの構成¶
ステップ1：Snowflakeクライアントが OCSP キャッシュサーバーをサポートしていることを確認する¶
Snowflake OCSP キャッシュサーバーは、Snowflakeクライアントとサーバー間の接続の問題を軽減します。インストール済みのSnowflakeクライアントが OCSP サーバーキャッシュを利用できるようにするには、次のクライアントバージョンを使用していることを確認してください。
SnowSQL 1.1.57 （またはそれ以上）
Pythonコネクタ 1.8.2（またはそれ以上）
JDBC ドライバー3.8.3（またはそれ以上）
ODBC ドライバー2.19.3（またはそれ以上）
注釈
Snowflake OCSP キャッシュサーバーは、ポート 80 をリッスンします。 ステップ1： VPC エンドポイント（VPCE）を作成および構成する で、 PrivateLink VPCE セキュリティグループを構成し、このポートとあわせてポート 443 （他のすべてのSnowflakeトラフィックに必要）を受け入れるようにしたのはこのためです。
ステップ2：Snowflakeクライアントのホスト名を指定する¶
各Snowflakeクライアントには、Snowflakeアカウントに接続するためのホスト名が必要です。
ホスト名は、 ステップ2： VPC ネットワークの構成 の CNAME レコードで指定したホスト名と同じです。
このステップは、Snowflake Data Marketplaceへのアクセスには適用されません。
たとえば、 xy12345 という名前のアカウントの場合、
アカウントが US 西部にある場合、ホスト名は
xy12345.us-west-2.privatelink.snowflakecomputing.comです。アカウントが EU （フランクフルト）にある場合、ホスト名は
xy12345.eu-central-1.privatelink.snowflakecomputing.comです。
重要
ホスト名を指定する方法は、クライアントによって異なります。
Sparkコネクタと ODBC および JDBC ドライバーについては、ホスト名全体を指定します。
他のすべてのクライアントについては、ホスト名全体を指定 しません。
代わりに、 アカウント識別子 を
privatelinkセグメント（つまり、<アカウント識別子>.privatelink）で指定します。これは、Snowflakeがsnowflakecomputing.comと連結してホスト名を動的に構築します。
Snowflakeクライアントのアカウント名またはホスト名の指定の詳細については、各クライアントのドキュメントをご参照ください。
AWS PrivateLink と SSO の併用¶
Snowflakeは、AWS PrivateLinkでSSOの使用をサポートしています。詳細については、次をご参照ください。
サンプル構成テンプレート（AWS us-east-1 のSnowflakeアカウント用）¶
これはテンプレート のみ であることに注意します。実際の VPC 環境を構成するには、すべての変数（テンプレート内の xxxx... 文字列で表示）を必要な値に置き換える必要があります。
また、テンプレートは、Amazon Route 53を DNS ウェブサービスとして使用していると想定しているため、 AWS VPCs とSnowflake間でのトラフィックのルーティング用としてRoute 53プライベートホストゾーンを作成します。別の DNS ウェブサービスを使用している場合は、それに応じてテンプレートを変更します。
詳細については、 プライベートホストゾーンの操作 をご参照ください。
### Information provided by Snowflake
# Variable for VPC route table(s) you will associate to S3 gateway endpoint
ROUTE_TABLE_IDS='rtb-11223344'
# Variable for Snowflake PrivateLink VPC endpoint address
# Your <privatelink-vpce-id> can be found by executing
# select system$get_privatelink_config()
SFC_VPCE_ADDRESS='<privatelink-vpce-id>'
# Variable for AWS Region
REGION_ID='us-east-1'
# Variable for Snowflake PrivateLink DNS hostname.
SFC_PL_DNS='<privatelink_account_url>'
# Your <privatelink_account_url> can be found by executing
# select system$get_privatelink_config()
# Variable for Snowflake Data Marketplace PrivateLink DNS hostname.
SFC_PL_Data_Marketplace_DNS='app.${REGION_ID}.privatelink.snowflakecomputing.com'
### Configuration for your VPC network
# Variable for VPC ID
VPC_ID='vpc-xxxxxxxxxxxx'
# Variables for one or more subnet IDs
SUBNET_ID1='subnet-xxxxxx'
SUBNET_ID2='subnet-xxxxxx'
SUBNET_ID3='subnet-xxxxxx'
# Variable for VPC Endpoint interface security group
SG_ID='sg-xxxxxx'
# Variable for subnet CIDR of services that connect to Snowflake
LOCAL_SUBNET_CIDR='10.xxx.xxx.xxx/xx'
# Create VPC endpoint
aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface \
--service-name ${SFC_VPCE_ADDRESS} \
--subnet-id ${SUBNET_ID1} ${SUBNET_ID2} ${SUBNET_ID3} \
--vpc-id ${VPC_ID} \
--security-group-ids ${SG_ID}
# Variable for the DNS address returned in the output for the VPC endpoint
VPCE_DNS=xxxxxxxx.vpce.amazonaws.com
# Authorize port 443 access to the VPCE
aws ec2 authorize-security-group-ingress \
--group-id ${SG_ID} --protocol tcp --port 443 --cidr ${LOCAL_SUBNET_CIDR}
# Authorize port 80 access to the VPCE
aws ec2 authorize-security-group-ingress \
--group-id ${SG_ID} --protocol tcp --port 80 --cidr ${LOCAL_SUBNET_CIDR}
# Create a private Route 53 hosted zone
aws route53 create-hosted-zone \
--name ${SFC_PL_DNS} \
--vpc VPCRegion=${REGION_ID},VPCId=${VPC_ID} \
--caller-reference $(date +"%s")
# Variable for the hosted zone ID returned in the output for the Route 53 zone
ZONE_ID='/hosted_zone/xxxxxx'
# Create a CNAME record and modify the Route 53 zone to use it
# Create CNAME records for Snowflake Account PrivateLink DNS and
# Data Marketplace DNS, then modify the Route 53 zone to use it.
dns_record='{
"Comment": "Create CNAME records for Account and Data Marketplace",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "'${SFC_PL_DNS}'",
"Type": "CNAME",
"TTL": 300,
"ResourceRecords": [
{
"Value": "'${VPCE_DNS}'"
}
]
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "'${SFC_PL_Data_Marketplace_DNS}'",
"Type": "CNAME",
"TTL": 300,
"ResourceRecords": [
{
"Value": "'${VPCE_DNS}'"
}
]
}
}
]
}'
aws route53 change-resource-record-sets \
--hosted-zone-id ${ZONE_ID} \
--change-batch "${dns_record}"
# Create VPC S3 gateway endpoint
aws ec2 create-vpc-endpoint \
--vpc-id ${VPC_ID} \
--service-name com.amazonaws.${REGION_ID}.s3 \
--route-table-ids ${ROUTE_TABLE_IDS}