What you will be able to do
- Calculate warehouse credit consumption from size, runtime, the 60-second minimum and resize events
- Measure and reduce warehouse idle time with auto-suspend, auto-resume and query attribution
- Limit warehouse spending with privileges and statement timeouts
- Configure budgets, including refresh tiers and tag-based backfill, and contrast them with resource monitors
1.Calculating warehouse credit consumption
Virtual warehouses are the compute cost you control directly. A warehouse's credits depend on three things: its size, how long it runs, and how many warehouses (or clusters) you run. Each size up roughly doubles both compute power and credits per hour. For example, a Small warehouse costs 2 credits per hour and a Medium costs 4. A suspended warehouse uses no credits at all.
| Event | What is billed |
|---|---|
| Warehouse starts or resumes | 1 minute at the hourly rate for its size |
| Warehouse keeps running after the first minute | Per second, for as long as it runs without stopping |
| Resize to a larger size | 1 minute, but only for the added compute (Small to Medium = 1 minute of 2 extra credits/hour) |
| Resize from 5X-Large or 6X-Large to 4X-Large or smaller | Briefly both old and new resources, while the old resources are quiesced |
| Warehouse suspended | Nothing |
Calculation: a Medium warehouse (4 credits per hour) that runs for 90 seconds uses 4 × 90 / 3600 = 0.1 credits. If it runs for only 20 seconds, it is still billed for 60 seconds, which is 4 / 60 ≈ 0.067 credits. So short bursts of work separated by suspends cost more than the same work done in one continuous run.
Checkpoint 1 of 7· Exam question
During an incident, an administrator must list the queries that ran on a warehouse in the last 20 minutes, and the result must be complete with no ingestion delay. Which source should be used?
Correct answer: D — The INFORMATION_SCHEMA.QUERY_HISTORY table function, filtered by warehouse name and an end-time range
- A. ACCOUNT_USAGE views lag behind real time, with QUERY_HISTORY delayed by up to roughly 45 minutes. Queries from the last 20 minutes may be missing.
- B. This view reports credit consumption by warehouse across the organization, not individual queries. It also arrives with a delay of hours.
- C. This view records warehouse events such as resume, suspend and resize, not individual query records. It is also subject to ACCOUNT_USAGE latency.
- D. The INFORMATION_SCHEMA table functions return results in real time with no latency, which suits a very recent window. They only cover a short recent period, which is fine here.
Checkpoint 2 of 7· Check yourself
A running Small warehouse (2 credits/hour) is resized to Medium (4 credits/hour). What does the resize itself add to the bill?
Upsizing is billed for a 1-minute minimum, but only for the extra compute added. Going from 2 to 4 credits/hour means 1 minute of the 2-credit difference.
“resizing from Small (2 credits/hour) to Medium (4 credits/hour) results in billing charges for 1 minute’s worth of 2 additional credits”Source: docs.snowflake.com
Sources1
2.Idle time, auto-suspend and auto-resume
Serverless features charge only for the time they spend working. A user-managed warehouse is different: it consumes credits the whole time it is running, whether or not it is executing a query. That idle time is the cost to target.
To measure idle time, compare two Account Usage views. WAREHOUSE_METERING_HISTORY gives the credits each warehouse actually used per hour. QUERY_ATTRIBUTION_HISTORY assigns credits to individual queries in CREDITS_ATTRIBUTED_COMPUTE, and that column covers query execution only, not idle time. So the gap between a warehouse's metered credits and the credits attributed to its queries shows roughly how much you are paying for idle time. QUERY_ATTRIBUTION_HISTORY has latency of up to eight hours, so leave recent hours out of the comparison.
To reduce idle time, rely on auto-suspend. All warehouses have it enabled by default, so a warehouse shuts down after a set period without activity. Pair it with auto-resume, so the warehouse stops and starts automatically as its workload changes. Suspend too eagerly, though, and the 60-second minimum on every resume eats into the savings. Set the suspend delay for how the workload actually behaves. The exam guide also mentions WAREHOUSE_MONITORING for cost optimization, but these sources don't document it, so this lesson doesn't describe it.
Anyone with the MODIFY privilege can turn off auto-suspend, so check for it regularly:
Checkpoint 3 of 7· Fill the gap
Which column completes this check for warehouses that have auto-suspend turned off?
SHOW WAREHOUSES
->> SELECT "name" AS WAREHOUSE_NAME,
"size" AS WAREHOUSE_SIZE
FROM $1
WHERE IFNULL(" ? ", 0) = 0;A warehouse with auto-suspend turned off shows a null or 0 auto_suspend value, so the query filters on that column. The auto-resume check instead compares "auto_resume" to 'false'.
Source: docs.snowflake.com3.Cost-saving controls: privileges and timeouts
Many cost overruns come from people changing a warehouse's configuration, so access control is a cost control too. Three privileges matter:
- CREATE WAREHOUSE (account level): decides who can create new warehouses, which keeps users on warehouses that already have controls in place. - MODIFY: allows resizing a warehouse and turning off auto-suspend. A common mistake is upsizing a warehouse for one job and never sizing it back down. - USAGE: decides who can run work on a warehouse.
Best practice is to give warehouse creation and scaling to a dedicated role held by a few people. If users need more capacity, a multi-cluster warehouse scales automatically, so nobody has to remember to resize it.
Timeouts stop wasted runtime. STATEMENT_TIMEOUT_IN_SECONDS cancels runaway statements. STATEMENT_QUEUED_TIMEOUT_IN_SECONDS cancels statements that have waited in the queue too long. Queued statements use no credits, but running a result that is no longer needed wastes them. You can set both parameters for the account, a user, a session or a warehouse. When a warehouse value and a session value are both set, the lowest non-zero value applies. None of these controls affect cloud services or serverless features.
ALTER ACCOUNT SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER USER <username> SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER SESSION SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER WAREHOUSE <warehouse_name> SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;Checkpoint 4 of 7· Check yourself
Analysts keep upsizing a shared warehouse for one-off jobs and leaving it large. They still need to run queries on it. Which privilege should you take away from them?
MODIFY is the privilege that allows resizing and turning off auto-suspend. Removing it while keeping USAGE lets analysts run queries without changing the warehouse's cost settings.
“allows changing the settings that affect cost, including resizing a warehouse and disabling the auto-suspend setting”Source: docs.snowflake.com
Sources3
4.Using budgets to monitor warehouse and serverless spending
Timeouts and privileges only cover warehouses. Budgets cover compute spending across the account, including serverless features. A budget sets a monthly spending limit in credits for the whole account (the account budget) or for a custom group of objects. When spending is forecast to go over the limit, it sends a daily alert to email addresses, a cloud queue (Amazon SNS, Azure Event Grid, Google Cloud PubSub) or a webhook (for example, Slack, Microsoft Teams or PagerDuty).
| Aspect | Budget | Resource monitor |
|---|---|---|
| What it covers | All supported objects and serverless features in the account, or a custom group | User-managed virtual warehouses only |
| Reset period | Monthly | Monthly or a custom schedule |
| Response | Notification when usage is forecast to exceed the limit | Email at up to five thresholds, optionally suspending the warehouse |
Budgets have several mechanics you need to know.
- Setup. To start using budgets, activate the account budget. Each budget needs a spending limit and a way to send notifications. - Monthly cycle. The cycle runs from 12:00 AM UTC on the first of the month to the last day of the month. - Limits alert; they don't block. The spending limit is used only for alerts and notifications. To take action, attach stored procedures that run when a threshold is reached or when the cycle restarts. These procedures can suspend warehouses, send notifications or log events to a table. - Backfill when created mid-month. An account budget activated mid-month backfills data from the start of the month. A custom budget backfills only resources added by tag. Resources added individually are forecast only from the day they were added, so the first month's forecast may be off. - Refresh interval. By default a budget refreshes up to every 6.5 hours. A low latency budget refreshes every hour, but its own compute cost is 12 times higher. Use SET_REFRESH_TIER to change it and GET_REFRESH_TIER to read it. - Coverage. Services tracked include AUTO_CLUSTERING, MATERIALIZED_VIEW, PIPE, QUERY_ACCELERATION, REPLICATION, SEARCH_OPTIMIZATION, SERVERLESS_TASK, SNOWPARK_CONTAINER_SERVICES, AI_SERVICES and WAREHOUSE_METERING. - Access. BUDGET_VIEWER and BUDGET_ADMIN control the account budget. Each custom budget has VIEWER and ADMIN instance roles.
Checkpoint 5 of 7· Exam question
An administrator compares the SNOWFLAKE.ACCOUNT_USAGE views with the INFORMATION_SCHEMA views and table functions of a database. Select TWO statements that are accurate.(Select 2)
Correct answers: D, E — ACCOUNT_USAGE views keep 365 days of history and include records for objects that have since been dropped; ACCOUNT_USAGE views have ingestion latency, ranging from around 45 minutes up to several hours depending on the view
- A. INFORMATION_SCHEMA is scoped to a single database, so it describes only that database's objects. It cannot be used for account-wide totals.
- B. The INFORMATION_SCHEMA query history functions only look back a matter of days, not a year. Longer lookbacks require ACCOUNT_USAGE.
- C. ACCOUNT_USAGE is not real time and lags by minutes to hours. INFORMATION_SCHEMA is the lower-latency option for live checks.
- D. ACCOUNT_USAGE retains most history for one year and still shows dropped objects. That makes it the source for long-range audits and cost trends.
- E. ACCOUNT_USAGE data is loaded after the fact, so recent events may not yet appear. The exact delay differs from view to view.
Checkpoint 6 of 7· Check yourself
A budget costs 1 credit per month at the default refresh interval. During a cost incident you switch it to a low latency budget for the full month. What will the budget itself cost that month?
A one-hour refresh interval multiplies the budget's compute cost by 12. That is why Snowflake suggests lowering the interval only temporarily.
“Setting the refresh interval to one hour increases the compute cost of the budget by a factor of 12.”Source: docs.snowflake.com
Checkpoint 7 of 7· Check yourself
On the 15th you create a custom budget for one department. Which way of adding its warehouses lets the forecast use spending from the 1st through the 14th?
For custom budgets, only resources added by tag get the month's earlier data backfilled. Resources added individually are forecast only from the days after the budget is created.
“historical data for the month is only backfilled for resources that were added to the budget using a tag”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A budget stops spending once its limit is reached.Why is that wrong?
A budget's limit only triggers alerts and notifications. To enforce anything, such as suspending warehouses, you must attach stored procedures as custom actions. If you only want to control warehouse spending, a resource monitor can suspend warehouses directly.
Covered in Using budgets to monitor warehouse and serverless spending
2.Because billing is per second, suspending a warehouse as soon as each query finishes always saves money.Why is that wrong?
Each resume brings back the 60-second minimum, so suspending and resuming within a minute means paying for several minimums.
Covered in Calculating warehouse credit consumption
3.Adding up CREDITS_ATTRIBUTED_COMPUTE across all of a warehouse's queries gives its full bill.Why is that wrong?
Attributed credits cover only query execution. Idle time is left out, so the total falls short of the warehouse's metered credits.
Covered in Idle time, auto-suspend and auto-resume
Practise it for real
Audit your warehouses for settings that cause idle or unexpected costs
1.Run SHOW WAREHOUSES ->> SELECT "name", "size" FROM $1 WHERE IFNULL("auto_suspend", 0) = 0;
Why: A warehouse with auto-suspend turned off keeps using credits while it sits idle.
You should see: A list of warehouses with no auto-suspend. Ideally it's empty.
2.Run the same pattern with WHERE "auto_resume" = 'false'.
Why: Every warehouse with auto-suspend should also have auto-resume, so it starts and stops with its workload.
You should see: Warehouses that won't restart on their own when a query arrives.
3.Run the same pattern with WHERE "resource_monitor" = 'null'.
Why: Warehouses without their own resource monitor are exposed to runaway costs, unless an account-level monitor covers them.
You should see: Warehouses that have no warehouse-level credit limit.
4.Fix each finding with ALTER WAREHOUSE using the AUTO_SUSPEND or AUTO_RESUME parameter, or in Snowsight under Compute » Warehouses.
Why: Fixing these settings removes the configurations that make warehouses use credits without doing work.
You should see: Rerunning the queries above returns no rows.
Stuck? Get a nudge
The resource monitor check doesn't consider account-level monitors, so confirm whether the account has one before treating a row as a problem.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“credits are billed per-second, with a 60-second (i.e. 1-minute) minimum”
↩︎ Calculating warehouse credit consumption“Each increase in size to the next larger warehouse approximately doubles the computing power and the number of credits billed per full hour”
↩︎ Calculating warehouse credit consumption“Warehouses are only billed for credit usage while running. When a warehouse is suspended, it does not use any credits.”
↩︎ Calculating warehouse credit consumption“user-managed virtual warehouses consume credits while running, regardless of whether they are performing any work”
↩︎ Idle time, auto-suspend and auto-resume“the 1-minute minimum starts over each time a warehouse is resumed”
↩︎ Exam trap 2“the 1-minute minimum starts over each time a warehouse is resumed”
↩︎ Prediction“resizing from Small (2 credits/hour) to Medium (4 credits/hour) results in billing charges for 1 minute’s worth of 2 additional credits”
↩︎ Checkpoint - 2.
“Includes only the credit usage for the query execution and doesn’t include any warehouse idle time.”
↩︎ Idle time, auto-suspend and auto-resume“Includes only the credit usage for the query execution and doesn’t include any warehouse idle time.”
↩︎ Exam trap 3 - 3.
“every warehouse that has auto-suspend enabled should also have auto-resume enabled”
↩︎ Idle time, auto-suspend and auto-resume“Centralizing the responsibility of creating and scaling warehouses to just a few members of your team is considered a best practice.”
↩︎ Cost-saving controls: privileges and timeouts“SQL statements that are in a queue to use a warehouse do not consume credits.”
↩︎ Cost-saving controls: privileges and timeouts“These controls do not apply to cloud services and serverless features.”
↩︎ Cost-saving controls: privileges and timeouts“allows changing the settings that affect cost, including resizing a warehouse and disabling the auto-suspend setting”
↩︎ Checkpoint - 4.
“Budgets let you control costs for both serverless features and warehouses, while resource monitors focus solely on warehouses.”
↩︎ Using budgets to monitor warehouse and serverless spending - 5.https://docs.snowflake.com/en/user-guide/budgetsOfficial docs
“By default, the budget refresh interval is up to 6.5 hours.”
↩︎ Using budgets to monitor warehouse and serverless spending“Each stored procedure you define can perform actions such as suspending warehouses, sending notifications, or logging events to a table.”
↩︎ Using budgets to monitor warehouse and serverless spending“A budget sends a daily alert notification when current spending is on track to exceed the spending limit based on time-series forecasting.”
↩︎ Using budgets to monitor warehouse and serverless spending“The spending limit is expressed in Snowflake credits and is used for alerting and notification purposes only.”
↩︎ Exam trap 1“Setting the refresh interval to one hour increases the compute cost of the budget by a factor of 12.”
↩︎ Checkpoint“historical data for the month is only backfilled for resources that were added to the budget using a tag”
↩︎ Checkpoint - 6.
“If you are only concerned with controlling the costs of warehouses, you can also use resource monitors to monitor and suspend warehouses.”
↩︎ Using budgets to monitor warehouse and serverless spending