Explanation
Why the waste happens and who it affects.
A pool is billed for its nodes whenever it is in the IDLE, ACTIVE, STOPPING or RESIZING state, and only stops billing when it is SUSPENDED. A pool can only auto-suspend when no services and no jobs are running on any of its nodes, so a single long-running service that nobody calls keeps the whole pool, and at least MIN_NODES nodes, billing around the clock.
Typical cases are pools created for experiments, demos, notebooks and internal apps that are used a few hours a week. Services do not auto-suspend by default (a service's AUTO_SUSPEND_SECS defaults to 0), so a forgotten service pins its pool active. Pools are also created with AUTO_SUSPEND_SECS set to 0, which disables automatic suspension, or with MIN_NODES higher than the steady workload needs, and GPU pools make any idle time especially expensive. Snowflake's SPCS cost guidance recommends using AUTO_SUSPEND to manage these charges.
Billing model
The pricing dimensions that drive this cost.
- Compute pool node credits
- Each node consumes Platform Credits per hour at the rate for its instance family, charged per second while the pool is IDLE, ACTIVE, STOPPING or RESIZING
- Node start minimum
- The Service Consumption Table applies a minimum of five minutes of credits each time a compute node is started or resumed
- Suspended pool
- No compute charges while the pool is STARTING or SUSPENDED; storage for images, volumes and logs is billed separately
- Data transfer
- Outbound and internal transfer for SPCS is billed at rates in the Service Consumption Table, except for accounts on Google Cloud where it is currently not billed
How to detect
5 checks to find it in your estate.
- Run SHOW COMPUTE POOLS and review state, num_services, num_jobs, active_nodes, idle_nodes, min_nodes and auto_suspend_secs; flag pools that are ACTIVE or IDLE with no workloads, pools with auto_suspend_secs = 0, and pools with idle nodes above need
- Query SNOWFLAKE.ACCOUNT_USAGE.SNOWPARK_CONTAINER_SERVICES_HISTORY (hourly CREDITS_USED per COMPUTE_POOL_NAME) to find pools billing continuously, including nights and weekends
- Run SHOW SERVICES IN COMPUTE POOL <name> for pools that never suspend and identify services with no recent callers, checking their auto_suspend_secs, which defaults to 0
- Check METERING_HISTORY where SERVICE_TYPE = 'SNOWPARK_CONTAINER_SERVICES' to track total SPCS spend over time and spot pools that outlived their project
- Separate pools created by Native Apps (IS_EXCLUSIVE and APPLICATION_NAME in the history view) and review them with the app owner
How to fix
5 ways to remove the waste.
- Drop services and pools that are no longer used (DROP SERVICE, then DROP COMPUTE POOL), or use ALTER COMPUTE POOL ... STOP ALL to drop all services and cancel jobs in a pool before removing it
- Set AUTO_SUSPEND_SECS on services with intermittent use (minimum 300 seconds, counted as no queries invoking a service function) with AUTO_RESUME left TRUE, so idle services release the pool; expect start-up latency on the first request after a suspend
- Keep a non-zero AUTO_SUSPEND_SECS on every compute pool (ALTER COMPUTE POOL ... SET AUTO_SUSPEND_SECS = <seconds>; the default for new pools is 3600) so the pool suspends once no services or jobs are running
- Suspend pools during known idle periods with ALTER COMPUTE POOL ... SUSPEND, which suspends all services in the pool while jobs run to completion, and RESUME before use
- Lower MIN_NODES to what the steady workload needs and let MAX_NODES absorb peaks, and pick the smallest instance family that fits, reserving GPU families for workloads that need them
Documentation
Vendor references for pricing and configuration.