はじめに
Snowflakeのコンピュート課金には「60秒最低課金」というルールがあります。このルールについて、「クエリを1本投げるたびに最低60秒分の課金が発生する」と誤解されているケースを見かけます。
この記事では、Snowflakeのコンピュート課金の仕組みを正しく整理し、東京リージョンの実際の金額を使ったシミュレーションを交えながら、auto-suspendの最適な設定について考察します。
対象読者: Snowflakeのコスト管理に関心のあるデータエンジニア・アナリスト
Snowflakeのコンピュート課金の基本
ウェアハウスの状態と課金の関係
Snowflakeのウェアハウスには「サスペンド（停止）」と「稼働中」の2つの状態があります。課金のルールはシンプルです。
- サスペンド中: 課金なし（コンピュートリソースが解放されている）
- 稼働中: 秒単位で課金が発生（クエリの有無に関わらず）
重要なのは、ウェアハウスが稼働している間は、クエリを処理していてもアイドル状態でも同じレートで課金されるという点です。Smallウェアハウスであれば、重いクエリを処理中でも何もしていなくても、常に2クレジット/時のレートが適用されます。
秒単位課金と60秒最低課金のルール
Snowflakeのコンピュート課金は秒単位ですが、ウェアハウスが起動（リジューム）されるたびに最低60秒分のクレジットが発生します。
具体的には以下のようになります。
| シナリオ | 課金される時間 |
|---|---|
| ウェアハウスが30秒で停止 | 60秒分 |
| ウェアハウスが61秒稼働して停止 | 61秒分 |
| 61秒稼働→停止→再起動→30秒で停止 | 121秒分（60+1+60） |
よくある誤解：60秒最低課金はクエリ単位ではない
誤解：「10秒のクエリでも60秒分課金される」
これは半分正しく、半分間違いです。
サスペンド状態からクエリを実行した場合（auto-resumeで自動起動）、ウェアハウスの起動に対して60秒の最低課金が適用されるため、10秒のクエリでも結果的に60秒分の課金が発生します。
しかし、すでにウェアハウスが稼働中の場合、ウェアハウスはもともと秒単位で課金が継続されています。追加の10秒のクエリを投げても、そのクエリ単体に60秒分の課金がかかるわけではありません。ウェアハウスが動いている以上、クエリを投げても投げなくても課金額は変わりません。
ポイントの整理
60秒最低課金は「ウェアハウスの起動（リジューム）イベント」に対して適用されるものであり、「個々のクエリの実行時間」に対して適用されるものではありません。
もう一つの誤解：クエリ処理中とアイドル時の課金レートは同じ
「クエリを処理しているときは多くクレジットが消費され、アイドル時は少ないのでは？」と考える方もいますが、これも誤解です。
ウェアハウスが稼働中であれば、作業の有無に関係なく一定のレートでクレジットが消費されます。これはSnowflakeがコンピュートリソースを「確保（プロビジョニング）」する仕組みを採っているためです。
ウェアハウスサイズ別のクレジット消費量（Standard Warehouse）
| サイズ | クレジット/時 | 1秒あたり | 1分あたり |
|---|---|---|---|
| X-Small | 1 | 0.000278 | 0.0167 |
| Small | 2 | 0.000556 | 0.0333 |
| Medium | 4 | 0.00111 | 0.0667 |
| Large | 8 | 0.00222 | 0.133 |
| X-Large | 16 | 0.00444 | 0.267 |
| 2X-Large | 32 | 0.00889 | 0.533 |
補足: Gen2ウェアハウスの場合、AWS/GCPではX-Smallが1.35クレジット/時、Azureでは1.25クレジット/時と、若干異なるレートが適用されます。
東京リージョンの実際のクレジット金額
Snowflakeのクレジット単価は、エディション・クラウドプロバイダー・リージョンによって異なります。以下は**Snowflake Service Consumption Table（2026年2月6日時点）**に基づく、東京リージョンのオンデマンド価格です。
東京リージョンのクレジット単価（オンデマンド）
| エディション | AWS（東京） | Azure（東京） |
|---|---|---|
| Standard | $2.85 | $2.85 |
| Enterprise | $4.30 | $4.30 |
| Business Critical | $5.70 | $5.70 |
| VPS | $8.55 | $8.55 |
参考として、USリージョン（Virginia/Oregon）のStandardは$2.00、Enterpriseは$3.00ですので、東京リージョンはUSと比較して約40%割高です。
東京リージョンでのウェアハウス時間単価（Enterprise Edition）
1クレジット = $4.30で計算すると以下のようになります。
| サイズ | クレジット/時 | 時間単価 | 1分あたり | 60秒最低課金額 |
|---|---|---|---|---|
| X-Small | 1 | $4.30 | $0.072 | $0.072 |
| Small | 2 | $8.60 | $0.143 | $0.143 |
| Medium | 4 | $17.20 | $0.287 | $0.287 |
| Large | 8 | $34.40 | $0.573 | $0.573 |
| X-Large | 16 | $68.80 | $1.147 | $1.147 |
| 2X-Large | 32 | $137.60 | $2.293 | $2.293 |
ストレージ単価（東京リージョン）
| 項目 | オンデマンド | Capacity（Tier 1） |
|---|---|---|
| Standard Storage | $25.00/TB/月 | $25.00/TB/月 |
auto-suspendの設定とコスト最適化
短いauto-suspend vs 長いauto-suspend
auto-suspendの設定は、2つの相反するコストのバランスで考える必要があります。
auto-suspendが短い場合（例：1分）
- アイドル時の無駄な課金を削減できる
- ただし、クエリが断続的に来ると頻繁にサスペンド→リジュームが発生し、60秒最低課金が何度もかかる
auto-suspendが長い場合（例：30分）
- リジュームの回数が減り、60秒最低課金の発生頻度が下がる
- ただし、クエリがない間もウェアハウスが稼働し続けるため、アイドル課金が発生する
具体的なシミュレーション
東京リージョン、Enterprise Edition、Smallウェアハウス（$8.60/時）で、1時間あたり10分間隔でクエリが来るケースを考えます。
パターンA：auto-suspend = 1分
各クエリの後にサスペンドが発生し、次のクエリで再度リジュームします。
- リジューム回数：6回/時
- 各リジューム時の課金：60秒 × $8.60/3600 = $0.143
- クエリ実行時間（仮に各10秒）の課金は60秒最低に含まれる
- 合計：約 $0.86/時
パターンB：auto-suspend = 10分
ウェアハウスはほぼ稼働し続けます。
- 稼働時間：ほぼ60分/時
- 合計：約 $8.60/時
パターンC：auto-suspend = 5分
クエリ間隔が10分なので、各クエリの後5分でサスペンドし、5分後に再びリジュームします。
- 稼働時間：各回約5分（300秒）× 6回 = 1,800秒 = 30分
- リジューム回数：6回（60秒最低課金は300秒の稼働に含まれる）
- 合計：約 $4.30/時
| パターン | auto-suspend | 概算コスト/時 |
|---|---|---|
| A | 1分 | $0.86 |
| C | 5分 | $4.30 |
| B | 10分 | $8.60 |
この例ではauto-suspend 1分が最もコスト効率が良い結果になりました。
ただし、クエリ間隔が1〜2分程度の場合は状況が逆転します。auto-suspend 1分だと毎回リジュームが発生し、60秒最低課金が積み重なるため、ウェアハウスを稼働させ続けたほうが安くなります。
判断の目安
最適なauto-suspendの値は以下の比較で決まります。
「60秒最低課金 × リジューム回数」 vs 「アイドル時間 × 秒単位課金」
- クエリ間隔 > auto-suspend + 60秒 → 短いauto-suspendが有利
- クエリ間隔 < 2分 → auto-suspendを長めにするか、常時稼働が有利
- クエリが不規則 → ワークロードを分析して最適値を見つける
まとめ
Snowflakeのコンピュート課金で押さえるべきポイントは以下の通りです。
- 60秒最低課金はウェアハウスの起動（リジューム）に対して適用される。個々のクエリに対してではない。
- ウェアハウスが稼働中であれば、クエリ処理中もアイドル時も同じレートで課金される。サスペンド中は課金なし。
- 東京リージョンのクレジット単価はUSリージョンの約1.4倍。Enterprise Editionで$4.30/クレジット（2026年2月時点）。
- auto-suspendの最適値はワークロードのクエリ間隔に依存する。一律に「短い方がいい」「長い方がいい」とは言えない。
コスト最適化のためには、自社のワークロードパターンを分析し、ウェアハウスごとに適切なauto-suspend値を設定することが重要です。Snowflakeの WAREHOUSE_METERING_HISTORY ビューなどを活用して、実際の稼働パターンを可視化することから始めてみてください。
参考情報