はじめに

AWS Community Builderのぺんぎん（@jitepengin）です。

データ基盤としてSnowflakeを採用するケースが増えています。
いざ導入しようとすると「エディション、どれを選べばいいんだっけ？」となる場面は意外と多いと思います。
特にEnterpriseとBusiness Criticalのどちらがいいか判断に迷うことがあると思います。

特にAWSと組み合わせて使う場合、ネットワーク的にセキュアに繋ぎたいという要件が出てくるとエディションの選択が重要なポイントになってきます。

Snowflakeには4つのエディションがあり、上位エディションになるほどセキュリティ・コンプライアンス・可用性などの機能が強化されていきます。
そして、AWS PrivateLinkを使ったプライベート接続だとBusiness Critical Edition以上が必須となるため、「とりあえずEnterpriseで始めたけど、後でPrivateLink必要になった…」となると、変更に少し手間がかかってしまいます。

今回は、Snowflakeのエディションごとの違いを簡単に整理した上で、Business CriticalエディションでAWSとセキュアに接続する方法（特にAWS PrivateLink）について考えてみたいと思います。

Snowflakeのエディションの違い（簡単なまとめ）

Snowflakeには下記の4つのエディションがあります。
上位エディションは下位エディションの機能をすべて含む構造になっており、上にいくほどクレジット単価が高くなります。

Standard Edition

エントリーレベルのエディションで、Snowflakeのコア機能を一通り利用できます。
SQL、半構造化データ、データシェアリング、1日のTime Travelなど、いわゆる「データウェアハウスとして使う」分には十分な機能が揃っています。

スタートアップや小規模なデータ分析チームでまず使ってみたい、というケースに合うかなと思います。

Enterprise Edition

Standardの機能に加えて、本番運用で必須となる機能が追加されます。

• マルチクラスタウェアハウス（同時実行ユーザ数のスケール）
• マテリアライズドビュー
• 最大90日のExtended Time Travel
• 列レベル・行レベルセキュリティ
• 動的データマスキング
• Query Acceleration Service
• Search Optimization Service

実務では、本番運用のSnowflakeはEnterpriseがスタートラインとなる印象です。
データ量や同時実行が増えてくると、マルチクラスタウェアハウスは特に重要になってきます。

Business Critical Edition

こちらは規制対応や機密データを扱う組織向けのエディションです。
Enterpriseのすべての機能に加えて、下記のような機能が追加されます。

• AWS PrivateLink/Azure Private Link/Google Private Service Connect（プライベート接続）
• Tri-Secret Secure（顧客管理鍵CMKによる二重暗号化）
• アカウントフェイルオーバー/フェイルバック
• クライアントリダイレクト
• HIPAA、HITRUST CSF、PCI DSS、FedRAMP対応

PHI（医療データ）、PCI（カード情報）、個人情報といった機密性の高いデータをSnowflakeで扱う場合は、このエディションが必要になります。
また、ネットワーク的にインターネットを介さずに接続したい（PrivateLinkを使いたい）という要件があれば、Business Critical以上が必須となります。

データは企業にとって重要な資産です。
そういった意味でもBusiness Criticalを採用するケースは多い印象です。

Virtual Private Snowflake (VPS)

Snowflakeの最高エディションで、専用のSnowflake環境を提供します。
他の顧客とハードウェアリソースを共有せず、完全に分離された環境で動作します。

金融機関や政府機関など、極めて厳しいセキュリティ要件がある組織向けのエディションです。

こちらは扱った経験がないのと、料金含めてSnowflakeに問い合わせが必要なので詳細は割愛します。

どれを選ぶか

実務上の選定軸としては、下記のような整理になるかなと思います。

• Standard：検証・PoC、小規模な分析チーム
• Enterprise：一般的な本番運用（多くの企業がここから）
• Business Critical：規制業界 / 機密データ / PrivateLink必須の場合
• VPS：完全な分離が必要な金融・政府系

「とりあえずEnterprise」と決めてしまうとPrivateLinkが使えないため、ネットワーク要件は最初に確認しておくのが安全です。
後からアップグレードはできますが、料金体系や設計を見直す必要が出てきます。

AWSとの接続における観点を考える

SnowflakeをAWS上で利用する場合、「クライアントやアプリケーションがどう接続するか」というネットワーク観点は、エディション選定とセットで考える必要があります。
ここでは、Enterprise/Business Criticalそれぞれの観点で接続方式を整理したいと思います。

Enterprise Editionでの接続

Enterprise Editionでは、AWS PrivateLinkは利用できないため、Snowflakeへの接続は基本的にインターネット経由となります。

👁 Image

クライアント/AWSサービス
 ↓
 インターネット
 ↓
 Snowflake

「インターネット経由」と聞くと不安に感じるかもしれませんが、Enterpriseでも下記のような対策を組み合わせることで、十分なセキュリティを確保することは可能です。

