![[新機能]Feature Policy Rules が一般提供となったので TEMPORARY テーブルとサーバーレスタスクの作成だけをブロックしてみた](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-3610e3c1ff5961bdb7b464e17f8bf06d/90b168b240005ead852ec1d474bb74fb/snowflake-logo-1200x630-1.png?w=3840&fm=webp)
[新機能]Feature Policy Rules が一般提供となったので TEMPORARY テーブルとサーバーレスタスクの作成だけをブロックしてみた
かわばたです。
2026年8月16日にFeature Policy Rules が一般提供となりました。
本記事では、rules によるオブジェクト作成の条件付きブロックと、同時に GA となった DESC FEATURE POLICY の出力を検証します。
【公式ドキュメント】
Feature Policy Rules
Feature Policy Rules の概要
Feature Policy は「そのコンテナ内でどのオブジェクトを作成できるか」を制御するガバナンス機能です。適用単位はユーザーやロールではなく、データベース・Personal Database・Native App というコンテナです(アカウントレベルでの一括適用も可能)。
今回の GA で、従来のタイプ単位ブロックに加えて rules による条件付きブロックが書けます。
| 従来: BLOCKED_OBJECT_TYPES_FOR_CREATION | 新: rules (YAML body) | |
|---|---|---|
| 粒度 | オブジェクトタイプ単位の all-or-nothing | リクエスト属性による条件付き |
| 例 | タスクを一切作らせない | サーバーレスタスクだけ禁止 |
| 対象タイプ | TASKS, DATABASES, WAREHOUSES 等 12種 | TABLE, VIEW, STAGE, FUNCTION, PROCEDURE 等に拡大 |
rules はポリシー定義の AS $$ ... $$ に YAML で記述します。block_when の SQL 式が TRUE と評価された作成リクエストがブロックされます。
CREATE FEATURE POLICY <name>
[ BLOCKED_OBJECT_TYPES_FOR_CREATION = ( <type> [ , ... ] ) ]
AS $$
blocked_creation_rules:
- object_type: <OBJECT_TYPE>
block_when: "<SQL式>"
$$;
式の中では SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', '<プロパティ>') で作成リクエストの属性を参照します。プロパティは IS_TEMPORARY / IS_TRANSIENT / WAREHOUSE / EXTERNAL_VOLUME / DATABASE / SCHEMA の6種類で、戻り値はすべて文字列です(Boolean 系は = 'TRUE' と比較します)。
前提条件
- ポリシー作成: ポリシー格納先スキーマへの
CREATE FEATURE POLICY権限 - ポリシー適用: アカウントへの
APPLY FEATURE POLICY権限と、適用する Feature Policy へのAPPLYまたはOWNERSHIP権限 - エディション要件はドキュメントに明記されていません(トライアルアカウントで動作を確認済み)
検証は2026年8月21日および23日(日本時間)に AWS 東京リージョンのアカウントで実施しています。ロールはすべて ACCOUNTADMIN です。
事前準備
ポリシー格納用 DB と適用対象 DB を作成します。
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE DATABASE FP_POLICY_DB; -- ポリシー格納用
CREATE SCHEMA FP_POLICY_DB.POLICIES;
CREATE OR REPLACE DATABASE FP_TEST_DB; -- 適用対象
CREATE OR REPLACE DATABASE FP_TEST_DB2; -- 優先順位検証用
試してみた
従来型: タイプ単位の all-or-nothing
比較のため、まず従来の BLOCKED_OBJECT_TYPES_FOR_CREATION でタスク作成を禁止します。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TASKS_ALL
BLOCKED_OBJECT_TYPES_FOR_CREATION = (TASKS)
COMMENT = 'Block all task creation (legacy style)';
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TASKS_ALL;
ウェアハウス指定タスクを作成してみます。
CREATE TASK FP_TEST_DB.PUBLIC.T_WH
WAREHOUSE = COMPUTE_WH SCHEDULE = '60 MINUTE' AS SELECT 1;

サーバーレスタスク(WAREHOUSE 指定なし)も同じエラーでブロックされ、テーブル作成は成功しました。タイプ単位のためタスクは全部か無かの制御になります。
注目すべきは、ACCOUNTADMIN でもブロックされる点です。Feature Policy はロールではなく DB というコンテナに効くため、管理者の操作も例外になりません。
次の検証のため解除しておきます。
ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
rules: TEMPORARY テーブルだけブロックできる
GA の本命である rules を試します。IS_TEMPORARY プロパティを条件に、TEMPORARY テーブルの作成だけを禁止します。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES
COMMENT = 'Block only temporary tables'
AS $$
blocked_creation_rules:
- object_type: TABLE
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'IS_TEMPORARY') = 'TRUE'"
$$;
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES;

