Explanation
Why the waste happens and who it affects.
Its usage is free only up to 10% of the account's daily virtual warehouse usage; anything above that line is billed. Some operations run almost entirely in cloud services with little or no warehouse time behind them, so workloads dominated by them push an account over the threshold and start paying for cloud services directly.
Snowflake's own guidance names the usual causes: COPY commands that list large numbers of files because stage paths are not selective, frequent DDL and cloning of whole schemas or databases, tools that send tens of thousands of trivial queries such as SELECT 1 a day, heavy polling of INFORMATION_SCHEMA views and SHOW commands by BI, catalog and orchestration tools, single-row inserts and one-schema-per-customer designs, and very complex SQL with long compilation times. These patterns often come from connector, framework or tool defaults, and they are easy to miss because the charge appears as a separate cloud services line rather than against any one warehouse.
Billing model
The pricing dimensions that drive this cost.
- Cloud services credits
- Credits consumed by the cloud services layer, billed at 4.4 credits per hour of cloud services use per the Snowflake Service Consumption Table
- Cloud services adjustment
- Daily cloud services usage is not charged up to 10% of daily virtual warehouse credits, calculated per day in UTC; only the excess is billed
- Serverless exclusion
- Cloud services used by serverless features and Snowpark Container Services compute do not count toward the 10% adjustment, so accounts with little warehouse time get a small allowance
- Reported in METERING_DAILY_HISTORY
- CREDITS_USED_CLOUD_SERVICES shows usage, CREDITS_ADJUSTMENT_CLOUD_SERVICES shows the negative adjustment, and CREDITS_BILLED shows what was actually charged
How to detect
5 checks to find it in your estate.
- Query SNOWFLAKE.ACCOUNT_USAGE.METERING_DAILY_HISTORY and find days where CREDITS_USED_CLOUD_SERVICES plus CREDITS_ADJUSTMENT_CLOUD_SERVICES is above zero, meaning cloud services were billed beyond the 10% allowance
- Group SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY by QUERY_TYPE and sum CREDITS_USED_CLOUD_SERVICES to see which statement types (COPY, SHOW, DESCRIBE, CREATE_TABLE_AS_SELECT, clones, simple SELECTs) drive usage, as in Snowflake's Exploring compute cost examples
- Break the same query history down by USER_NAME, ROLE_NAME and CLIENT_APPLICATION_ID to attribute high-frequency SHOW, INFORMATION_SCHEMA and SELECT 1 traffic to specific tools or service accounts
- For COPY statements with high cloud services credits, compare LIST_EXTERNAL_FILES_TIME with execution time to confirm that file listing on the stage path is the cost driver
- Use WAREHOUSE_METERING_HISTORY to find warehouses whose CREDITS_USED_CLOUD_SERVICES is high relative to CREDITS_USED, which Snowflake describes as warehouses not using enough warehouse time to cover the cloud services portion
How to fix
6 ways to remove the waste.
- Restructure stage paths with date or other selective prefixes and narrow COPY file patterns so each load lists only the files it needs
- Clone individual tables rather than entire schemas or databases, and run cloning and other DDL only as often as the workflow requires
- Reduce polling frequency of BI, catalog and monitoring tools, ask vendors whose JDBC-based tools send keep-alive queries to use the getSessionId() method, which Snowflake says reduces cloud services usage through caching
- Replace frequent INFORMATION_SCHEMA queries with ACCOUNT_USAGE views, which run on a warehouse instead of cloud services, accepting their data latency
- Batch or bulk-load data instead of single-row inserts, and consider consolidating one-schema-per-customer designs into a shared schema
- Review very complex statements with long compilation times, such as those with extensive joins or large IN lists, and simplify them where the logic allows
Documentation
Vendor references for pricing and configuration.