Snowflake

SnowflakeのBillingとコスト管理

2026-03-26
更新: 2026-03-27
NicheeLab編集部

Snowflakeの課金はコンピュート(クレジット)ストレージ(TB/月)の2軸で構成されます。 コンピュートはウェアハウスの稼働時間とサーバーレスサービスの使用量に応じてクレジットが消費され、 ストレージはアクティブデータ・Time Travel・Fail-safeの合計容量に対して課金されます。 この記事ではクレジット課金モデルの構造、監視SQL、Resource Monitorの設定、 そして実務で即使えるコスト最適化5策を整理します。

クレジット課金モデル

課金カテゴリ対象課金単位課金タイミング
ウェアハウスクレジットVirtual Warehouseの稼働サイズ × 稼働時間(秒単位、最低60秒)ウェアハウス稼働中
Cloud Servicesメタデータ操作・認証・最適化コンピュートクレジットの10%超過分常時(10%免除枠あり)
Serverless CreditSnowpipe / Clustering / MV / Replication等サービス固有のクレジットレートサービス利用時
ストレージテーブル / ステージ / Time Travel / Fail-safeTB/月(圧縮後のデータ量)日次で計測、月次精算
データ転送リージョン間/クラウド間データ移動GB単位転送発生時

ウェアハウスサイズとクレジット消費

ウェアハウスサイズ1時間あたりのクレジットノード数
X-Small11
Small22
Medium44
Large88
X-Large1616
2X-Large3232
3X-Large6464
4X-Large128128

Multi-cluster Warehouseの場合、上記クレジットにクラスタ数を掛けた値が消費されます。 たとえばMediumサイズで3クラスタ稼働中は 4 × 3 = 12クレジット/時です。

WAREHOUSE_METERING_HISTORY

-- ウェアハウス別の日次クレジット消費
SELECT
  start_time::DATE AS usage_date,
  warehouse_name,
  SUM(credits_used) AS total_credits,
  SUM(credits_used_compute) AS compute_credits,
  SUM(credits_used_cloud_services) AS cloud_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY total_credits DESC;