3種類のテーブルを作成した結果です。
CREATE TABLE FP_TEST_DB.PUBLIC.T2 (ID INT); -- 成功
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T3 (ID INT); -- ブロック (003001)
CREATE TRANSIENT TABLE FP_TEST_DB.PUBLIC.T4 (ID INT); -- 成功



TEMPORARY だけがブロックされました。TRANSIENT は IS_TEMPORARY に該当しないため成功します(TRANSIENT も止めるなら IS_TRANSIENT の条件を追加します)。従来型では不可能だった「テーブルは許可、ただし一時テーブルだけ禁止」が実現できています。
rules: サーバーレスタスクだけブロックできる
タスクの WAREHOUSE プロパティは、ウェアハウス指定がないサーバーレスタスクで NULL になります。これを条件にすると、コスト統制の定番要望「サーバーレスタスクだけ禁止」を実装できます。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS
COMMENT = 'Block only serverless tasks'
AS $$
blocked_creation_rules:
- object_type: TASK
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') IS NULL"
$$;
適用しようとしたところ、エラーになりました。
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS;

1つのデータベースに直接バインドできる Feature Policy は1つです。既存の DB レベルポリシーがある状態で FORCE を付けずに SET するとエラーになります。今回は FORCE を指定して直接置き換えます。
-- FORCE で既存の DB レベルポリシーを直接置き換える
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS
FORCE;

タスクを2パターン作成した結果です。
-- ウェアハウス指定タスク → 成功
CREATE TASK FP_TEST_DB.PUBLIC.T_WH
WAREHOUSE = COMPUTE_WH SCHEDULE = '60 MINUTE' AS SELECT 1;
-- サーバーレスタスク → ブロック (003001)
CREATE TASK FP_TEST_DB.PUBLIC.T_SERVERLESS
SCHEDULE = '60 MINUTE' AS SELECT 1;


狙いどおり、ウェアハウス指定タスクは作成でき、サーバーレスタスクだけがブロックされました。
名前付き条件で複数タイプに同じ条件を使い回せる
conditions で名前を付けた式は、block_when_any で複数のルールから参照できます。従来型パラメータとの併用も可能です。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH
COMMENT = 'Named condition + legacy param combined'
BLOCKED_OBJECT_TYPES_FOR_CREATION = (WAREHOUSES)
AS $$
conditions:
- name: is_temp
expression: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'IS_TEMPORARY') = 'TRUE'"
blocked_creation_rules:
- object_type: TABLE
block_when_any:
- is_temp
- object_type: STAGE
block_when_any:
- is_temp
$$;
ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T6 (ID INT); -- ブロック
CREATE TEMPORARY STAGE FP_TEST_DB.PUBLIC.S_TEMP; -- ブロック (Create STAGE denied)
CREATE STAGE FP_TEST_DB.PUBLIC.S1; -- 成功



テーブル・ステージの両方で TEMPORARY だけがブロックされました。一方、併用した WAREHOUSES は効きませんでした。
CREATE WAREHOUSE FP_TEST_WH WITH WAREHOUSE_SIZE = 'XSMALL' INITIALLY_SUSPENDED = TRUE;

ウェアハウスはアカウントレベルオブジェクトで、作成は DB コンテナの外の操作です。そのため DB にバインドしたポリシーでは制御されません。ドキュメントでも、アカウントレベルオブジェクトタイプは Native App にバインドした場合のみ有効とされています。
DESC FEATURE POLICY: policy_definition に YAML が表示される
同時に GA となった DESC FEATURE POLICY で rules を確認します。
DESC FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS;

policy_definition プロパティに、設定した YAML のポリシー定義が表示されます。今回の検証環境では、rules を持たないポリシーを DESC すると policy_definition 行自体が表示されませんでした。
適用状況の確認には SHOW と POLICY_REFERENCES を使います。IN は「その場所に作成されたポリシー」、ON は「適用されているポリシー」で、ON の結果には適用先を示す set_on カラムが付きます。
SHOW FEATURE POLICIES IN DATABASE FP_POLICY_DB; -- 作成した4ポリシーが一覧表示
SHOW FEATURE POLICIES ON DATABASE FP_TEST_DB; -- 適用中の1ポリシーのみ (set_on = DATABASE)
SELECT POLICY_NAME, POLICY_KIND, REF_ENTITY_NAME, REF_ENTITY_DOMAIN, POLICY_STATUS
FROM TABLE(FP_POLICY_DB.INFORMATION_SCHEMA.POLICY_REFERENCES(
POLICY_NAME => 'FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH'));