1. ネットワークポリシーによるIP制限

Snowflake側のネットワークポリシーで、接続元IPを制限することができます。
社内ネットワークやNAT GatewayのEIPなど、出口となるIPを限定することで、不正アクセスのリスクを大幅に下げることができます。

2. Key Pair認証 + Secrets Manager

認証情報の管理についても、パスワード認証ではなくKey Pair認証を利用するのが標準です。
2026年現在、Snowflakeは単一要素パスワード認証の廃止を進めており、システム連携ではKey Pair認証またはOAuthが推奨となっています。

AWS Lambdaなどから接続する場合は、秘密鍵をSecrets Managerで管理するのがいいと思います。

👁 Image

Event Source
 ↓
AWS Lambda
 ↓
Secrets Manager
 ↓
Private Key取得
 ↓
Snowflake (インターネット経由 TLS)

こちらは過去の記事でもまとめているので参考にどうぞ
https://zenn.dev/penginpenguin/articles/03f6ffff54b0d4

3. TLS暗号化

Snowflakeへの通信は当然TLSで暗号化されているため、通信路自体の機密性は確保されます。
つまり、Enterpriseでも「IP制限 + Key Pair認証 + TLS」を組み合わせれば、ある程度実用的なセキュリティ水準には到達できます。
ただし、トラフィック自体は依然としてインターネットを経由します。

Enterprise Editionでの限界

下記のような要件が出てくる場合、Enterpriseでは対応できません。

• 監査・コンプライアンス要件で「インターネットを経由しない構成」が求められる
• 社内セキュリティポリシーで外部接続にPrivateLink必須
• HIPAA、PCI DSSなどの規制対象データを扱う
• 自社の鍵管理サービス（KMS）でデータを暗号化したい（Tri-Secret Secure）

こうした要件が出てくると、Business Critical以上のエディションが必要になります。

Business Critical Editionでの接続

Business Critical EditionではAWS PrivateLinkが利用可能となり、AWS VPCとSnowflakeの間をプライベートネットワークで接続できます。

この時、トラフィックはAWSのバックボーンネットワーク内に閉じ、インターネットを一切経由しません。

👁 Image

 AWS VPC
 ↓
 VPC Interface Endpoint
 ↓
 AWS PrivateLink
 ↓
 Snowflake VPC

セットアップ手順の概要

公式手順に沿うと、大きく下記のステップで構成します。

1. Snowflake側でPrivateLinkを有効化

ACCOUNTADMINロールで、SnowflakeアカウントにAWS PrivateLinkを認可します。
事前にAWS CLIのSTSでフェデレーショントークンを取得しておきます。

aws sts get-federation-token --name your-user-name

取得したトークンを使って、Snowflake側で認可を実行します。

USE ROLE ACCOUNTADMIN;

SELECT SYSTEM$AUTHORIZE_PRIVATELINK(
 '<aws_account_id>',
 '<federated_token>'
);

認可の確認は下記のシステム関数で行えます。

SELECT SYSTEM$GET_PRIVATELINK('<aws_account_id>', '<federated_token>');

Account is authorized for PrivateLink. が返ってくれば成功です。

2. VPCエンドポイントIDを取得

Snowflake側からAWS VPCエンドポイント作成に必要な情報を取得します。

SELECT SYSTEM$GET_PRIVATELINK_CONFIG();

レスポンスのJSONに含まれる privatelink-vpce-id をメモしておきます。
このIDが、AWS側でVPC Endpointを作成する際の「サービス名」になります。

3. AWS側でVPCエンドポイントを作成

AWS側でVPC Interface Endpointを作成します。

• サービス名：先ほどの privatelink-vpce-id の値
• VPC：接続元となるVPC
• サブネット：マルチAZで配置するのが推奨
• セキュリティグループ：Lambda / EC2側からポート443と80を許可

ポート80はOCSP（証明書失効確認）用に必要となるため、忘れずに開けておきます。

4. DNSの設定

PrivateLinkで接続する際は、SnowflakeのアカウントURLが下記のような形式になります。

<account_identifier>.privatelink.snowflakecomputing.com

SYSTEM$GET_PRIVATELINK_CONFIG() で返されるエンドポイント名を、AWSのVPC Endpointの DNS名にマッピングするCNAMEレコードを設定します。
Route 53のPrivate Hosted Zoneを使うのが一般的です。

5. 接続確認

クライアント側からSnowflakeに接続して動作を確認します。
事前確認には SnowCD（Snowflake Connectivity Diagnostic Tool）を使うと、PrivateLink経由の接続を診断できます。

snowcd <hostfile>

S3アクセス用のVPCエンドポイントの設定

ここが落とし穴というか忘れがちな部分です。
Snowflakeのドライバ（JDBC、ODBC、Pythonコネクタなど）は、ステージへのデータロード／アンロード時に裏側でAmazon S3にアクセスします。
PrivateLink経由でSnowflakeに繋いでも、S3へのトラフィックがインターネット経由のままだと、結局そこから漏れてしまいます。