-- 時間帯別のクレジット消費パターン分析
SELECT
  EXTRACT(HOUR FROM start_time) AS hour_of_day,
  warehouse_name,
  AVG(credits_used) AS avg_hourly_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD(DAY, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY warehouse_name, hour_of_day;

METERING_HISTORY(全サービス統合)

-- 全サービスのクレジット消費を一覧化
SELECT
  start_time::DATE AS usage_date,
  service_type,
  SUM(credits_used) AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY usage_date, total_credits DESC;

-- service_type の値:
-- WAREHOUSE_METERING    : ウェアハウス
-- AUTO_CLUSTERING       : Automatic Clustering
-- MATERIALIZED_VIEW     : MV メンテナンス
-- PIPE                  : Snowpipe
-- REPLICATION           : レプリケーション
-- SEARCH_OPTIMIZATION   : Search Optimization Service
-- SERVERLESS_TASK       : Serverless Task

Resource Monitor

Resource Monitorは、ウェアハウスのクレジット消費に上限を設定し、 閾値到達時に通知・サスペンドを行うガバナンス機能です。 ACCOUNTADMINロールで作成・管理します。

-- Resource Monitorの作成
CREATE RESOURCE MONITOR bi_monitor
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 95 PERCENT DO SUSPEND
    ON 100 PERCENT DO SUSPEND_IMMEDIATE;

-- ウェアハウスにResource Monitorを割り当て
ALTER WAREHOUSE bi_dashboard_wh SET RESOURCE_MONITOR = bi_monitor;

-- アカウントレベルのResource Monitor(全ウェアハウスに適用)
ALTER ACCOUNT SET RESOURCE_MONITOR = account_monitor;

-- Resource Monitorの確認
SHOW RESOURCE MONITORS;

Resource Monitorのアクション比較

アクション動作推奨用途
NOTIFY管理者に通知のみ(ウェアハウスは継続稼働)最初の閾値(70〜80%)
SUSPEND実行中クエリの完了を待ってからウェアハウスを停止中間の閾値(90〜95%)
SUSPEND_IMMEDIATE実行中クエリを即座にキャンセルしてウェアハウスを停止最終閾値(100%)

コスト最適化5策

1. AUTO_SUSPENDの適正化

-- 対話型: 5分(300秒)で自動サスペンド
ALTER WAREHOUSE bi_wh SET AUTO_SUSPEND = 300;

-- バッチ: 1分(60秒)で自動サスペンド
ALTER WAREHOUSE etl_wh SET AUTO_SUSPEND = 60;

-- AUTO_RESUME を有効にしてクエリ受信時に自動再開
ALTER WAREHOUSE bi_wh SET AUTO_RESUME = TRUE;

2. ウェアハウスのワークロード分離

BI・ETL・データサイエンスなど異なるワークロードを同一ウェアハウスで実行すると、 リソース競合によりすべてのクエリが遅くなり、結果的にコスト増大につながります。 ワークロードごとに専用ウェアハウスを作成し、適切なサイズとAUTO_SUSPEND設定を個別に行います。

3. クエリ最適化によるスキャン量削減

-- パーティションプルーニング効率が低いクエリの特定
SELECT
  query_id,
  query_text,
  partitions_scanned,
  partitions_total,
  ROUND(partitions_scanned / NULLIF(partitions_total, 0) * 100, 1) AS scan_pct,
  bytes_scanned / POWER(1024, 3) AS gb_scanned
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD(DAY, -7, CURRENT_TIMESTAMP())
  AND partitions_total > 100
  AND partitions_scanned / NULLIF(partitions_total, 0) > 0.8
ORDER BY bytes_scanned DESC
LIMIT 20;

4. ストレージコストの削減

-- Time TravelとFail-safeのストレージ使用量を確認
SELECT
  table_catalog AS database_name,
  table_schema AS schema_name,
  table_name,
  ROUND(active_bytes / POWER(1024, 3), 2) AS active_gb,
  ROUND(time_travel_bytes / POWER(1024, 3), 2) AS time_travel_gb,
  ROUND(failsafe_bytes / POWER(1024, 3), 2) AS failsafe_gb,
  ROUND(retained_for_clone_bytes / POWER(1024, 3), 2) AS clone_gb
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE active_bytes > 0
ORDER BY (active_bytes + time_travel_bytes + failsafe_bytes) DESC
LIMIT 30;

-- 不要なTransientテーブルの検出(Fail-safeが不要な中間データ)
-- Transientテーブルに切り替えることでFail-safeストレージコストを削減

5. Serverless Creditの監視と制御

-- Serverlessサービス別のクレジット消費トレンド
SELECT
  start_time::DATE AS usage_date,
  service_type,
  SUM(credits_used) AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -1, CURRENT_TIMESTAMP())
  AND service_type != 'WAREHOUSE_METERING'
GROUP BY 1, 2
ORDER BY usage_date, credits DESC;

チャージバックレポート

