なぜ重要か
従来のコスト異常検知はアカウント全体またはorganization全体が対象で、単一チームやプロジェクト内の急増を把握しにくい場合がありました。anomaly monitorsではタグとサービス種別で監視範囲を分け、監視対象ごとの通知先を設定できます。Per-user quotasでは、ユーザー単位の利用制御とAI機能へのアクセスブロックを実施でき、設定変更の反映時間も従来の最大15分から約5〜10分に短縮されました。
対象となるチーム
- FinOps・コスト管理担当者
- SnowflakeのQuota admin・アカウント管理者
- データ基盤・プラットフォーム運用チーム
- 部門別・プロジェクト別の予算管理者
提供条件
- Per-user quotas：General Availability
- anomaly monitors：Public Preview
- エディション・リージョンの提供条件：リリースノートに記載なし
- anomaly monitorsは1アカウントあたり最大20モニター
- 10.29リリース完了予定日は2026年8月18日で、変更の可能性あり
ユースケース
- ユーザーごとに月次または日次のcredit上限を設定し、利用量が一定水準に達した時点で通知する。
- AI機能の利用上限に達したユーザーを自動的にブロックし、利用サイクルのリセット時にブロックを解除する。
- タグ付けされた事業部やコストセンターだけを対象に、warehouse computeのコスト異常を監視する。
- 特定プロジェクトのAI credits使用量を個別のanomaly monitorで追跡し、専用の通知先へメールする。
- リソースのタグを変更した後、anomaly monitorを再計算して監視範囲を更新する。
仕組みと使い方
Per-user quotasでは、Quota adminがユーザー全体またはタグで絞り込んだユーザー集合に対して、日次・月次のcredit limit、通知しきい値、AIアクセスのブロック enforcementを設定します。ブロック時のエンドユーザー通知は、次のように第二引数で明示的に有効化します。
SET_BLOCK_ENFORCEMENT_ENABLED(TRUE, TRUE)
通知しきい値は、ADD_NOTIFICATION_THRESHOLDの第4引数に'MONTHLY'または'DAILY'を指定して、月次または日次の上限に紐付けます。ブロック中のユーザーはGET_ACTIVE_BLOCKS_V2()で確認でき、アカウント全体のブロック状況はACCOUNT_USAGE.QUOTA_ACCESS_BLOCK_HISTORYで確認します。anomaly monitorsはSnowsightのCost managementにあるAnomaliesタブ、またはANOMALY_INSIGHTS classから操作します。タグとservice typesでスコープを作成し、creditsまたはAI creditsのどちらを追跡するか選択します。ANOMALY_INSIGHTSには、モニターの作成・更新・参照・削除、通知先管理、保存前の設定テストに対応するメソッドがあります。
導入ステップ
- 10.29のリリース完了状況と、対象アカウントで各機能が利用可能になったことを確認する。
- Per-user quotasで管理対象ユーザー、日次・月次上限、通知しきい値、AIアクセスのブロック方針を整理する。
- 既存のPreview API利用箇所を確認し、GET_ACTIVE_BLOCKS()をGET_ACTIVE_BLOCKS_V2()へ移行する。
- 監視したい部門・プロジェクトのobject tagsとservice typesが適切に設定されているか確認する。
- anomaly monitorsを小さなスコープで作成し、保存前テストと通知先確認を行う。
- タグ変更後や設定変更後に、利用量・ブロック履歴・異常通知が想定どおりになるか検証する。
運用上の注意
- 10.29のリリースノートはPreview版であり、記載された機能や挙動がリリース完了前に利用できない場合があります。
- ブロック enforcementを有効にしても、エンドユーザーへのメール通知はデフォルトで無効になります。通知が必要な場合は第二引数で明示的に有効化してください。
- Quota設定の変更反映には約5〜10分かかるため、設定直後の利用状況だけで反映成否を判断しないでください。
- anomaly monitorsの検知対象はobject tagsとservice typesによるスコープに依存するため、タグの付与・変更状況を運用手順に含める必要があります。
- Preview機能のため、本番の予算統制や自動対応に組み込む前に、通知内容と検知結果を検証してください。
制約事項
- anomaly monitorsはPublic Previewであり、Preview固有の提供条件や将来の仕様変更について、リリースノートに詳細な記載はありません。
- anomaly monitorsは1アカウントあたり最大20個で、各モニターが追跡できるのはcreditsまたはAI creditsのいずれかです。
- エディション、リージョン、必要権限、前提となる有効化設定の詳細は、当該リリースノートに記載されていません。
- GET_PER_USER_USAGE_PREVIEW()とSET_REFRESH_TIER()はGeneral Availabilityで利用できなくなり、Quota評価は全アカウントで数分以内に行われます。
- GET_ACTIVE_BLOCKS()は廃止され、GET_ACTIVE_BLOCKS_V2()に置き換えられています。
次に確認すること
- 公式のPer-user quotasドキュメントで、必要権限、対象エディション、リージョン、SQLシグネチャを確認する。
- 公式のanomaly monitorsドキュメントで、ANOMALY_INSIGHTSの各メソッド、権限、Previewの利用条件を確認する。
- テスト用ユーザーとタグ付きリソースを用意し、上限到達時の通知・AIアクセスブロック・解除動作を検証する。
- 既存のコスト監視とPreviewモニターの検知結果を比較し、導入範囲と運用責任者を決める。
公式情報
仕様・提供条件は更新される可能性があります。導入前に必ず公式リリースノートを確認してください。