分析用のデータをどこに集め、どう運び込むかが決まると、保存先の製品として Snowflake の名前がよく挙がります。
Snowflake は AWS・Google Cloud・Azure のいずれかの上で動くデータ基盤のサービスで、AWS 自身のサービスではありません。
説明で必ず出てくるのが「ストレージとコンピュートの分離」で、計算を受け持つ単位は仮想ウェアハウスと呼ばれています。
この 2 つの仕組みが分かると、Snowflake の請求が何に対して発生するのかと、AWS の Redshift や Athena と並べたときにどこが違うのかにも説明がつきます。
私は Snowflake を使ったことがなく、公式ドキュメントを読みながら学んでいるところです。
データを生のまま保存先へ入れてから中で整える ELT の考え方は、ETL と ELT の違いとして前の記事にまとめました。
Snowflakeとは
Snowflake は、データの保存と処理、分析をまとめて提供するデータ基盤のサービスです。
Snowflake の主要な概念とアーキテクチャの説明によると、利用者が選んだり管理したりするハードウェアは、仮想のものも含めてありません。
保守やアップグレード、チューニングも Snowflake の側が受け持ちます。
その代わり、自社のサーバーやプライベートクラウドに入れて動かすことはできません。
IaaS・PaaS・SaaS の分け方でいえば、インフラにもソフトウェアにも利用者が手を入れない SaaS に近い位置づけです。
中身は、データを置く層、計算する層、全体を取りまとめる層の 3 つに分かれています。
データを置く層
テーブルに読み込んだデータは、Snowflake が独自に最適化した、圧縮済みの列指向の形式に組み直してクラウドのストレージへ置きます。
ファイルの大きさや圧縮、統計の情報まで Snowflake が管理するので、利用者がファイルの置き方を決める場面はありません。
テーブルのデータは、自動でマイクロパーティションという単位に分けられます。
マイクロパーティションの説明によると、1 つのマイクロパーティションには圧縮前の大きさで 50 MB から 500 MB のデータが入り、列ごとに分けて保存されます。
列ごとの値の範囲もメタデータとして記録されているので、クエリに関係しないマイクロパーティションは読み飛ばせます。
計算する層
クエリを実行するのは、仮想ウェアハウスと呼ばれる計算資源のクラスターです。
仮想ウェアハウスどうしは計算資源を共有しない独立したクラスターで、ほかのウェアハウスの性能に影響しないと説明されています。
全体を取りまとめる層
3 つ目のクラウドサービス層は、サインインからクエリの振り分けまで、利用者の依頼を処理するための仕事をまとめて受け持ちます。
認証とアクセス制御、メタデータの管理、クエリの解析と最適化などが、この層の担当です。
ドキュメントは、この構成を、共有ディスク型とシェアードナッシング型という従来の 2 つの作りを組み合わせたものと説明しています。
保存したデータはどの計算ノードからも読める 1 か所にまとめ、クエリは各ノードが手元にデータの一部を持つ並列のクラスターで処理する、という組み合わせです。
データは 1 か所にまとめて置き、計算はウェアハウスごとに独立させる、というのが Snowflake の骨格になります。
なぜストレージとコンピュートを分けるのか
計算と保存が同じノードに載っている作りでは、保存の容量が足りなくなると計算のノードごと足すことになります。
AWS の Redshift には、この作りと分けた作りの両方が並んでいるので、比べると違いが見えやすくなります。
Redshift のプロビジョニングされたクラスターの説明によると、DC2 ノードはデータをノードのローカル SSD に持ちます。
データが増えたら、計算ノードを足して保存の容量を増やす作りです。
一方で RA3 と RG のノードはマネージドストレージを使い、計算と保存を別々に増やし、別々に支払えます。
保存と計算を分けると、得られる効果は大きく 3 つあります。
1 つ目は、保存の量と計算の量を、それぞれの必要に合わせて決められることです。
2 つ目は、同じデータを複数のウェアハウスから同時に読めることです。
取り込みの処理と BI のダッシュボードに別々のウェアハウスを割り当てれば、重い取り込みが走っていても、ダッシュボードの速さは影響を受けません。
3 つ目は、データを写さずに渡せることです。
Secure Data Sharing の概要によると、ほかの Snowflake アカウントへデータを共有しても、実際のデータはコピーも転送もされません。
受け取る側は共有されたデータの保存料を払わず、読むときに使う自分のウェアハウスの計算だけを払います。
同じ考え方で、テーブルやデータベースのクローンも、作った時点では元のマイクロパーティションを共有していて、保存の容量を使いません。
テーブルの保存に関する注意点には、クローンに変更を加えると、その分だけクローン専用のマイクロパーティションが増えると書かれています。
仮想ウェアハウスの仕組み
仮想ウェアハウスは、クエリの実行と、データの読み込みを含むすべての DML に必要な計算資源です。
名前に「ウェアハウス」と付いていますが、データを置く場所ではなく、計算だけを受け持つものなので気をつけてください。
サイズと秒単位の課金
仮想ウェアハウスの概要によると、ウェアハウスには X-Small から 6X-Large までのサイズがあります。
サイズで決まるのは、1 つのクラスターが持つ計算資源の量です。
消費するのは Snowflake のクレジットで、従来型（Gen1）の標準ウェアハウスでは X-Small が 1 時間に 1 クレジットです。
サイズが 1 つ上がるごとに、1 時間あたりのクレジットは 2 倍になります。
課金は秒単位ですが、ウェアハウスが動き出すたびに最低 60 秒分がかかります。
ドキュメントの比較表では、X-Small を 0〜60 秒動かしても 61 秒動かしても 0.017 クレジットで、1 時間動かすと 1 クレジットです。
大きいサイズほど複雑なクエリは速くなる傾向がありますが、小さく単純なクエリは大きくしても速くなるとは限りません。
データの読み込みも、数百から数千のファイルを同時に読むのでなければ、Small から Large で足りることが多いとされています。
新しい世代の Gen2 の標準ウェアハウスもあり、こちらのクレジットの消費量は別の表で決められています。
自動停止と自動再開
ウェアハウスはいつでも止めたり動かしたりでき、止まっている間はクレジットを消費しません。
既定では自動停止と自動再開が有効で、一定時間クエリが来なければ止まり、クエリが来れば動き出します。
CREATE WAREHOUSE のリファレンスによると、自動停止までの時間の既定は 600 秒（10 分）です。
次は、このリファレンスの構文に沿って、取り込み用と BI 用のウェアハウスを分けて作る例として私が書いたもので、実行はしていません。
-- 取り込み用（小さく作り、60 秒動きがなければ止める）
CREATE WAREHOUSE load_wh
WAREHOUSE_SIZE = XSMALL
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;
-- BI 用（同じデータを別の計算資源で読む）
CREATE WAREHOUSE bi_wh
WAREHOUSE_SIZE = MEDIUM
AUTO_SUSPEND = 300
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;INITIALLY_SUSPENDED の既定は FALSE で、指定しなければ作った直後からウェアハウスが動き始めます。
止めると、ウェアハウスが持っていたテーブルのデータのキャッシュは消えるので、再開した直後のクエリは遅くなることがあります。
クエリの結果そのものは別に 24 時間保存され、データが変わっていなければ、まったく同じクエリにその結果が使い回されることがあります。
大きくするか、数を増やすか
計算を増やす方法は、ウェアハウスを大きくするスケールアップと、クラスターの数を増やすスケールアウトの 2 つです。
ウェアハウスの使い方の注意点は、大きくするのは主にクエリを速くするためで、同時に来るクエリの多さへの対策ではないと書いています。
同時実行の多さには、ウェアハウスを分けるか、クラスターの数を自動で増減するマルチクラスターウェアハウスで対応します。
マルチクラスターウェアハウスは、Enterprise Edition 以上で使える機能です。
動いているウェアハウスを大きくしても実行中のクエリには効かず、増えた資源は待っているクエリと新しいクエリから使われます。
サイズを選ばないAdaptive Warehouse
2026 年 6 月 16 日には、サイズを選ばない Adaptive Warehouse が一般提供になりました。
Adaptive Compute の説明によると、利用者はサイズやマルチクラスターの設定、自動停止と自動再開の設定を持ちません。
計算資源は、Snowflake がクエリに合わせて割り当てます。
課金はクエリごとに使った資源で決まり、ウェアハウスの費用はその中で動いたクエリの合計になります。
使うには Enterprise Edition 以上が必要で、提供先には AWS の東京リージョンも含まれています。
サイズを決めて動いた時間で払う従来型と、クエリごとに払う Adaptive 型の 2 つが並んでいる、と捉えておくと資料を読み違えにくくなるでしょう。
どこで使われるか
AWS の上で使う場合は、Snowflake のアカウントを置く AWS のリージョンを選びます。
Snowflake の対応リージョンの一覧によると、アカウントは 1 つのリージョンに置かれ、そのリージョンがデータの保存場所と計算資源の場所を決めます。
AWS では、東京（ap-northeast-1）と大阪（ap-northeast-3）のリージョンも選べます。
よくある構成は、S3 にたまったデータを Snowflake に読み込み、Snowflake の中で変換してから BI で読む形です。
S3 のファイルは外部ステージとして Snowflake に登録し、COPY INTO でまとめて読み込むか、Snowpipe で届いた順に読み込みます。
Snowpipe を S3 で自動化する手順では、S3 のイベント通知が SQS のキューを通して、新しいファイルが届いたことを Snowpipe に知らせる流れです。
読み込んだ後の変換は、Snowflake のウェアハウスで SQL を実行する ELT の形になり、dbt もこの段で使われます。
S3 を読む権限は、ストレージ統合という Snowflake のオブジェクトで渡します。
ストレージ統合の設定手順によると、Snowflake はアカウントごとに 1 つの IAM ユーザーを用意しています。
自分の AWS アカウントに作った IAM ロールを、外部 ID を付けた信頼ポリシーでその IAM ユーザーに引き受けさせる仕組みです。
シークレットキーのような認証情報を Snowflake に渡さずに済むのが、この方式の利点になります。
読み込んだテーブルのデータは、自分のバケットではなく、Snowflake が管理するクラウドのストレージに置かれます。
自分の S3 にデータを置いたまま扱いたい場合は、Apache Iceberg のテーブルを使う方法もあります。
この場合、データとメタデータのファイルは S3 のような外部のストレージに置かれ、そのストレージは Snowflake の一部ではありません。
Iceberg のテーブルとレイクハウスの考え方は、データウェアハウス・データレイク・レイクハウスの違いを扱った記事で書きました。
先に知っておく用語
OLTP・OLAP やデータウェアハウスといった言葉は同じシリーズの前の記事で確かめたので、ここでは Snowflake に固有の言葉を挙げておきます。
- クレジット: Snowflake で計算資源の使用量を数える単位。請求額はクレジットの数に単価を掛けて決まり、単価はエディション・リージョン・契約の形で変わる
- エディション: Standard・Enterprise・Business Critical・Virtual Private Snowflake の 4 段階の契約の種類。上の段ほど機能が増える
- マイクロパーティション: テーブルのデータを自動で分けた保存の単位。圧縮前で 50〜500 MB
- ステージ: 読み込むファイルや書き出したファイルを置く場所。Snowflake の中の内部ステージと、S3 などを指す外部ステージがある
- Snowpipe: ステージに届いたファイルを、届いた順に読み込む仕組み。計算は Snowflake が用意するサーバーレスの資源で行う
- Time Travel: 変更や削除をする前のデータを、決めた日数のあいだ読み戻せる仕組み
- Fail-safe: Time Travel の期間が過ぎた後の 7 日間、Snowflake がデータの復旧を試みられる期間
- ゼロコピークローン: データを写さずに、テーブルやデータベースの複製を作る機能
いつ使わないか
Snowflake は AWS の上で動いていても AWS とは別の会社のサービスで、アカウントも権限の仕組みも AWS の外に持ちます。
Snowflake のアクセス制御の概要によると、権限は主に、ロールに与えてからそのロールをユーザーに割り当てる形で管理します。
AWS の IAM とは別にもう 1 つの権限の仕組みを運用することになるので、AWS のサービスで足りないかを先に確かめておくと安心です。
| 状況 | 選ぶもの | 理由 |
|---|---|---|
| S3 のログなどを、ときどき SQL で調べたい | Athena | サーバーを用意せず、S3 のデータへ直接クエリを投げられる |
| データも利用者も AWS の中にあり、Aurora などから zero-ETL で写したい | Redshift | 取り込みから分析までを AWS の中でつなげられる |
| 変換のジョブや、S3 のデータの台帳が欲しい | Glue | 変換とカタログのサービスで、データウェアハウスの代わりにはならない |
| 使わない時間の計算を払いたくないが、AWS の外には出したくない | Redshift Serverless | 計算は使った分を秒単位で払い、保存は別に払う |
| AWS・Google Cloud・Azure にまたがって、同じ製品で分析したい | Snowflake | 3 つのどのクラウドにもアカウントを置ける |
| データが小さく、集計の種類も決まっている | 業務の DB のまま | 保存先を増やすと、その保守も増える |
Athena の使いどころの説明は、S3 のデータにその場で SQL を投げるなら Athena、多くの大きな表を結合する複雑なクエリなら Redshift、と分けています。
Redshift Serverless の課金の説明によると、計算は秒単位で、最低 60 秒分から課金されます。
保存の料金は計算とは別に、GB 月で数えます。
保存と計算の分離そのものは AWS の中でも手に入るので、それだけでは Snowflake を選ぶ決め手になりません。
AWS の中だけで足りるなら Redshift や Athena、クラウドをまたいで同じ製品を使いたいなら Snowflake、と考えると最初の候補を絞りやすくなります。
課金と落とし穴
Snowflake の費用の全体像の説明によると、請求は計算・保存・データ転送の 3 つの合計です。
課金の軸
金額は改定されやすく、エディションやリージョン、契約の形でも単価が変わるので、ここでは何に対して払うかだけを挙げます。
- 仮想ウェアハウス: 動いている間のクレジットで課金される。秒単位で、動き出すたびに最低 60 秒分。止まっている間は消費しない
- サーバーレスの機能: Snowpipe や検索の最適化のように Snowflake が計算資源を用意する機能は、ウェアハウスとは別にクレジットを消費する。Snowpipe は読み込んだデータ 1 GB あたりの決まったクレジットで数え、CSV や JSON は圧縮前の大きさで数える
- クラウドサービス層: 認証やメタデータの管理にもクレジットを使う。課金されるのは、1 日の使用量がその日のウェアハウスの使用量の 10% を超えたときだけ
- 保存: 毎日の保存量の月平均に、TB あたりの定額で課金される。テーブルは圧縮後の大きさで数え、ステージのファイル、Time Travel と Fail-safe で残すデータ、元のテーブルでは消してもクローンが参照しているデータも含む
- データ転送: 取り込みには課金されない。別のリージョンや別のクラウドへデータを出すときに課金され、同じリージョンの中は無料。読み込み元の S3 の側で転送の料金がかかることはある
- 無料トライアル: 30 日間か、無料分を使い切るまで。支払い情報なしで始められる
Snowpipe の数え方は Snowpipe の費用の説明に、データ転送の数え方はデータ転送の費用の説明にまとめられています。
自動停止を短くしすぎても高くつく
自動停止を 0 か NULL にすると、ウェアハウスは止まらなくなります。
止まらないウェアハウスは、クエリを処理していない間もクレジットを消費し続けます。
反対に、自動停止を短くしすぎるのも得策ではありません。
2〜3 分おきにクエリが来るのに自動停止を 1〜2 分にすると、止まっては動き出すのを繰り返し、そのたびに最低 60 秒分が課金されます。
ウェアハウスの使い方の注意点は、5 分か 10 分以下の短い値を勧めながら、クエリが来る間隔に合わせるよう書いていました。
停止の処理はおよそ 30 秒ごとに動くので、30 秒未満の値や 30 の倍数でない値は、思ったとおりには止まらないことがあります。
消したデータにも保存料がかかる
通常のテーブルは、変更や削除をする前のデータを Time Travel の期間だけ残します。
期間の既定は 1 日で、Enterprise Edition 以上では 90 日まで延ばせます。
その後に 7 日間の Fail-safe が続き、この 7 日は変えられません。
Fail-safe はほかの手段を尽くした後に Snowflake が試みる復旧の仕組みで、利用者が過去のデータを読むためのものではないとされています。
保存の費用の説明によると、残している期間のデータも保存料の対象です。
ただし、残すのは変更や削除された行を戻すのに要る分だけで、テーブルを丸ごと残すのは、テーブルを削除したときと TRUNCATE したときに限られます。
1 日以内で作り直す ETL の作業用のテーブルは、Fail-safe の無いトランジェントテーブルにすれば、この保存料を抑えられます。
ただしトランジェントテーブルのデータは、Time Travel の期間を過ぎると戻せません。
そのため、Snowflake の外で作り直せるデータに限って使うよう勧められています。
上限はリソースモニターで決める
使いすぎを止める仕組みとして、リソースモニターがあります。
決めたクレジットの量に達したら、通知を送ったり、割り当てたウェアハウスを止めたりできます。
次は、リソースモニターの説明にある例からの抜粋で、コメントは私が日本語で足しました。
USE ROLE ACCOUNTADMIN;
-- 90% で新しいクエリの受け付けを止め、100% で実行中のクエリも取り消して止める
CREATE OR REPLACE RESOURCE MONITOR limit1 WITH CREDIT_QUOTA = 1000
TRIGGERS ON 90 PERCENT DO SUSPEND
ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE wh1 SET RESOURCE_MONITOR = limit1;SUSPEND は実行中のクエリが終わるのを待ってから止めるので、上限を超えてクレジットを使うことがあります。
また、リソースモニターが見張れるのはウェアハウスだけで、Snowpipe のようなサーバーレスの機能や AI の機能の消費は追えません。
それらの消費は、予算（Budgets）の機能で見張るよう案内されています。
S3を読ませる権限は自分の側で設計する
Snowflake の基盤の運用は Snowflake が受け持ちますが、自分の AWS アカウントの側の設定は自分の責任です。
ストレージ統合に引き受けさせる IAM ロールには、読ませたいバケットとパスだけを許可するポリシーを付けます。
ストレージ統合の側でも、外部ステージに指定してよいバケットとパスを列挙して、読める場所を絞れます。
Snowflake の中のロールと権限の設計も、利用者の側の仕事として残ります。
他クラウドでは
Snowflake 自身は、AWS・Google Cloud・Azure のどれの上にもアカウントを置けます。
対応するクラウドプラットフォームの説明によると、保存・計算・クラウドサービスの 3 つの層は、すべて選んだクラウドの上に置かれる作りです。
アカウントごとに違うクラウドを選べる一方で、別のプラットフォームに置いたファイルを読み込むと、転送の料金がかかる場合があります。
クラウド事業者が自前で持つデータウェアハウスにも、保存と計算を分ける作りが広がっています。
Google Cloud の BigQuery も、BigQuery の概要によると、保存の層と計算の層を分けた構成です。
Azure では、Fabric Data Warehouse の概要が保存と計算を分けた作りを挙げていて、データは Delta 形式のテーブルとして置かれます。
Snowflake の立場から 3 社を並べると、次のとおりです。
| 区分 | AWS | Google Cloud | Azure |
|---|---|---|---|
| クラウド事業者のデータウェアハウス | Redshift | BigQuery | Fabric Data Warehouse |
| Snowflake のアカウントを置く先 | AWS のリージョン | Google Cloud のリージョン | Azure のリージョン |
参考
本文のリンクで紹介した公式ドキュメントは、いずれも 2026-10-05 に参照しました。
Snowflake は機能の追加が速く、2026 年 6 月の Adaptive Warehouse のように、ウェアハウスの形そのものが増えることもあります。
構成を決める前には、リンク先の最新の記述を確かめてください。
最後に
Snowflake は、データを 1 か所に置き、計算を独立した仮想ウェアハウスに分けることで、保存と計算を別々に増やし、別々に払えるようにしたサービスです。
請求の中心はウェアハウスが動いた時間のクレジットなので、ウェアハウスの大きさと止め方の決め方がそのまま費用に響きます。
同じ分離は Redshift の RA3・RG や Serverless にもあるので、選ぶときはクラウドをまたぐかどうかと、AWS の中で管理をまとめたいかどうかを先に考えます。
Snowflake は AWS のサービスではないため、AWS の試験で扱われるのは、比べる側の Redshift や Athena などです。
AWS Certified Data Engineer – Associate（DEA-C01）の試験ガイドでは、第 2 分野のデータストアの管理にタスク 2.1 があります。
このタスクが求めているのは、コストと性能の要件に合わせて Redshift などの保存先を選ぶことです。
Snowflake 社には、基礎を扱う SnowPro Core と、その上の Advanced の認定があり、Snowflake の認定の案内から一覧をたどれます。
ウェアハウスを作る前に、どの処理を同じウェアハウスに載せ、何分動きが無ければ止めるかを書き出しておくと、費用の見通しが立てやすくなります。
以上です。
コメントを残す