-- ウェアハウス別の月次コストレポート(チャージバック用)
SELECT
  warehouse_name,
  DATE_TRUNC('MONTH', start_time) AS billing_month,
  SUM(credits_used) AS total_credits,
  SUM(credits_used) * 3.00 AS estimated_cost_usd  -- 単価は契約による
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD(MONTH, -3, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY billing_month DESC, total_credits DESC;

問題で確認

Cost Management

問題 1

ある企業のデータチームがMediumサイズのウェアハウスを月次のバッチETLに使用しているが、ETLジョブは1日1回30分しか実行されない。にもかかわらず月間のクレジット消費が想定の5倍になっている。最も可能性の高い原因と対策の組み合わせはどれか。

  1. Clustering Keysが設定されているため → Clustering Keysを削除する
  2. AUTO_SUSPENDが無効(0)に設定されておりウェアハウスが24時間稼働し続けている → AUTO_SUSPENDを60〜300に設定する
  3. Cloud Services課金が10%免除枠を超過している → ウェアハウスサイズを拡大する
  4. Time Travelのストレージコストが急増している → DATA_RETENTION_TIME_IN_DAYSを0にする

正解: B

Mediumサイズ(4クレジット/時)のウェアハウスが24時間×30日稼働すると4×24×30 = 2,880クレジットを消費しますが、1日30分のETLのみなら4×0.5×30 = 60クレジットで済むはずです。5倍の差はAUTO_SUSPENDが無効でウェアハウスが常時稼働していることが最も可能性の高い原因です。AUTO_SUSPENDを60〜300秒に設定することでアイドル時に自動停止し、コストを大幅に削減できます。

よくある質問

Snowflakeのクレジットとは何ですか?実際の金額はどう計算しますか?

クレジットはSnowflakeのコンピュートリソース消費を測る単位です。1クレジットの金額はEdition・クラウドプロバイダー・リージョンの組み合わせで異なり、契約形態(On-Demand vs Capacity)によっても変わります。たとえばAWS US-EAST-1のEnterprise Editionでは1クレジットが約$3(On-Demand)です。WAREHOUSE_METERING_HISTORYで消費クレジット数を取得し、契約単価を掛けることで実コストを算出できます。ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILYビューでは金額ベースで日次消費を確認できます。

Resource Monitorのアクションで「Suspend & Immediately」はどう動作しますか?

SUSPEND_IMMEDIATEアクションは、クレジット消費が閾値に達した時点で実行中のクエリを即座にキャンセルしてウェアハウスを停止します。一方、SUSPENDアクションは現在実行中のクエリの完了を待ってからウェアハウスを停止します。SUSPEND_IMMEDIATEはコスト上限を厳格に守る必要がある場合に使いますが、ユーザーのクエリが中断されるため本番BIウェアハウスには通常SUSPENDを推奨します。NOTIFYアクションはウェアハウスを停止せず管理者に通知のみ行うため、最初の閾値(例: 80%)にNOTIFY、最終閾値(100%)にSUSPENDを設定する多段構成が一般的です。

Serverless Creditはウェアハウスクレジットと何が違いますか?

ウェアハウスクレジットはユーザーが明示的に作成したVirtual Warehouseの稼働時間に対して課金されます。Serverless Creditは、Snowflakeが自動管理するバックグラウンド処理(Automatic Clustering、Materialized View Maintenance、Snowpipe、Replication、Search Optimization Service等)に対して課金されます。Serverless Creditの単価はウェアハウスクレジットとは異なり、通常やや高めに設定されています。SERVERLESS_TASK_HISTORYやAUTOMATIC_CLUSTERING_HISTORYなどのビューでサービス別のServerless Credit消費を追跡できます。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる
この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。


関連記事
Snowflake

Snowflake資格一覧|全11試験(SnowPro)の難易度・費用

Snowflake認定資格(SnowPro)全11試験の一覧・難易度・費用・出題範囲を徹底解説。...

Snowflake

Snowflake試験の難易度ランキング|全11資格を徹底比較

Snowflake(SnowPro)認定全11試験の難易度をランキング形式で比較。学習時間・合格に必要なスキルから分析。...

Snowflake

Snowflake資格の勉強方法|効率的な学習ルートと合格のコツ

Snowflake認定資格(SnowPro)に最短で合格するための勉強方法。公式リソース・学習スケジュールを徹底ガイド。...

Snowflake

SnowPro Core試験完全解説|出題範囲・問題例・合格戦略

SnowPro Core Certification(COF-C03)を徹底解説。出題範囲・100問の試験形式・合格ライ...

Snowflake

SnowPro Platform Associate完全解説|入門試験の攻略

SnowPro Associate: Platform Certification(SOL-C01)を徹底解説。最も簡単...

Snowflakeの記事一覧 (102件)
© 2026 NicheeLab All rights reserved.