対応方法は下記のいずれかです。

• Snowflake内部ステージ用のAWS VPC Interface Endpointを作成（これを推奨）
• S3 Gateway Endpointを作成し、Snowflakeが使うバケットへのアクセスをプライベート化
• インターネット経由を許容する（非推奨というか、せっかくのプライベート接続の意味が全くなくなってしまいます…）

完全にプライベート化したい場合は、内部ステージ用のVPC Interface Endpointを作成するのが公式の推奨構成です。

パブリックアクセスのブロック

PrivateLinkでの接続を確立した後は、Snowflake側でパブリックアクセスをブロックすることもできます。
これにより、PrivateLink経由以外からの接続を遮断できます。

CREATE NETWORK POLICY privatelink_only
 ALLOWED_IP_LIST = ('10.0.0.0/8');

ALTER ACCOUNT SET NETWORK_POLICY = privatelink_only;

また、SYSTEM$ENFORCE_PRIVATELINK_ACCESS_ONLYシステム関数やEnforce privatelink-only access機能も提供されているのでこちらを使うのもアリだと思います。

VPN等の社内IPと併用しつつ、PrivateLinkだけにすることで、よりセキュアな構成にすることができます。

Tri-Secret Secureの活用

Business Criticalでは、AWS KMSの顧客管理鍵（CMK）を使ったTri-Secret Secureも利用可能です。
Snowflakeの管理鍵に加えて顧客側の鍵をAND条件で要求するため、もしSnowflake側が侵害されても顧客鍵がない限りデータは復号できません。

PrivateLink + Tri-Secret Secureを組み合わせると、規制要件にもかなり強い構成にすることができます。

こちらは扱った経験がないので詳細は割愛します。

クロスリージョン接続について

AWS PrivateLinkは、同一リージョン内での接続が基本ですが、Business Critical以上ではクロスリージョン接続もサポートしています。
例えば、SnowflakeアカウントがUS-EASTにあって、AWSのVPCがAP-NORTHEAST-1（東京）にある場合でも、PrivateLink経由でプライベート接続できます。

ただし、注意点があります。

• S3やKMSなどPaaSサービスはクロスリージョンPrivateLinkに対応していない
• 政府リージョンや中国リージョンでは未対応
• VPCコンソールで「Enable Cross Region endpoint」を有効化する必要がある

実務上はSnowflakeアカウントのリージョンとアプリケーション側のリージョンを揃える設計のほうが、シンプルで運用しやすいと思います。
とはいえ、グローバル環境でのデータ基盤構築を考えると、この辺りの考慮もしておく必要があります。

エディション選定とコストのバランス

Business Critical化のメリットは大きいですが、クレジット単価がEnterpriseから約1.3倍程度上がるため、コストインパクトもそれなりにあります。
2026年時点の参考価格としては下記のようなイメージです（オンデマンド、US East）。

• Standard：約$2/クレジット
• Enterprise：約$3/クレジット
• Business Critical：約$4/クレジット

「絶対にインターネットを通さない」要件が明確にあるならBusiness Critical一択ですが、データセンシティビティとコストのバランスを取って、下記のような切り分けも実務的かなと思います。

• 本番データウェアハウス（機密データ含む）：Business Critical
• 開発・検証環境：Enterprise
• データシェアリング専用アカウント：Enterprise

要件に合わせて、組織内で複数のエディションを使い分けるのも一つの戦略だと思います。

まとめ

今回は個人的な振り返りも含めて、Snowflakeのエディションごとの違いと、Business CriticalエディションでAWSとセキュアに接続する方法を紹介しました。

ポイントをまとめると下記となります。

• Snowflakeには4つのエディション（Standard / Enterprise / Business Critical / VPS）があり、上位ほどセキュリティ・コンプライアンス機能が強化される
• AWS PrivateLinkはBusiness Critical以上が必須となるため、セキュリティ・ネットワーク要件は最初に確認しておくこと
• Enterpriseでも「ネットワークポリシー + Key Pair認証 + TLS」で一定のセキュリティは確保可能
• Business CriticalではPrivateLinkでAWS VPCとプライベート接続でき、トラフィックをインターネットから完全に分離可能
• S3アクセスもプライベート化しないと意味がないので、内部ステージ用のVPC Endpointも併せて設定する
• Tri-Secret Secureと組み合わせると、規制対応に強い構成が組める

特にEnterpriseとBusiness Criticalのどちらを採用するかで悩む場面が多いと思います。
エディション選定は後からの変更も可能ですが、設計・コストの両面で影響が大きいため、要件定義の早い段階でしっかり整理しておくのが良いと思います。

今回の記事が、AWS上でSnowflakeをセキュアに使いたい方の参考になれば幸いです。