適用の優先順位を確認する
通常のデータベースでは、DB レベルのポリシーがアカウントレベル(FOR ALL DATABASES)のポリシーより優先されます。アカウント全体を縛りつつ、特定 DB だけ空ポリシーで制限解除する公式記載のテクニックを試します。
ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
-- アカウント内のすべての通常の DB に TEMPORARY テーブル禁止を適用
ALTER ACCOUNT
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES FOR ALL DATABASES;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T8 (ID INT);

FP_TEST_DB2 でも同じエラーになりました。DB 適用時とはメッセージが異なり、アカウントポリシー起因であることと確認コマンドが示されます。
次に「何もブロックしない」空ポリシーを作成し、FP_TEST_DB にだけ適用します。空リスト () で作成できました。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_NOTHING
BLOCKED_OBJECT_TYPES_FOR_CREATION = ()
COMMENT = 'Empty policy to lift account-level restrictions';
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_NOTHING;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T8 (ID INT); -- 成功
CREATE TEMPORARY TABLE FP_TEST_DB2.PUBLIC.T9 (ID INT); -- 引き続きブロック


DB レベルの空ポリシーがアカウントレベルより優先され、FP_TEST_DB だけ制限が解除されました。なお今回の検証環境では、アカウント適用中に SHOW FEATURE POLICIES ON ACCOUNT の options カラムへ {"target_scopes":["ALL_DATABASES"]} が表示されました。
検証後はアカウントレベルの適用を解除します。
ALTER ACCOUNT UNSET FEATURE POLICY FOR ALL DATABASES;
つまずいたところ
評価できない式は作成時に拒否される
WAREHOUSE プロパティは TASK 以外の作成リクエストでは常に NULL です。これを TABLE のルールで等価比較すると、実行時ではなくポリシー作成時に拒否されました。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.NULL_TRAP2
AS $$
blocked_creation_rules:
- object_type: TABLE
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') = 'COMPUTE_WH'"
$$;

object_type: ALL でも同じエラーです。対象タイプで評価しようがない式は作成段階で弾かれます。
NULL 評価は fail-closed でブロックされる
作成時バリデーションを通った式でも、実行時に NULL と評価されるケースがあります。TASK に WAREHOUSE = 'COMPUTE_WH' の条件を付けてサーバーレスタスクを作成すると、NULL = 'COMPUTE_WH' は NULL になります。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.NULL_TRAP3
AS $$
blocked_creation_rules:
- object_type: TASK
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') = 'COMPUTE_WH'"
$$;
-- (FP_TEST_DB に適用後)
CREATE TASK FP_TEST_DB.PUBLIC.T_B SCHEDULE = '60 MINUTE' AS SELECT 1;

FALSE のときだけ許可、TRUE と NULL はブロックという fail-closed の挙動で、NULL の場合は専用のエラーメッセージになります。実際に COMPUTE_WH 指定(TRUE)はブロック、別ウェアハウス指定(FALSE)は成功でした。「条件に該当しなければ許可されるはず」という感覚で書くと、NULL の分岐で意図せずブロックされるため注意が必要です。
制限事項・注意点
制限事項・注意点
- バインド中のポリシーは
CREATE OR REPLACE/DROPできません。変更はALTER FEATURE POLICYを使い、削除は先に適用を解除します - ポリシー定義に
CLONE句は使えません - rules の式でテーブル等の DB オブジェクトや副作用のある関数は参照できません
- アカウントレベルのポリシー参照をレプリケーションする場合、ポリシーの格納 DB をレプリケーショングループに含めないと適用先で強制されません
最後に
Feature Policy Rules により、オブジェクト作成の制御が「タイプ丸ごと」から「条件付き」に進化しました。サーバーレスタスクや一時テーブルだけの禁止など、コスト統制・ガバナンスの実用的なポリシーを ACCOUNTADMIN 含む全ユーザーに強制できます。NULL 評価が fail-closed でブロックになる点だけは、ポリシー設計時に注意してください。
この記事が何かの参考になれば幸いです!





