Security Features and Their Credit Footprint in Snowflake

1.Where the credits go: four kinds of compute

Before you can judge what a security feature costs, you need to know which bill it lands on. Snowflake splits compute into four categories. Virtual warehouses are managed by you: they run queries and DML, and they cost credits only while they are running. Serverless compute is managed by Snowflake and covers features that don't use your warehouses. Compute pools supply the nodes for Snowpark Container Services. Cloud services is the layer that ties everything together, including logins and security enforcement.

The cloud services layer matters to a security architect because it does the security work on every request. It "authenticates users, enforces security, performs query compilation and optimization". You don't pay for it directly unless it goes over a threshold: cloud services usage is billed only on days when it is more than 10% of that day's warehouse usage.

Serverless features are billed in compute-hours, measured per second. The number of credits per compute-hour depends on the feature, so two serverless features running for the same time can cost different amounts. Each serverless feature also appears as its own line item on the bill. That line item combines the Snowflake-managed compute and the cloud services used by that feature, which is why you can see exactly what a given security feature costs.

Not every charge is a compute-hour charge, though. AI features are billed in AI Credits, and sensitive data classification with AI mode enabled adds token charges for LLM usage on top of its serverless compute charges. That AI-mode cost appears under its own service type, AI_SENSITIVE_DATA_CLASSIFICATION.

One warning about the numbers you query. In METERING_HISTORY, the CREDITS_USED column adds compute and cloud services together *before* the cloud services adjustment. It can therefore show more than you were actually billed.

Sources123

2.Security features that show up as serverless service types

The SERVICE_TYPE column in METERING_HISTORY names each metered service. Several of them are security or governance features, which means you can measure each one's cost separately. The view keeps hourly credit usage for the last 365 days.

The Trust Center is the clearest example, and it shows that the cost of enabling a feature is not all-or-nothing. The Security Essentials scanner package is enabled by default and you can't deactivate it. It runs regularly on a fixed schedule without incurring any serverless compute cost, though any other run incurs incremental charges. The other packages (CIS Benchmarks, Threat Intelligence, and AI Security) are deactivated by default, and the docs say cost can occur from the scanners you enable. The CIS Benchmarks package runs once a day by default, and you can change its schedule. Sensitive data classification works the same way. Once a classification profile is attached to a database, all the tables and views in that database are classified automatically. If you add tag-based masking, new sensitive columns are masked as soon as they are tagged. That is a real security gain, and it bills as SENSITIVE_DATA_CLASSIFICATION. Classifying views can cost more than classifying tables, and views are excluded by default. Serverless alerts and data quality monitoring have their own service types too.

So the decision to enable or disable a feature has several sides. On security, turning off Trust Center scans or classification removes a detection or protection layer. Disabling can also create findings of its own: the CIS Section 2 scanners check that the matching Threat Intelligence or Security Essentials scanner is enabled, and if a required scanner is missing or has not run recently, Trust Center surfaces a Vulnerability finding. On credits, the charge depends on the feature and the settings. Free Security Essentials scans, paid-for optional packages, and the extra token charges of AI-mode classification are different cases. Virtual warehouses are user-managed, so you control their consumption directly. Serverless compute is managed and scaled by Snowflake, so your levers are which features and scanners you enable and how often they run. On operations, these features run without you managing any warehouse. You do need to enable packages with the TRUST_CENTER_ADMIN application role, tune individual scanners and schedules, and watch each additional service type. The Trust Center docs show how to check its cost by filtering on its service type:

SELECT
   SUM(credits_used) AS total_credits
FROM snowflake.account_usage.metering_history
WHERE
   service_type = ' ? ' AND
   start_time >= '2024-12-01' AND
   end_time <= '2024-12-31';

Sources42561

3.Cloud-provider and residency trade-offs

Some security decisions affect cost through the cloud provider, not through the feature itself.

AI routing and data residency. AI features are billed in AI Credits, which are separate from Platform Credits and cost the same in every edition. The price depends on CORTEX_ENABLED_CROSS_REGION. If you allow global routing (for example ANY_REGION or AWS_GLOBAL), an AI Credit costs $2.00. If you choose regional routing (DISABLED, or a regional value such as AWS_EU), it costs $2.20. Keeping AI requests inside a geography to meet residency or compliance rules is a security choice that raises the unit price.

Data movement. Outbound transfers from Snowpark Container Services to other regions or to the internet are charged at the normal outbound data transfer rate. You can see them in the DATA_TRANSFER_HISTORY view in ACCOUNT_USAGE, where the transfer_type column identifies this cost as SNOWPARK_CONTAINER_SERVICES. Where your account runs makes a difference: data transfer is currently not billed for accounts on Google Cloud, so on that cloud these views won't show transfer charges. Compute pools also bill while idle, so Snowpark Container Services is a cost to watch even when no workload is running. Snowflake recommends the AUTO_SUSPEND feature to control it.

Operational overhead of monitoring. Account-level and organization-level cost anomaly detection is always on and needs no configuration, but it needs at least 30 days of consumption before it can identify anomalies. If you want a narrower scope, anomaly monitors (a preview feature) are extra work to maintain. Each monitor tracks one credit family, so covering both traditional and AI consumption takes two monitors. Each has its own verified email notification list and supports email only, and if you retag resources you may need to recalculate the monitor's history.

Notification path. Cost anomaly emails are sent through Snowflake's AWS deployments using Amazon SES, and their content may be kept for up to thirty days. These emails can also include spend details, so pick recipients with the same care you would for any sensitive report.

Sources789

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Security scanning features such as the Trust Center are free because they are part of the platform.Why is that wrong?

   Trust Center scans run on serverless compute and are metered under the TRUST_CENTER service type.

   Covered in Security features that show up as serverless service types

2. 2.AI Credits are priced like Platform Credits, so the price changes with your edition.Why is that wrong?

   AI Credits are a separate unit and cost the same in every edition. Only Platform Credit prices vary by edition and region.

   Covered in Cloud-provider and residency trade-offs