FinOps for Data Cloud Platforms: Practical Scenarios

Transform Theory into Practical Execution

Transitioning from a high-level FinOps scope to operational reality for Data Cloud Platform billing requires moving beyond architectural theory into repeatable, practical execution. The following scenarios assume a greenfield starting point: a Data Cloud Platform that is brand-new out of the box with no existing configuration, naming conventions, or usage patterns in place.

This “blank slate” approach allows practitioners to establish a benchmark for excellence, whether you are building from scratch or performing a gap analysis on a mature, high-spend environment. Each scenario is structured as a practitioner’s blueprint, clearly defining the Business Challenge, the Value Realized, and the Practical Steps required to drive collaboration across Engineering, Finance, and Product personas.

Scenarios include Snowflake-specific configuration steps to demonstrate how FinOps concepts can be applied in practice, including cost visibility, workload attribution, governance, and optimization. This approach avoids limiting the paper to platform-agnostic abstractions while still preserving applicability across the broader Data Cloud Platform landscape. Similar patterns apply to Databricks, Microsoft Fabric, Google BigQuery, Amazon Redshift, and other platforms, although the specific implementation will differ based on each platform’s consumption model, metadata structures, workload execution layer, tagging or labeling mechanisms, and native cost management capabilities.

As your FinOps for Data Cloud Platforms matures, the guidance shifts toward sophisticated scenarios such as Query-Level Anomaly Detection, Storage Lifecycle Management, and ultimately, Unit Economic Modeling for Data Products. This progression ensures that financial accountability is baked into the platform from the very first credit consumed.

Practical Scenarios: Crawl

Platform-Native Cost Management Setup (Understand Usage & Cost)

FinOps Framework Capabilities: Reporting & Analytics

Challenge

Establishing native cost management typically requires navigating complex administrative permissions and security guardrails that are often restricted by default.

For example, in Snowflake, enabling the Cost Management interface specifically requires the ORGADMIN or ACCOUNTADMIN role, which can create significant implementation bottlenecks if these high-level privileges are held by teams outside the immediate FinOps function.

Business Value

Enabling native cost management provides immediate visibility that prevents budget surprises and uncovers “quick win” optimizations, such as zombie resources or oversized warehouses, often within the first 30 days. This foundation establishes the baseline for transparent showback and chargeback, fostering a culture of financial accountability that naturally reduces waste through engineering behavioral change.

High-Level Solution

FinOps Practitioners collaborate with Platform Administrators and Security to secure the elevated permissions required to access sensitive financial metadata.

Following approval, they perform the initial configuration of the native cost management module to activate telemetry for compute, storage, and marketplace consumption.

Snowflake Example: Practical Steps

To activate a complete view of all Snowflake spend, the following steps are performed:

• Elevate Permissions: Sign in to Snowsight and switch to the ORGADMIN (to see all accounts) or ACCOUNTADMIN (for a single account) role.
• Access the Module: Navigate to Admin » Cost Management.
• Assign Metadata Warehouse: Select a small virtual warehouse (e.g., X-Small) to power the metadata queries required to visualize consumption.
• Delegate Access: To allow non-admins to view these dashboards, execute: GRANT DATABASE ROLE SNOWFLAKE.USAGE_VIEWER TO ROLE your_finops_role

What You Can Monitor:

• Spend Breakdown: Toggle between Compute, Storage, and Data Transfer usage.
• Top Cost Drivers: Identify the top 10 most expensive warehouses or databases.
• Contract Burn-down: Track your remaining credit balance against your total commitment.

AI & Cortex Services: Ensure your initial cost management setup includes METERING_HISTORY filtered by SERVICE_TYPE = ‘AI_SERVICES‘ so that Cortex usage is visible alongside compute and storage from the outset

In Snowflake, this means working with the ORGADMIN or ACCOUNTADMIN to enable the Cost Management interface, providing a centralized dashboard for cross-functional spend visibility.

Personas/Roles Involved

• Platform Administrator: enables required permissions and delegate access
• FinOps practitioner: sets up required reports and analytics
• Engineering, Finance, Product and Leadership: consumes reports and insights to take action and improve value and efficiency

Metrics & KPIs

Example set of metrics and KPIs for consideration:

• Data Freshness: The time lag between a resource being consumed and its cost appearing in the dashboard.
  • Example: 24–48 hours.
• Spend Coverage: The percentage of total Data Cloud Platform spend visible in the dashboard.
  • Example: 80% in Month 1; 95%+ by Month 3
• Time to Insight: The duration between a cost anomaly occurring and its detection by a human or system.
  • Example: < 7 Days (Reduction from the traditional 30–45 day invoice cycle).

Cost Drivers

• Unseen Consumption: Lack of visibility allows unmonitored resources to burn credits silently.
• Operational Toil: Manual data reconciliation wastes engineering hours on non-value-add reporting tasks.
• Insight Latency: Delayed detection allows inefficient workloads to persist, missing critical recovery opportunities.
• Data Coverage Gaps: Excluding storage or marketplace fees results in inaccurate Total Cost reporting.
• AI Services (Cortex): Serverless credits consumed by Cortex LLM functions, document processing, search serving, and analyst workloads are billed independently of virtual warehouse credits. Establish visibility into this cost category at the same time as compute and storage, as token-driven costs can scale rapidly with usage and are easy to overlook in initial dashboards.

Data Sources Needed

• Snowflake Cost Management Interface — Centralised dashboard in Snowsight (Admin › Cost Management) for compute, storage, and marketplace consumption visibility.
• SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY — Daily credit consumption by service type; primary source for account-level spend trending and burn-down analysis.
• SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — Hourly credit consumption by warehouse; identifies top cost drivers and idle spend.
• SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE — Daily account-level storage consumption, ensuring storage costs are included in the total spend baseline.
• SNOWFLAKE.ORGANIZATION_USAGE views — Aggregated cross-account spend visibility for multi-account organizations.

Risks to Mitigate

• Telemetry Latency: System metadata delays can cause 24-hour reporting lags in initial visibility.
• Coverage Gaps: Manual exclusions of marketplace or storage fees create inaccurate total spend.
• Access Bottlenecks: Restricted administrative roles can delay visibility for the central FinOps team.
• Granularity Limits: Initial views lack query-level depth, requiring managed expectations for early maturity.
• AI Spend Blind Spot: Organizations that configure cost management visibility for compute and storage only without including AI_SERVICES in their metering baseline will have an incomplete picture of total platform spend from the start.

Dependencies

• Administrative Privileges: Enabling financial telemetry requires high-level Data Cloud Platform administrative permissions for initial setup.
• Metadata Activation: Underlying system logs must be actively toggled to populate native dashboards.
• Compute Resource Allocation: Snowflake for example requires an active warehouse to execute background metadata visualization queries.
• Security Approvals: Internal security teams must authorize visibility into sensitive billing and contracts.

Role Delegation: Establishing a suitable viewer based role permission is necessary for non-admin team accessibility, for example in Snowflake this is Usage_Viewer

Tagging Strategy & Attribution Enablement (Understand Usage & Cost)

FinOps Framework Capabilities: Allocation

Challenge

Snowflake environments often grow organically, with many warehouses, databases, and views owned by different teams, making it hard to know which spend belongs to which product, cost center, or customer. Without a standard tag set and required usage, tags are ad‑hoc, incomplete, or inconsistent; this breaks cost attribution, makes reporting brittle, and complicates governance across replicated and inherited objects. Query‑level context (e.g., workload, feature, customer) is rarely captured natively, so associating query/warehouse usage back to business drivers can require manual mapping or unreliable naming conventions.

Business Value

Granular cost allocation enables consistent tags on warehouses and key objects enable accurate mapping of compute credits and related costs to cost centers, products, or customers, enabling showback and chargeback with minimal manual reconciliation. Improving governance and auditability involves tagging that provides a queryable layer of metadata that supports governance reviews. For example, identifying which warehouses are associated with specific cost centers, workloads, or data classifications, enabling more structured reporting and policy enforcement.

Operational efficiency looks like tag‑driven reporting that lets teams identify high‑cost workloads and optimize them, while tag inheritance and automatic propagation reduce operational overhead to maintain attribution coverage.

High-Level Solution

• Standardize Taxonomy: Define global tag keys (e.g., cost_center, environment, owner_team, workload_team) and enforce them via CI/CD pipelines and platform-level guardrails for cross-cloud consistency.
• Automate Coverage: Apply mandatory tags to compute and storage objects, leveraging inheritance to propagate metadata from parent containers to granular resources automatically.
• Enable Attribution: Join platform consumption telemetry with tag metadata to generate automated showback and chargeback reports for full financial accountability.

Snowflake Example: Practitioners utilize Object Tagging on warehouses and databases, then query the TAG_REFERENCES and ACCOUNT_USAGE views to attribute credit spend directly to specific tags.

Design the Tag Model

• Identify core business dimensions to capture: cost center, product, customer segment, environment, ownership, sensitivity/classification, and workload category.
• For key tags (e.g., cost_center, environment), define ALLOWED_VALUES to constrain options and avoid free‑text drift. Note that Snowflake resolves overlaps via a hierarchy where the tag closest to the object takes precedence.

Create Tags Centrally

• Use a governance or tag_admin role to create tags in a shared database or schema using the CREATE TAG command, optionally defining ALLOWED_VALUES.
• Document naming conventions (e.g., snake_case names, consistent value labels) and integrate them into organizational development standards.

Establish Management Approach & Access

• Select a management model: centralized (governance team applies tags), decentralized (individual teams apply tags), or hybrid (central creation, distributed application).
• Grant CREATE TAG and APPLY TAG privileges accordingly. Ensure roles owning warehouses, databases, or schemas have the necessary privileges to set required tags while enforcing that tags cannot be bypassed in production.

Implement Warehouse‑Level Mandatory Tags

• Require that all warehouses have cost_center, environment, and workload_type tags set during CREATE or ALTER WAREHOUSE workflows.
• For multi‑tenant warehouses, define an attribution strategy (e.g., using specific workload_type values combined with query-level metadata) to minimize “unallocated” spend buckets.

Implement Object‑Level Tagging & Inheritance

• Apply core tags to higher‑level objects (Account, Database, or Schema) so they automatically inherit down to tables and columns, leveraging Snowflake’s native propagation.
• Use tags like data_classification or sensitivity for governance, and product or line-of-business to link costs to business ownership.

Leverage Automatic Propagation

• Utilize Snowflake’s automatic propagation across dependencies and data movement; for example, clones inherit tags from the source object by default.
• Ensure the tagging hierarchy is documented so that when tags exist at multiple levels (e.g., both Database and Table), the deterministic override behavior maintains attribution quality.

Enable Query‑Level Attribution Semantics

• Define standards for connecting queries to tags:
  • Ensure queries target tagged warehouses and objects so usage can be joined via warehouse_id or object_id.
  • Optionally, enforce query comment conventions (e.g., JSON-encoded metadata) that map to tag values for downstream ETL.
• Use tag references and usage views to infer query context from the specific objects (e.g., Dynamic Tables, Tasks) driving the workload.

Build Attribution & Governance Reporting

• Develop views that join Snowflake usage tables (e.g., WAREHOUSE_METERING_HISTORY, QUERY_HISTORY) with TAG_REFERENCES to compute spend by tag combinations (e.g., cost_center × environment).
• Example Query:

-- Attribution of warehouse credit spend by cost_center and environment tags
-- Source: SNOWFLAKE.ACCOUNT_USAGE
-- Latency: up to 3 hours; not suitable for real-time alerting

SELECT
    wmh.WAREHOUSE_NAME,
    MAX(CASE WHEN tr.TAG_NAME = 'cost_center'   THEN tr.TAG_VALUE END) AS cost_center,
    MAX(CASE WHEN tr.TAG_NAME = 'environment'   THEN tr.TAG_VALUE END) AS environment,
    MAX(CASE WHEN tr.TAG_NAME = 'owner_team'    THEN tr.TAG_VALUE END) AS owner_team,
    DATE_TRUNC('DAY', wmh.START_TIME)                                  AS usage_date,
    SUM(wmh.CREDITS_USED)                                              AS total_credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY wmh
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES tr
    ON  tr.OBJECT_NAME      = wmh.WAREHOUSE_NAME
    AND tr.OBJECT_DOMAIN    = 'WAREHOUSE'
    AND tr.TAG_NAME         IN ('cost_center', 'environment', 'owner_team')
WHERE wmh.START_TIME >= DATEADD('DAY', -30, CURRENT_TIMESTAMP())
GROUP BY
    wmh.WAREHOUSE_NAME,
    DATE_TRUNC('DAY', wmh.START_TIME)
ORDER BY
    usage_date DESC,
    total_credits_used DESC;

What this does: For each warehouse, it pulls the last 30 days of hourly credit metering and pivots the tag values for cost_center, environment, and owner_team into columns using conditional aggregation. The result is a daily spend summary attributable to each business dimension, the “single source of truth” view referenced in the scenario.

Treat these aggregated views as the single source of truth for showback and chargeback dashboards and financial analytics.

Operationalize & Monitor

• Implement automated checks (e.g., CI/CD hooks or scheduled audits) to flag untagged or mis-tagged resources.
• Ensure the number of tags per object respects the Snowflake limit (currently 50 tags per object). Regularly review distributions to retire unused tags and maintain taxonomy hygiene.

Personas/Roles Involved

• FinOps Practitioner: Designs the tagging taxonomy, enforces attribution standards, and owns showback reporting built from tag metadata.
• Product: Defines the business dimensions (product lines, features) that tags must reflect to enable accurate cost-to-product attribution.
• Engineering: Applies tags at warehouse and object level during build and deployment; responsible for maintaining tagging compliance within their workloads.
• Finance: Consumes tag-driven showback reports for internal billing and validates that tag values align to General Ledger cost center structures.

Metrics & KPIs

• Credit Attribution Rate: The percentage of compute credits linked to a valid cost owner. This measures the success of your move away from “unallocated” buckets.
• Tag Coverage Compliance: The percentage of warehouses and production-critical tables carrying all mandatory tags. This is your primary governance health check for the tagging policy.
• Unclassified Spend Trend: The total credit volume or workload count currently labeled as “unknown” or “miscellaneous.” Ideally, this should decrease monthly as attribution logic matures.
• Showback Cycle Efficiency: The time required to generate monthly financial reports. Transitioning to tag-driven models should reduce this from days of manual work to a near-instant automated query.

Cost Drivers

• Compute Credits: The primary cost driver, attributed via metadata on compute engines or virtual machines. For example in Snowflake, Virtual Warehouse usage is attributed via warehouse-level tags, refined by query-level context.
• Storage Consumption: Costs associated with data at rest, attributed based on the containing folder or database metadata. For example, in Snowflake Database and Table tags capture credit burn for data storage, including historical (Time Travel) and replicated data.
• Data Pipelines: Credits consumed by automated ETL/ELT processes and streaming services. For example, in Snowflake Tagged Dynamic Tables, Tasks, and Pipes attribute serverless processing costs directly to specific data products.
• Advanced Features: Additional costs from managed services like search indexing or data sharing. For example, in Snowflake Serverless credits from Materialized Views or Search Optimization are aligned with tags for accurate showback and chargeback.

Data Sources Needed

• SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES — Primary source for querying tag assignments across all tagged objects. Used to join tag metadata against usage and consumption views for cost attribution reporting.
• SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — Hourly credit consumption by warehouse. Joined with TAG_REFERENCES to attribute compute spend to specific cost centres, environments, and workload types.
• SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY — Query execution details including user, role, warehouse, and database context. Used to enrich attribution beyond warehouse-level tags where query-level metadata is available.
• SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE — Account-level daily storage consumption. Combined with database and table-level tags to attribute storage costs to owning teams and data products.

Note: Data represents a point-in-time view only. For current tag schema definitions, inheritance behavior, and TAG_REFERENCES field definitions, refer to the Snowflake Object Tagging Guide and the TAG_REFERENCES Account Usage View.

Risks to Mitigate

• Incomplete Tagging: Unlabeled resources leave spend “orphaned,” undermining report credibility.
• Taxonomy Over-Complexity: Excessive tags increase maintenance and risk hitting platform limits (e.g., Snowflake’s 50-tag limit).
• Financial Misalignment: Tag values that don’t match cleanly to financial structures e.g. General Ledger (GL) Cost Centers, Product Hierarchy codes prevent Finance from using the data for internal billing.
• Override Misinterpretations (Snowflake Specific Example): Snowflake uses hierarchical overrides; if a child object has a different tag value than the parent, the child value wins.

Dependencies

• Platform Readiness: A baseline Cloud Data Platform environment with access to metadata and usage APIs, ensuring the specific service tier supports programmatic tagging and inheritance. For example, in Snowflake access to the Enterprise Edition or higher is required to leverage Object Tagging and automated metadata views.
• Taxonomy Governance: Formal organizational agreement on tag ownership, enforcement mechanisms, and a clear change management process for requesting or retiring tag values. For example, in Snowflake establishing an administrative role (e.g., TAG_ADMIN) with specific CREATE TAG and APPLY TAG privileges to manage the centralized taxonomy.
• System Interoperability: Integration between Data Cloud Platform attribution outputs and the broader technical ecosystem (e.g., CI/CD pipelines, data catalogs, and financial systems) to maintain consistency.
• Permissions (Snowflake Specific Example): Permissions to query the SNOWFLAKE shared database (specifically ACCOUNT_USAGE) to join consumption data with the TAG_REFERENCES metadata view.

Planning and Estimating Accounts (Quantify Business Value)

FinOps Framework Capabilities: Planning & Estimating, Budgeting, Forecasting

Challenge

Data Cloud Platforms consume credits continuously and at variable rates, making cost forecasting inherently difficult. Without a structured planning process, teams default to reactive cost reviews, only identifying budget overruns after the fact. This leads to sudden spend spikes from unplanned workloads, difficulty honoring contractual commitments, and misalignment between engineering activity and financial expectations. For example, in Snowflake, new warehouses can be created and scaled without finance visibility, meaning a single migration or ad hoc analytics burst can materially distort a monthly forecast.

Business Value

Establishing a structured planning and estimation process lets teams manage Data Cloud Platform spend proactively rather than reactively. Improved forecast accuracy reduces budget surprises, enables optimised commitment and contract planning, and creates a clear linkage between engineering roadmaps and financial outcomes. Teams can move from anecdotal cost estimates to a repeatable monthly forecast model.

High-Level Solution

FinOps Practitioners build an account-level forecasting model by combining historical credit consumption trends with forward-looking inputs from engineering and product teams. The model applies simple trend analysis, such as linear regression or rolling averages, on daily and weekly credit consumption, then overlays known planned changes such as new workloads, migrations, or seasonal peaks. In Snowflake, this involves querying SNOWFLAKE.ACCOUNT_USAGE views to extract consumption history, then mapping projected usage against contracted credit commitments to surface variance early.

Snowflake Example: Practical Steps

To build an account-level forecast in Snowflake, the following steps are performed:

1. Extract Historical Usage: Query SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY for at least 3–6 months of credit consumption, segmented by warehouse, service type (compute, storage, serverless), and team.
2. Identify Trends: Normalise daily and weekly credit burn rates and calculate month-on-month growth. Flag warehouses or services with accelerating spend trajectories.
3. Segment by Category: Separate usage into key categories, Compute (virtual warehouses), Storage, and Serverless Features (including Snowpipe, Tasks, Automatic Clustering, Materialized Views, and Search Optimization — each billed independently of virtual warehouse credits) to isolate the primary cost drivers.
4. Overlay Business Inputs: Gather forward-looking inputs from engineering and product leads: new warehouse deployments, planned migrations, upcoming peak seasons, or workload retirements.
5. Produce a Monthly Forecast: Map projected credit volumes to current credit costs and publish a monthly forecast report, reconciling projected spend against contracted commitments.

Personas/Roles Involved

• FinOps Practitioner: owns the forecasting model and monthly reporting cycle
• Finance Business Partner / FP&A: validates forecasts against budget and contract commitments
• Data / DevOps Engineering Teams: provides forward-looking pipeline and workload inputs
• Product or Business Unit Owner (optional): informs demand-side planning for new features or initiatives

KPIs

• Forecast Accuracy: Variance between projected and actual monthly credit consumption
• Budget Variance: Difference between approved budget and actual spend at period close
• Commitment Utilisation Rate: Percentage of contracted credits consumed within the commitment period
• Time to Forecast: Number of days required to produce a complete monthly forecast

Cost Drivers

• Compute Credits: Virtual warehouse usage is the primary driver; unplanned warehouse creation or upsizing can cause significant forecast deviation.
• Storage Consumption: Data retention policies, Time Travel settings, and Fail-safe windows drive storage growth that compounds over time.
• Serverless Features: including Snowpipe, Tasks, Automatic Clustering, Materialized Views, and Search Optimization all consume credits independently of virtual warehouses and are frequently underestimated in forecasts.
• Marketplace Usage: Third-party data product consumption adds variable cost that is difficult to predict without pipeline-level intake tracking.

Data Sources Needed

For Snowflake, the following system views provide the data required to build and maintain a forecast:

• SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY — daily credit consumption by service type
• SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — compute credit consumption by warehouse
• SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE — storage consumption over time
• SNOWFLAKE.ACCOUNT_USAGE.METERING_DAILY_HISTORY — granular daily consumption breakdown
• SNOWFLAKE.ORGANIZATION_USAGE views — for multi-account aggregation
• Contract and commitment data from the Snowflake billing portal

Note: Data represents a point-in-time view only. For current schema definitions and view availability across METERING_HISTORY and related views, refer to the Snowflake Account Usage Documentation.

Risks to Mitigate

• Forecast Underestimation: New, large, or unplanned workloads, particularly migrations or new product launches can cause material variance. Establish a formal intake process so engineering changes are reflected in forecasts before they occur.
• Trend Oversimplification: Relying solely on linear trend extrapolation risks missing significant seasonality or growth inflection points. Supplement with qualitative inputs from engineering leads.
• Untagged Workloads: Usage from untagged or miscategorized warehouses cannot be accurately attributed, reducing forecast segmentation quality.
• Commitment Misalignment: Organizations on Snowflake capacity commitments risk under-consuming contracts or incurring on-demand overage if forecasts are not reconciled against contract terms regularly.

Dependencies

• At least 3–6 months of stable, accessible usage history in ACCOUNT_USAGE
• A named FinOps Practitioner with ownership of the forecasting cycle
• Access to forward-looking engineering and product roadmaps for demand-side planning, for example:
  • New warehouses
  • Migrations from SQL server to Snowflake, the stages of migration and the build up of costs, plus the in-efficiency of existing SQL queries being migrated over
• Established warehouse naming conventions and tagging to enable accurate usage segmentation
• Access to contract and commitment data from the Snowflake billing portal

Warehouse Controls (Optimize Usage and Cost)

FinOps Framework Capabilities: Usage Optimization

Challenge

In Data Cloud Platforms, compute resources are provisioned on demand and continue to consume credits even during periods of low or no activity. Without controls on warehouse sizing and suspension behavior, organizations accumulate significant idle spend, particularly in development and ad hoc environments where warehouses are left running between query executions. In Snowflake, the default auto-suspend setting of 10 minutes can result in hours of unnecessary credit burn across a fleet of warehouses, and default warehouse sizes are frequently set larger than workloads require.

Business Value

Implementing foundational warehouse controls is one of the fastest wins in a Data Cloud environment. Enforcing auto-suspend thresholds and right-sizing warehouses eliminates idle credit burn without impacting query performance, yielding early compute cost reductions when applied. These controls also establish the governance baseline for more advanced workload optimization at Walk and Run maturity.

High-Level Solution

FinOps Practitioners work with Platform Administrators and engineering teams to enforce three core controls: appropriate auto-suspend thresholds, default warehouse sizing set to the smallest viable size (e.g., X-Small), and auto-resume enabled for on-demand workloads. In Snowflake, these controls are applied via ALTER WAREHOUSE commands or enforced through Infrastructure-as-Code templates. A warehouse inventory review identifies oversized or persistently active warehouses for right-sizing.

Practical Steps

To implement foundational warehouse controls in Snowflake:

1. Audit the Warehouse Fleet: Query SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY to identify warehouses with high idle-to-active ratios or consistently low utilisation.
2. Set Auto-Suspend: For non-production and ad hoc warehouses, set AUTO_SUSPEND = 60 (seconds). For production batch workloads, AUTO_SUSPEND = 120–300 is typically appropriate. Avoid the default 600-second setting.
3. Enable Auto-Resume: Ensure AUTO_RESUME = TRUE on all warehouses so that queries can start on-demand without manual intervention.
4. Right-Size Warehouses: For warehouses where average query execution time is short and concurrency is low, downsize from the current size. Start new workloads at X-Small and scale up only when evidenced by performance data.
5. Set Default Size Policy: Adopt a policy that all new warehouses default to X-Small unless a workload sizing assessment has been completed and approved.
6. A robust RBAC strategy is required in order to prevent proliferation of Warehouses e.g., restricting CREATE WAREHOUSE privilege to a governance role; using Infrastructure-as-Code templates to enforce warehouse policies

Note: Warehouse sizing and suspension best practices evolve with platform capabilities. Refer to the Snowflake Warehouse Considerations documentation for current guidance.

Personas/Roles Involved

• Data Cloud Platform Administrator: applies warehouse configuration changes and enforces policies
• FinOps Practitioner: identifies optimization candidates and tracks credit savings; monitors credit consumption impact post-implementation
• Engineering and/or Data Teams: validates that suspension thresholds do not impact workload SLAs

KPIs

• Idle Credit Ratio: Proportion of total warehouse credits consumed during periods of no query activity (target: <10%)
• Average Auto-Suspend Threshold: Mean suspension time across all warehouses (target: ≤120 seconds for development; ≤300 for production)
• Warehouses Exceeding X-Small Default: Count of warehouses provisioned above the default size without a documented sizing justification
• Credit Reduction vs. Baseline: Month-on-month compute credit reduction following control implementation

Cost Drivers

• Idle Compute: Warehouses running without active queries are the single largest avoidable cost driver in most Snowflake environments.
• Oversized Warehouses: Warehouses provisioned larger than workload requirements consume credits at higher rates for the same throughput.
• Multi-Cluster Warehouses: Unnecessary multi-cluster configurations add concurrency capacity that is rarely fully utilized outside peak periods.
• Development and Sandbox Environments: Ad hoc and exploratory environments are disproportionately prone to idle burn due to infrequent and unpredictable usage patterns.

Data Sources Needed

• SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — credit consumption by warehouse over time
• SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY — query execution times and warehouse utilisation patterns
• SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_EVENTS_HISTORY — warehouse start, suspend, and resize events

Note: Data represents a point-in-time view only. For current warehouse configuration options, sizing guidance, and WAREHOUSE_METERING_HISTORY field definitions, refer to the Snowflake Warehouse Considerations Guide and the WAREHOUSE_METERING_HISTORY Account Usage View.

Risks to Mitigate

• Under-provisioning During Peak Loads — Setting auto-suspend too aggressively on shared production warehouses can cause cold-start delays and queue build-up during peak periods. Validate thresholds against workload patterns before applying broadly.
• Blanket Right-Sizing — Reducing warehouse size for compute-intensive batch workloads can significantly increase query runtime. Assess each workload individually before downsizing.
• Policy Drift — Warehouse controls applied manually are frequently overridden. Enforce configurations through IaC or Snowflake resource monitors to prevent settings being changed ad hoc.
• Warehouse Proliferation — Without RBAC controls restricting CREATE WAREHOUSE privileges, teams create new warehouses to bypass governance controls, negating the impact of any sizing or suspension policy.
• Multi-Cluster Misconfiguration — Enabling multi-cluster scaling without appropriate min/max cluster settings can cause uncontrolled scale-out during concurrent query bursts, rapidly multiplying credit consumption.
• Cold-Start Impact on SLAs — Aggressive auto-suspend on warehouses serving time-sensitive pipelines or dashboards can breach SLAs if resume latency is not accounted for in workload design.

Dependencies

• ACCOUNT_USAGE Access — Query access to SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY and WAREHOUSE_EVENTS_HISTORY to perform the initial warehouse fleet audit and establish idle credit baselines.
• Administrative Privileges — ACCOUNTADMIN or a delegated role with MODIFY WAREHOUSE privileges to apply auto-suspend, auto-resume, and sizing changes via ALTER WAREHOUSE commands.
• Established Warehouse Naming Conventions — Warehouses must follow a consistent naming convention (e.g., TEAM_ENV_WORKLOADTYPE_WH) to enable accurate attribution of idle spend to owning teams before controls are applied.
• Tagging Policy in Place — Object tags linking warehouses to cost centres, environments, and workload types must exist prior to this scenario to ensure that credit savings can be attributed to specific teams after controls are implemented.
• Infrastructure-as-Code (IaC) Templates — Terraform or equivalent IaC tooling should be in place to enforce warehouse configuration standards at provisioning time, preventing manual overrides and policy drift post-implementation.
• RBAC Governance Model — A defined role-based access control policy restricting CREATE WAREHOUSE privileges to a governance or platform administrator role, preventing uncontrolled warehouse proliferation that would undermine the controls being applied.
• Engineering Team Alignment — Agreement from workload owners and data engineering leads on acceptable auto-suspend thresholds and default sizing standards, ensuring controls do not breach workload SLAs before they are enforced broadly.

Understand the Invoice – Billing and Commitments (Manage the FinOps Practice)

FinOps Framework Capabilities: Invoicing & Chargeback

Challenge

Data Cloud Platform billing structures combine multiple distinct consumption types: virtual warehouse compute, storage, serverless features (including Snowpipe, Tasks, Automatic Clustering, Materialized Views, and Search Optimization — each billed independently of virtual warehouse credits), and marketplace, into a single consolidated invoice, making it difficult to reconcile actual spend against contracted commitments without structured analysis. Organizations with multi-year capacity commitments must actively monitor burn-down rates to avoid both under-utilisation (losing contracted credits) and unexpected on-demand overage charges, yet most teams only review billing data reactively at month or quarter close.

Business Value

Proactive invoice analysis enables organizations to identify high-spend accounts, validate that consumption is aligned with contractual commitments, and surface discrepancies before they escalate. Teams that establish regular billing reviews gain the ability to make timely decisions about contract renewals, renegotiations, and workload prioritisation, replacing reactive invoice reconciliation with a forward-looking financial control.

High-Level Solution

FinOps Practitioners establish a regular billing review cycle, typically monthly, that reconciles actual credit consumption against committed spend across compute, storage, and marketplace categories.

In Snowflake, this involves querying ACCOUNT_USAGE and ORGANIZATION_USAGE views to construct a consolidated burn-down view, then aligning it against the contracted commitment schedule from the billing portal. High-spend accounts and services are identified and flagged for investigation or optimization.

Snowflake Example: Practical Steps

To build a billing and commitment review process in Snowflake:

1. Understand the details of your commitment:
   1. Total dollar or credit value
   2. Duration of the contract
   3. Pricing rate /credit value (For compute and data storage)
2. Access the Billing Portal: Use the Snowflake billing portal or the SNOWFLAKE.ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY view to retrieve credit consumption converted to monetary cost by day.
3. Construct a Burn-Down View: Calculate remaining contracted credits: Remaining Credits = Total Commitment − Cumulative Credits Consumed. Plot against the contract end date to identify whether consumption is on pace.
4. Segment by Service Type: Break down consumption into Compute (virtual warehouse credits), Storage (bytes × rate), Serverless Features (including Snowpipe, Tasks, Automatic Clustering, Materialized Views, and Search Optimization — each billed independently of virtual warehouse credits), and Marketplace to identify which categories are driving spend.
5. Identify Top Cost Accounts: Use WAREHOUSE_METERING_HISTORY and METERING_HISTORY to rank top-consuming warehouses, databases, and services.
6. Visualise and Distribute: Build a monthly billing summary using Snowsight dashboards or an external BI tool, and distribute to Finance, Engineering, and Platform leads.

Note: This data reflects a point in time. Refer to the Snowflake Cost Management documentation for current billing schema details.

Personas/Roles Involved

• FinOps Practitioner: primary owner of the billing review cycle
• Finance / FP&A: validates invoice against budget and commitment terms
• Engineering: provides context on spend drivers and remediation actions
• Product: informs commitment planning based on roadmap changes
• Procurement: identifies and manages contract value, duration, renewal, and renegotiation

KPIs

• Remaining Commitment: Total contracted credits minus cumulative credits consumed to date
• Burn Rate vs. Projected Rate: Comparison of actual daily/weekly credit burn against the rate required to consume the full commitment by contract end
• On-Demand Overage: Credits consumed outside the contracted commitment at on-demand rates
• Actual vs. Projected Spend Variance: Deviation between forecasted and actual invoiced spend at period close

Cost Drivers

• Warehouse Compute Credits: The primary component of most Snowflake invoices, driven by warehouse size, runtime, and concurrency.
• Storage Bytes: Data retention volume, including Time Travel and Fail-safe storage, billed at a per-terabyte rate.
• Data Transfer: Egress fees for data moved between regions or clouds, and for Snowflake data sharing where applicable.
• Serverless Features: Including Snowpipe, Tasks, Automatic Clustering, Materialized Views, and Search Optimization — each billed independently of virtual warehouse credits, and each consume credits and appear as distinct line items.
• Marketplace Listings: Third-party data product subscriptions billed separately from standard credit consumption.
• SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY — daily credit consumption by service type
• SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — compute credits by warehouse
• SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE — storage consumption over time
• SNOWFLAKE.ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY — consumption converted to monetary cost

Note: Data represents a point-in-time view only. For current billing schema definitions, commitment structures, and monetary usage views, refer to the Snowflake Cost Management Overview Guide and the USAGE_IN_CURRENCY_DAILY Organization Usage View.

Risks to Mitigate

• Incomplete Coverage: Excluding storage, marketplace, or serverless features (including Snowpipe, Tasks, Automatic Clustering, Materialized Views, and Search Optimization — each billed independently of virtual warehouse credits) from invoice analysis results in an inaccurate picture of total spend. Ensure all service types are included.
• Commitment Burn Misalignment: Failing to monitor burn-down rates monthly can result in missed commitment targets — either unused credits at contract end or unexpected on-demand charges.
• Data Freshness Lag: ACCOUNT_USAGE view latency varies by view type, typically 45 minutes to 3 hours; practitioners should check Snowflake documentation for per-view latency and supplement with INFORMATION_SCHEMA for near-real-time operational queries.

Dependencies

• USAGE_VIEWER role (or equivalent) to access SNOWFLAKE shared database views
• Access to the Snowflake billing portal for contract and commitment data
• Tagging policy in place to enable spend attribution down to business unit or cost centre level
• A defined billing review cadence agreed between FinOps, Finance, and Platform teams

Training, Education, Awareness and Collaboration (Manage the FinOps Practice)

FinOps Framework Capabilities: FinOps Education & Enablement

Challenge

Data Cloud Platform cost management requires active participation from engineering, product, and finance teams, yet each group operates with different priorities, vocabulary, and incentives. Without a deliberate education program, FinOps knowledge often remains siloed within a central team. The behavioral changes required to understand the cost impact and value of their actions never materialize. Without this teams may run expensive queries, over-provision compute, or use inefficient storage and pricing models.

Business Value

FinOps training gives teams visibility into how their decisions impact cost, usage, and value, creating accountability for resource consumption. Teams optimize when they understand actual usage patterns, while the organization can make informed trade-offs between performance, scale, and spend. Over time, cost optimization becomes a shared responsibility, embedded into everyday decision-making across technical and business teams. For example, Engineers who understand how their queries translate into credit consumption naturally write more efficient code and raise issues proactively. Finance teams who understand platform billing structures can engage more meaningfully in commitment planning.

High-Level Solution

Establish a continuous FinOps learning loop that combines foundational training with practical, hands-on scenarios. Teams learn and collaborate across functions, sharing insights and best practices, while cost discussions are embedded into existing governance forums. Regular sessions such as Efficiency Chapters, FinOps Guilds, and Operational Reviews reinforce awareness and make cost-conscious decision-making part of everyday workflows, rather than delivered as standalone events, maximizing reach and relevance.

Practical Steps

To build a FinOps enablement program for Snowflake:

1. Map Personas and Knowledge Gaps: Identify the key stakeholder groups — Platform Engineers, Data Engineers, Analysts, Finance, and Product — and document the specific knowledge gaps for each (e.g., engineers may not understand Time Travel costs; Finance may not understand credit consumption models).
2. Develop Role-Specific Content: Create concise reference materials for each persona.  Center training on Data Cloud cost drivers such as compute, storage, streaming, and service-specific pricing models and cover SLAs and guidance for using generally available features in production. For example a “Snowflake Cost Basics” guide for engineers, a “Reading Your Snowflake Invoice” guide for Finance, and a “FinOps KPI Glossary” for leadership.
3. Conduct Sessions: Run interactive workshops and include FinOps in new-hire onboarding. Provide sandbox projects for safe experimentation and dashboards for real-time consumption tracking. Invite CSP technical SMEs to share expertise and best practices.
4. Governance Integration: Incorporate cost and usage reviews into existing architecture and steering committees to make financial accountability routine.
5. Measure & Gamify: Track “FinOps IQ” through surveys, host hackathons and share success stories to reinforce a cost conscious culture.

Personas/Roles Involved

• FinOps Practitioner: designs and delivers the enablement program
• Platform/Data Engineering Teams: primary recipients of technical training
• Finance/FP&A: recipients of billing and commitment briefings
• Product/Business Unit Owners: participants in FinOps governance forums
• Engineering Leads: act as FinOps champions within their teams

KPIs

• Training Coverage: Percentage of in scope Personas e.g. Engineering, who have completed relevant FinOps training material
• Champion Network Coverage: Number of teams with a designated FinOps champion, responsible for FinOps for Data Cloud Platforms
• Cost-Related Incident Rate: Reduction in cost anomalies attributable to untagged or unoptimised workloads following training rollout (baseline prior to training launch date)
• Tagging Compliance Rate: Percentage of warehouses and queries with required tags applied (as a proxy for behavioral change)

Cost Drivers

• Unoptimised Query Patterns: Engineers unaware of Snowflake cost mechanics tend to write full-table scans, avoid clustering keys, and rerun expensive queries unnecessarily.
• Ad Hoc Warehouse Proliferation: Without education on warehouse governance, teams create new warehouses for individual use cases rather than sharing appropriately sized resources.
• Missed Tagging: Engineers who do not understand attribution requirements fail to apply tags, creating unallocated spend that obscures cost ownership.

Data Sources Needed

Internal LMS or training platform completion data required.

Risks to Mitigate

• Training Without Reinforcement: One-time training events have limited lasting impact. Embed FinOps updates into regular operational forums to sustain behavioral change over time.
• Generic Content: Training that is not tailored to specific personas or platform contexts is quickly disengaged from. Use real query cost examples and actual Data Cloud Platform data to make content concrete.
• No Clear Ownership: Without a defined FinOps champion network, responsibility for adoption diffuses and training does not translate into sustained practice changes.

Dependencies

• Stakeholder buy-in from Engineering and Finance leadership to prioritize time for training.
• Established tagging and warehouse naming conventions to use as worked examples.
• A defined FinOps champion network or equivalent governance structure.

Practical Scenarios: Walk

Query-Level Usage Tracking and Warehouse Performance Analysis (Understand Usage & Cost)

FinOps Framework Capabilities: Allocation, Reporting & Analytics

Challenge

Account-level cost visibility identifies how much is being spent, but not which queries, users, or workloads are responsible. Data cloud resources like virtual warehouses and compute clusters are shared across multiple teams, making precise cost attribution complex. Without query-level attribution, high-cost workloads remain invisible, making it impossible to identify waste, enforce accountability, or optimize the right things.

Shared warehouses compound the challenge: when multiple teams or pipelines run on the same resource, credit consumption cannot be attributed to individual workloads without query-level tagging or metadata enrichment. Clustered table scans, repeated large queries, and inefficient pipeline patterns accumulate significant cost that is invisible at the warehouse level.

Ephemeral resources exist for minutes or hours, traditional infrastructure tagging proves insufficient, and virtual currency consumption (credits, DBUs, slots) requires normalization. Teams dispute allocated costs without granular query-level attribution showing actual usage patterns.

More specific challenges then also exist such as:

• Warehouse metering reports hourly credit consumption but does not explain which queries or users drove that spend, leaving cost optimization teams unable to pinpoint root causes.
• Query execution details exist in query history, but correlating them with warehouse-level credit consumption requires manual joins and allocation logic that teams often implement inconsistently or skip entirely.
• AI-enabled workloads add a second spend dimension (e.g., AISQL/token usage) that must be correlated back to the same query, warehouse, and business context for accountable showback and chargeback.
• Hidden cost drivers such as burst BI dashboards, or poorly clustered table scans events remain invisible without query-level attribution, preventing effective optimization.

Business Value

Build accurate allocation and chargeback to attribute consumption to cost owners by user, role, query tag, application, or customer rather than relying on warehouse names. Use query-level credit attribution connects individual queries to actual spend, enabling teams to identify high-cost workloads, users, or applications and take targeted action. Seek proactive optimization: surface hidden cost drivers (inefficient scans, duplicated analytics queries) shifts teams from reactive budget firefighting to continuous improvement based on data.

Enable business units to calculate unit economics (cost per customer, cost per feature) enabling data-driven pricing decisions. For example, Finance achieves predictable budgeting with costs properly attributed. Lastly, attain faster performance triage: pinpoint the specific queries and time windows causing queueing, excessive scans, or runaway concurrency.

High-Level Solution

Deploy automated tagging enforcement through Infrastructure-as-Code with custom metadata enrichment at query and job levels. Implement proportional allocation algorithms for shared resources based on actual usage metrics. Create unified allocation rules normalizing virtual currencies across platforms into consistent cost views with automated daily updates.

For example in Snowflake:

• Establish Query-level Attribution: Use QUERY_ATTRIBUTION_HISTORY to get per-query credit consumption, eliminating the need for manual allocation formulas and providing direct visibility into who ran what and at what cost.
• Correlate with Warehouse Signals: Join query history with WAREHOUSE_LOAD_HISTORY and WAREHOUSE_METERING_HISTORY to identify when high concurrency, queueing, or scaling events inflate costs beyond query execution time alone.
• Track AI Workload Costs: Extend the same attribution model to AI SQL activity using CORTEX_AISQL_USAGE_HISTORY to connect token consumption back to credit usage and operational owners.

Snowflake Examples: Practical Steps

Example: Practical Steps to implement query-level cost attribution in Snowflake:

1. Build a Query-Level Cost Dataset
   1. Join QUERY_HISTORY with WAREHOUSE_METERING_HISTORY to allocate warehouse credits proportionally to individual queries based on execution time and concurrency.
   2. Normalize to a common unit (credits or currency) and retain QUERY_ID to support joins to performance and AI usage tables.
2. Apply Attribution Dimensions
   1. Use USER_NAME, ROLE_NAME, QUERY_TAG, and DATABASE_NAME fields from QUERY_HISTORY to attribute cost to teams, applications, and workload types.
   2. Enforce query comment conventions (e.g., JSON-encoded metadata) for enriched attribution where tags are not available.
3. Track Cortex AI Workload Costs
   1. Query CORTEX_AISQL_USAGE_HISTORY to retrieve AI function usage (FUNCTION_NAME, MODEL_NAME, TOKENS, CREDITS consumed) per QUERY_ID.
   2. Correlate AI function usage with user, warehouse, and query tag metadata to attribute generative AI costs to business units or applications.
4. Identify Top Cost Queries
   1. Rank queries by total credits consumed over a rolling 7- or 30-day window. Investigate the top 10–20 queries for optimization opportunities: full-table scans, missing cluster key utilisation, or repeated execution.
5. Enable Query-Level Attribution Semantics:
   1. Define standards for connecting queries to organizational tags, ensure queries target tagged warehouses and objects so usage can be joined via WAREHOUSE_ID or OBJECT_ID.
6. Operationalize Continuous Monitoring
   1. Schedule automated alerts for queries exceeding cost thresholds (e.g., >10 credits per query) or showing anomalous patterns (sudden spike in credit usage).
   2. Integrate query-level cost data into incident response workflows so teams can quickly investigate spikes in warehouse spend.
7. Build Cost Attribution Dashboards
8. 1. Create dashboards that aggregate by user, warehouse, query tag, date, and cost center.
   2. Surface top-N expensive queries, users, or applications; track trends over time to measure optimization impact.

Note: Refer to the Snowflake QUERY_HISTORY documentation for current field definitions and query attribution best practices.

Personas/Roles Involved

• FinOps Practitioner: builds and maintains the query-level attribution model
• Data/Analytics Engineers: primary recipients of query cost feedback and optimization recommendations
• Engineering Managers: review team-level cost attribution for accountability and showback
• Finance/FP&A: consumes attributed cost data for chargeback and budget reporting

KPIs

• Average Query Cost: Average credits consumed per query, segmented by user, warehouse, or query tag. Tracks efficiency of individual workloads and identifies outliers.
• Query Attribution Coverage: Percentage of total warehouse credits that can be attributed to specific queries. Measures completeness of query-level tracking.
• Idle Time Percentage: Ratio of unattributed warehouse credits (idle time) to total metering credits. High idle time signals opportunities for auto-suspend tuning or warehouse consolidation.
• Concurrency-Driven Cost Overhead: Credits consumed during high-concurrency periods (load >90%) versus normal periods. Identifies when queueing or contention inflates costs.
• Top-N Query Cost Contributors: List of queries or query families (by QUERY_PARAMETERIZED_HASH) accounting for the largest share of credits. Prioritizes optimization targets.

Cost Drivers

• Full-Table Scans: Queries that do not leverage partition pruning or clustering keys scan significantly more data, driving higher credit consumption per execution.
• Repeated / Duplicate Queries: Identical queries run multiple times within short windows, often from BI tools or pipelines accumulate cost that can be eliminated through caching or result reuse.
• High-Concurrency Periods: Spikes in concurrent query execution inflate warehouse credit consumption disproportionately, particularly on multi-cluster warehouses.
• Unoptimised Pipeline Queries: ETL/ELT pipelines that run full-refresh rather than incremental loads are a frequent source of large, avoidable credit expenditure.
• Compute Credits: Direct credits attributed to individual queries, reflecting execution time, warehouse size, and complexity.
• Idle Warehouse Time: Credits consumed when the warehouse is active but no queries are running, driven by auto-suspend delay settings or frequent short-duration queries preventing shutdown.
• Auto-Scaling Events: Credits from warehouse scale-up triggered by burst demand; unnecessary scaling events waste if scaling policy is poorly tuned to actual workload patterns.
• Cortex AI Functions: Serverless credits for generative AI workloads (tokens processed, models invoked) can add to AI-augmented analytics.

Data Sources Needed

• QUERY_ATTRIBUTION_HISTORY: per-query attribution and normalized consumption metrics.
• CORTEX_AISQL_USAGE_HISTORY: AI function/model usage per query (token consumption).

Supporting: To correlate warehouse saturation and queueing patterns.

• QUERY_HISTORY: Query execution details (user, warehouse, query text, execution time, bytes scanned, rows produced).
• WAREHOUSE_LOAD_HISTORY: Warehouse load metrics (average load, queueing, concurrency) over time.
• WAREHOUSE_METERING_HISTORY: Hourly warehouse credit consumption (source of truth for billing).

Note: Data represents a point-in-time view only. For current field definitions across QUERY_ATTRIBUTION_HISTORY, QUERY_HISTORY, and CORTEX_AISQL_USAGE_HISTORY, refer to the Snowflake Account Usage Documentation and the QUERY_ATTRIBUTION_HISTORY View.

Risks to Mitigate

• Attribution Gaps for Very Short Queries: Sub-second queries (≤~100ms) are not captured in QUERY_ATTRIBUTION_HISTORY, leaving small but frequent workloads unattributed.
• Latency in ACCOUNT_USAGE Views: The 45-minute to 3-hour delay in ACCOUNT_USAGE means dashboards are not real-time. Supplement with INFORMATION_SCHEMA for operational alerting.
• Inconsistent Query Tagging: Without enforced QUERY_TAG standards, attribution beyond user and warehouse becomes unreliable. Implement programmatic tagging in ETL frameworks and BI tools.
• Idle Time Misinterpretation: High idle time may be acceptable for on-demand warehouses with strict auto-suspend. Evaluate idle percentage against warehouse usage patterns before optimising.
• AI Cost Attribution Complexity: Cortex AI usage is billed separately (serverless) and may not align cleanly with warehouse credits. Ensure separate tracking and reporting for AI-specific costs.
• Data Volume: QUERY_HISTORY retains 365 days of data but can be very large. Use date and warehouse filters to keep query performance manageable.

Dependencies

• Executive mandate for cost accountability across all teams.
• Query tagging conventions and role naming standards in place across engineering teams
• Account Usage Access: ACCOUNTADMIN or SNOWFLAKE.USAGE_VIEWER role to query ACCOUNT_USAGE schema.
• Warehouse-level tagging to enable workload segmentation beyond user and role context
• A defined showback and chargeback reporting format agreed between FinOps and Finance
• Tagging/annotation standard (QUERY_TAG or query comments) implemented consistently by BI tools, pipelines, and AI workloads.

Account Level Anomaly Detection and Response (Understand Usage & Cost)

FinOps Framework Capabilities: Anomaly Management

Challenge

Data Cloud Platform workloads fluctuate due to scheduled jobs, data pipeline refreshes, and ad hoc analytical queries. Without anomaly detection, unexpected credit spikes can go unnoticed until the monthly invoice arrives, by which point the spend has already occurred and the root cause is difficult to trace. Account-level anomalies are particularly hard to identify manually because credit consumption is spread across multiple warehouses, serverless features, and burst-driven workloads. Teams often lack clear ownership of spend spikes, making it hard to intervene early or determine whether a surge is legitimate growth or an operational incident.

Business Value

Account-level anomaly detection provides early warning signals for abnormal credit consumption, enabling teams to investigate and remediate spend spikes within hours rather than weeks. This prevents runaway spend from escalating into material budget overruns, reduces the risk of breaching contractual commitments, and highlights misconfigurations or inefficient workloads before they become established patterns. Anomaly detection shifts teams from reactive invoice management to proactive financial control.

High-Level Solution

Leverage Snowflake’s Cost Management module to automatically detect anomalies based on historical spend patterns and expected daily consumption. Snowflake’s anomaly detection engine builds a rolling 30-day baseline to determine expected credit usage, flags deviations that exceed statistical thresholds, and allows sensitivity tuning to reduce noise. Anomalies can be filtered at the account or warehouse level to quickly isolate abnormal consumption. Supplement this with usage views such as METERING_HISTORY and WAREHOUSE_METERING_HISTORY to validate anomalies and identify contributing warehouses or services.

Investigate root causes using QUERY_HISTORY, pipeline histories, or owner information, and establish a lightweight response workflow with relevant engineering teams.

Practical Steps

Enable and Access Anomaly Detection

• Ensure Snowflake Cost Management is enabled for accounts.
• Confirm that FinOps practitioners have access to anomaly events in Snowsight.

Review Daily or Weekly Anomalies

• Open the Anomaly Detection dashboard to identify spend spikes at the account or warehouse level.
• Validate whether the spike exceeds the expected baseline or historical trend.

Identify the Responsible Warehouse or Service

• Use WAREHOUSE_METERING_HISTORY to locate unusual warehouse credit consumption.
• Review serverless features in METERING_HISTORY to identify spikes from Snowpipe, Tasks, or other services.

Investigate Root Cause

• For compute spikes:
  • Inspect QUERY_HISTORY for long-running, high-credit, or repeated queries.
• For pipeline spikes:
  • Check TASK_HISTORY or PIPE_USAGE_HISTORY.
• Confirm ownership through tags, warehouse naming conventions, or account structure.

Engage the Workload Owner

• Contact the responsible team or engineer to confirm whether the spike was:
  • Planned (e.g., monthly refresh)
  • Expected due to workload growth
  • Accidental or avoidable (query inefficiency, misconfiguration)

Document and Log Findings

• Record anomalies and their root causes.
• Add repeat offenders to the optimization backlog (Warehouse Controls / Query Optimization scenarios).

Feed Insights into Budgeting and Forecasting

• Share recurring anomaly patterns with Finance or Platform teams.
• Adjust baselines if anomalies represent structural workload growth.

Personas/Roles Involved

• FinOps Practitioner: primary owner; reviews daily anomaly alerts, triages severity, and drives the investigation workflow.
• Snowflake Administrator/Data Platform Engineer: validates warehouse behavior and configuration changes that may explain the spike.
• Workload/Product Owners: confirm whether a consumption surge is planned (e.g. scheduled refresh) or accidental (e.g. misconfiguration or runaway query).
• Finance/FP&A: notified when anomalies are material enough to affect monthly budget tracking or commitment burn rates.

KPIs

• Mean Time to Detect (MTTD) for spend anomalies
• Anomalies Investigated Within SLA (%)
• Repeat Anomaly Rate (% of anomalies recurring within 90 days without resolution)
• False Positive Rate

Cost Drivers

• Unplanned Compute Spikes: Ad-hoc analytical queries, poorly scheduled jobs, or manual warehouse usage can cause sudden credit surges that bypass normal planning.
• Serverless Feature Activity: Snowpipe, Tasks, Search Optimisation, and Clustering consume credits independently of virtual warehouses and are frequently overlooked in anomaly reviews.
• Multi-Cluster Scale Events: Burst demand triggering multi-cluster scale-up can rapidly inflate hourly credit consumption beyond expected baselines.
• Pipeline Backfills: Re-running historical data loads or full-refresh transformations generates large, concentrated credit consumption that appears anomalous against daily patterns.
• Increased Bytes Scanned: Queries without effective pruning scan significantly more micro-partitions, driving disproportionate credit use relative to row count returned

Data Sources Needed

• ACCOUNT_USAGE.METERING_HISTORY — account-level daily credit consumption by service type; primary source for identifying anomalous spend periods.
• ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — hourly warehouse credit consumption; used to isolate which warehouse drove a detected anomaly.
• ACCOUNT_USAGE.METERING_DAILY_HISTORY — daily rolled-up view useful for trending and baseline comparisons over 30–90 day windows.
• ACCOUNT_USAGE.SERVERLESS_TASK_HISTORY, SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY, PIPE_USAGE_HISTORY, AUTOMATIC_CLUSTERING_HISTORY — supporting views to attribute anomalies from queries add serverless features when warehouse metering alone is insufficient.
• Optional: ORGANIZATION_USAGE.METERING_DAILY_HISTORY for multi-account orgs

Note: Data represents a point-in-time view only. For current anomaly detection configuration options, sensitivity settings, and supporting view definitions, refer to the Snowflake Cost Anomaly Detection Guide and the METERING_HISTORY Account Usage View.

Risks to Mitigate

• False positives during expected high-volume periods (month-end, backfills).
• Alert fatigue if anomalies are too frequent or poorly categorized.
• Lack of ownership leading to unresolved anomalies.
• Misclassification of seasonality as anomalies (requires baseline tuning).
• Assuming the anomaly module detects query-level issues, account-level anomalies only detect credit deviations.

Dependencies

• Snowflake Cost Management enabled at account level, with FinOps practitioners having access to anomaly events in Snowsight (USAGE_VIEWER or ACCOUNTADMIN role, or a governed equivalent).
• Warehouse naming and tagging conventions in place to map detected anomalies to owning teams without manual investigation.
• A defined anomaly response workflow agreed between FinOps and engineering: clear escalation paths, SLA for investigation, and a shared record for repeat offenders.
• At least 30–90 days of stable usage history in ACCOUNT_USAGE to establish meaningful baselines for anomaly sensitivity thresholds.

Implementing KPIs (Quantify Business Value)

FinOps Framework Capabilities: KPIs & Benchmarking, Unit Economics

Challenge

Data Cloud Platforms generate granular usage data, but most organizations lack a consistent framework for translating that data into unit economics. Without defined KPIs, it is difficult to assess whether credit consumption is improving or deteriorating over time, to benchmark against industry norms, or to demonstrate the value of FinOps optimization work. Teams make decisions based on total spend rather than efficiency metrics, missing opportunities to detect degrading workload performance early.

Business Value

A KPI framework for Data Cloud Platform usage creates an objective basis for measuring and communicating value. Unit economics such as credits per query, cost per terabyte scanned, and warehouse efficiency percentage allow engineering and finance teams to evaluate whether spend changes reflect volume growth or efficiency loss, enabling value-based rather than cost-only conversations.

High-Level Solution

Instrument Data Cloud Platform usage metadata to track a standard set of unit economic KPIs on a recurring cadence. Build dashboards that surface these KPIs by warehouse, team, and workload type, and establish baseline thresholds so that deviations trigger optimization reviews rather than reactive cost cuts.

Practical Steps

1. Define the KPI set: Agree on a core set of unit economic metrics (e.g. credits per 1,000 query executions, credits per TB scanned, warehouse idle percentage, warehouse efficiency %).
2. Extract baseline data: Query WAREHOUSE_METERING_HISTORY, QUERY_ATTRIBUTION_HISTORY, and QUERY_HISTORY over at least 90 days to establish baseline values by warehouse and team.
3. Build KPI views: Create purpose-built SQL views or dbt models that materialize the agreed KPIs on a daily cadence, normalized to a consistent credit unit.
4. Publish in dashboards: Surface KPIs in Snowsight or a BI tool, segmented by warehouse, cost centre, and time period, with trend lines and threshold alerts.
5. Review on a regular cadence: Incorporate KPI review into monthly FinOps reporting cycles, with engineering managers accountable for trends in their team’s unit costs.

Personas/Roles Involved

• FinOps Practitioner: designs and maintains the KPI framework and reporting infrastructure.
• Data/Analytics Engineers: primary audience for query  and workload-level unit cost feedback.
• Engineering Managers: review team-level KPI trends for accountability and optimization prioritization.
• Finance/FP&A: uses unit economics to contextualize credit spend changes in budget reviews.

KPIs

• Credits per 1,000 query executions — measures average compute cost per unit of analytical work.
• Credits per TB scanned — tracks data scanning efficiency; rising values indicate deteriorating pruning or clustering.
• Warehouse efficiency % — ratio of query execution time to total warehouse active time; indicates idle credit waste.
• Warehouse idle % — proportion of metered credits consumed while no queries are running; directly actionable via auto-suspend tuning.

Cost Drivers

• Warehouse compute credits (virtual warehouse usage), the primary KPI input; rises with warehouse size, idle time, and query volume.
• Storage replication and Time Travel affect credit cost calculations when included in total account spend.
• Serverless features (e.g. Tasks, Clustering, Snowpipe) billed separately from virtual warehouses and must be tracked independently in unit cost models.

Data Sources Needed

• ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY — hourly warehouse credit consumption; primary source for efficiency and idle KPIs.
• ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY — per-query normalized credit consumption; source for cost-per-query metrics.
• ACCOUNT_USAGE.QUERY_HISTORY — query execution details including bytes scanned, execution time, and user/warehouse context.

Note: Data represents a point-in-time view only. For current field definitions across WAREHOUSE_METERING_HISTORY, QUERY_ATTRIBUTION_HISTORY, and QUERY_HISTORY, refer to the Snowflake Account Usage Documentation and the QUERY_ATTRIBUTION_HISTORY View.

Risks to Mitigate

• KPI definitions that differ across teams undermine comparability; agree on and document a single standard before publishing dashboards.
• Unit costs naturally fall as query volume grows due to caching and concurrency; ensure KPI trends account for volume when assessing efficiency.
• Serverless costs excluded from unit calculations create a misleading picture of total workload cost; include all credit types in the denominator.

Dependencies

• Access to ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY and WAREHOUSE_METERING_HISTORY 
• Established warehouse tagging policy
• At least 90 days of usage history for baseline
• Agreed KPI definitions across FinOps, Engineering, and Finance

Data Storage & Lifecycle Management  (Workload Optimization)

FinOps Framework Capabilities: Usage Optimization

Challenge

Storage in Data Cloud Platforms grows continuously. For example, in Snowflake data accumulates across tables, clones, Time Travel history, and Fail-safe windows. Without active lifecycle policies, organizations often retain data well beyond its business value, paying for storage that supports no active workload. Storage costs are particularly insidious because they grow gradually and are rarely attributed to a specific team or workload, making it difficult to assign accountability or justify cleanup effort.

Business Value

Automating data retention and cleanup policies directly reduces storage credit consumption and prevents compounding growth. Organizations that implement lifecycle governance can sometimes reduce storage costs by 20–40% in environments with long retention defaults, while maintaining compliance with data access requirements. This frees up the budget for re-investment and reduces the administrative overhead of manual data hygiene.

High-Level Solution

Apply Snowflake Storage Lifecycle Policies to automate the deletion or archival of data past its retention threshold. Combine this with governance policies that standardize Time Travel windows by object criticality, enforce DROP of deprecated tables and clones, and provide FinOps practitioners with regular storage attribution reports by database and schema.

Practical Steps

1. Audit current storage: Query ACCOUNT_USAGE.TABLE_STORAGE_METRICS and DATABASE_STORAGE_USAGE_HISTORY to identify the largest storage consumers and tables with significant Fail-safe or Time Travel overhead.
2. Classify retention requirements: Work with data owners to assign retention tiers (e.g. 0-day, 7-day, 30-day Time Travel) by table criticality and regulatory requirement.
3. Apply Storage Lifecycle Policies: Use Snowflake Storage Lifecycle Policies to automate deletion or archival of data past its designated retention period.
4. Remove deprecated objects: Identify tables, clones, and schemas with no recent query activity (via QUERY_HISTORY) and work with owners to DROP or archive them.
5. Establish regular storage reporting: Publish monthly storage attribution reports by database, schema, and owning team, with trend comparisons to make growth visible.

Personas/Roles Involved

• FinOps Practitioner: designs and monitors storage reporting; escalates growth anomalies to data owners.
• Snowflake Administrator/Data Platform Engineer: implements lifecycle policies and DROP operations.
• Data Owners/Engineering Teams: accountable for classifying retention requirements for their datasets.
• Compliance/Legal: consulted to confirm minimum retention requirements before lifecycle policies are applied.

KPIs

• Total storage credits (or bytes) consumed by database/schema — primary storage cost metric, tracked monthly.
• Time Travel storage as a percentage of active storage — high ratios indicate overly long Time Travel windows relative to table change frequency.
• Fail-safe storage volume — non-configurable but visible; large Fail-safe overhead signals tables with frequent DML that may benefit from restructuring.
• Storage growth rate month-on-month — flags databases or schemas with accelerating retention that may need lifecycle intervention.

Cost Drivers

• Long Time Travel windows: Time Travel windows up to 90 days (configurable on Enterprise tier): When retention is extended beyond the default 1-day window to the maximum 90 days, tables with frequent updates or deletes accumulate significantly higher storage costs..
• Abandoned clones and development tables: Zero-copy clones created for development or testing that are never dropped accumulate Fail-safe overhead over time.
• Data pipeline full-refresh patterns: ETL pipelines that recreate tables rather than performing incremental updates generate large volumes of historical micro-partitions.
• Marketplace and external data replication: Replicated datasets and Marketplace shares contribute to storage costs that are often not attributed to a consuming team.

Data Sources Needed

• ACCOUNT_USAGE.TABLE_STORAGE_METRICS — per-table breakdown of active, Time Travel, and Fail-safe bytes; primary source for storage attribution.
• ACCOUNT_USAGE.DATABASE_STORAGE_USAGE_HISTORY — daily database-level storage consumption for trending.
• ACCOUNT_USAGE.STORAGE_USAGE — account-level daily storage totals for high-level monitoring.
• ACCOUNT_USAGE.QUERY_HISTORY — used to identify tables with no recent query activity as candidates for archival or deletion.

Note: Data represents a point-in-time view only. For current storage lifecycle policy options, retention configuration, and TABLE_STORAGE_METRICS field definitions, refer to the Snowflake Storage Lifecycle Policies Guide and the TABLE_STORAGE_METRICS Account Usage View.

Risks to Mitigate

• Applying lifecycle policies without data owner sign-off risks deleting data that has undocumented downstream dependencies.
• Reducing Time Travel windows on critical tables decreases the recovery window for accidental data modifications.
• Storage savings may be partially offset by Fail-safe obligations that cannot be shortened.

Dependencies

• ACCOUNTADMIN or equivalent role to alter Time Travel settings and apply Storage Lifecycle Policies.
• Data ownership registry or database/schema tagging to enable accountability-based storage reporting.
• Business sign-off on minimum retention requirements before lifecycle policies are applied in production.

Practical Scenarios: Run

Anomaly Detection – Query Level (Understand Usage & Cost)

FinOps Framework Capabilities: Anomaly Management

Challenge

Unpredictable usage spikes from outlier queries waste compute and hinder effective Warehouse auto-scaling. Recurring short queries, orphaned jobs, and poor tagging reduce anomaly traceability and detection accuracy. Queries causing memory errors, join explosions, and disk spills degrade performance without proactive controls. Dynamic AI query costs driven by prompt length and model complexity complicate anomaly detection. Rapid bursts from Cortex Agents obscure legitimate workload spikes versus runaway loops.

Business Value

Granular cost visibility at the query level allows precise optimization and cost savings. Connect anomaly detection to cost governance to deliver measurable ROI. Connect anomaly detection to performance and reliability, increasing customer satisfaction. Proactive detection prevents runaway costs and resource waste. Achieve long-term optimization and scalability planning through best practices.

High-Level Solution

• Deviation of query average execution time and bytes scanned compared to historical baseline
  • Deviation = (Current Value – Historical Average) / Historical Average
• Enable proactive cost control by applying Snowflake’s ANOMALY_DETECTION function to time-series aggregations of per-query credit data — for example, daily credit totals grouped by QUERY_PARAMETERIZED_HASH — to identify statistically significant deviations from historical baselines. Note that ANOMALY_DETECTION operates on pre-aggregated time-series structures, not on raw query-level records from QUERY_ATTRIBUTION_HISTORY directly. For teams earlier in their maturity, custom statistical thresholds using standard deviation over a rolling 30-day baseline are often a simpler and equally effective starting point before introducing ML-based detection.
• Group workloads by query_hash and query_parameterized_hash to normalize patterns and build reliable historical baselines for anomaly detection
• Set per-team and per-model anomaly sensitivity thresholds, and configure automated escalation workflows for governance and accountability
• Connect anomaly detection outputs to monitoring and notification tools (e.g., Snowflake Alerts, external observability platforms) for near real-time cost governance actions
• Enable a continuous feedback loop using anomaly insights to optimize workloads and adjust thresholds as usage patterns evolve

Practical Steps

• Automate outlier alerts using QUERY_HISTORY, QUERY_ATTRIBUTION_HISTORY, and CORTEX_AISQL_USAGE_HISTORY.
• Monitor query volume per time interval and compare against historical patterns to detect anomalies.
• Leverage QUERY_INSIGHTS to identify performance-impacting factors and recommend optimization steps.
• Tag and log problematic queries for remediation, linking them to owners, teams, and cost centers for accountability.

Personas/Roles Involved

• FinOps Practitioner: Primary owner. Reviews daily anomaly alerts, triages severity, initiates investigations, and tracks recurring offenders for escalation.
• Snowflake Administrator/Data Platform Engineer: Validates whether a spike reflects a configuration change, scaling event, or platform issue using warehouse event histories.
• Workload/Product Owner: Confirms whether a consumption surge was planned or accidental, determining whether remediation is required.
• Data/Analytics Engineer: Investigates and resolves anomalies traced to specific queries, pipelines, or transformation jobs.
• Finance/FP&A: Notified when anomalies are material enough to affect monthly budget tracking or commitment burn rates.
• Engineering Manager: Accountable for ensuring their team responds to attributed anomalies within the agreed SLA, acting as the escalation point for unresolved issues.
• Security Teams: where anomaly could also have a security related incident associated to it.

KPIs

• Improve anomalies are correctly identified to avoid false positives and wasted investigation effort
  • Precision= (True Positives / (True Positives + False Positives)) × 100
  • Accuracy = ((True Positives + True Negatives) / Total Sample) × 100
• Reduce Mean Time to Detect (MTTD) for cost anomalies to enable near real-time intervention and prevent runaway compute costs.
• Lower Mean Time to Remediate (MTTR) by streamlining workflows so anomalies are resolved quickly, minimizing financial impact.
• Track credits saved by mitigating abnormal query costs, directly linking anomaly detection to measurable ROI.

Cost Drivers

• Credits consumed per query that drive cost spikes.
• Bytes scanned per query driven by inefficient patterns.
• Query frequency against historical patterns.
• AI-driven query costs (including Cortex AI SQL) driven from prompt length, model complexity, and execution patterns.

Data Sources Needed

• Compute Usage: QUERY_HISTORY, QUERY_ATTRIBUTION_HISTORY, WAREHOUSE_METERING_HISTORY, WAREHOUSE_LOAD_HISTORY for per-query and per-warehouse cost attribution

• Query Insights: QUERY_INSIGHTS for performance diagnostics, including factors impacting query efficiency (e.g., join explosions, disk spills) to enable proactive optimization.

• AI Query Usage: CORTEX_AISQL_USAGE_HISTORY for capturing AI-related query details, including function name, model name, tokens processed, and token credits.

Sample Query to Track Cortex Functions Usage:

SELECT
USAGE_TIME,
MODEL_NAME,
FUNCTION_NAME,
TOKEN_CREDITS,
TOKENS,
QUERY_ID,
QUERY_TAG,
USER_ID,
WAREHOUSE_ID
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AISQL_USAGE_HISTORY
WHERE USAGE_TIME >= DATEADD('DAY', -7, CURRENT_TIMESTAMP())
ORDER BY TOKEN_CREDITS DESC;

Note: Data represents a point-in-time view only. For current field definitions across QUERY_INSIGHTS, QUERY_ATTRIBUTION_HISTORY, and CORTEX_AISQL_USAGE_HISTORY, refer to the Snowflake Query Insights Guide and the CORTEX_AISQL_USAGE_HISTORY Account Usage View.

Risks to Mitigate

• Overly aggressive query termination can disrupt critical workloads and breach business deliverables.
• Excessive alert noise may lead to warning fatigue.
• Excessive false positives may cause teams to ignore authentic anomalies and delay interventions.
• Excessive instrumentation, alerts, telemetry, and logging can generate extra cost and drop in performance.
• Lack of defined ownership for query patterns results in unresolved anomalies and erodes trust in the detection system

Dependencies

• Consistent query tagging, cost center mapping, and role-based access controls for accurate anomaly attribution.
• Integration with Slack, PagerDuty, or Snowflake alerts to deliver anomalies to the right owners with context for timely root cause analysis.

ROI Based Workload Segmentation and Insights (Quantify Business Value)

FinOps Framework Capabilities: Unit Economics, Allocation

Challenge

Teams have limited visibility into per-workload ROI makes capacity planning reactive instead of data-driven. They also might be requesting capacity increase without validated ROI or financial accountability. Business agility declines when long-term investments proceed without rapid pilot-based value validation.

Organizations struggle to demonstrate workload value within short evaluation windows (2–3 weeks) and reach conclusions on longer term business value. Significant effort required to segment workloads, allocate costs, and link usage to business outcomes.

Business Value

Most of the business value derived from this scenario is quantified using unit economics.

• Establish clear workload priorities by validating revenue impact and ROI within rapid milestone cycles.​
• Balance revenue-generating workloads against cost-optimization initiatives investments.​
• Reduce speculative capacity spending by requiring business case proof before long-term capacity commitments.​
• Enable data-driven resource allocation decisions based on per-workload financial performance metrics and trends.

High-Level Solution

• Use Snowflake Intelligence (Cortex AI Agents) for unit economic reports on workloads.​
• Segment workloads by criticality and revenue impact to prioritize optimization efforts on high-value workload clusters.​
• Right-size workload editions (e.g., migrate non-sensitive workloads to lower-cost Snowflake Product Edition like Standard or Enterprise Edition.
• Align data storage and access patterns with use-case lifecycle, archive cold/low-access data.

Note: Data has an intrinsic shelf life of actionability and access pattern depending on its use case. Some data, for example, is very likely to be stored and never read again, while others will likely be very hot.

Practical Steps

• Collect business unit reports, revenue targets, and cost thresholds to define workload ROI success criteria.​
• Provide workload metadata, usage history, and business goals to Snowflake Intelligence for analysis ​[doc].​
• Query Snowflake Intelligence to calculate unit economics, cost-per-query, and workload-level KPIs.​
• Validate computed metrics against company-defined ROI thresholds and investment benchmarks.​
• Generate milestone reports comparing workload value before and after pilot periods for stakeholder review.​
• Plan and implement changes based on stakeholder feedback.

Note: Snowflake Intelligence availability depends on tier and region. The core SQL-based approach using QUERY_ATTRIBUTION_HISTORY and WAREHOUSE_METERING_HISTORY is the baseline approach. Snowflake Intelligence is an accelerator, not a prerequisite. Snowflake Intelligence was announced in early 2025 and is a rapidly evolving product.

Personas/Roles Involved

• VPs from Business Units provide KPIs and unit economics specifications
• FinOps team/practitioners
• Data and Analytics Teams
• Solutions Architects

KPIs

1. FinOps unit costs, including:
   1. Cost per query
   2. Cost per warehouse
   3. Credit consumption per workload
   4. Unit cost per data processed
   5. Networking costs
2. Business KPIs, including
   1. CAC
   2. LTV
3. Product-specific KPIs that make sense for the specific product and/or workload the company is running. These may include costs and/or revenues per: monthly active users, searches run, documents stored, activities performed, etc.

Cost Drivers

• Token consumption by Snowflake Intelligence Agents, Vector embeddings, and LLM-based workload analysis queries
• Query complexity, concurrency, warehouse sizing, and auto-scaling behavior across workload clusters.​
• Data volume per workload, retention policies, cloning overhead, and access patterns (hot vs. cold data).​
• Cross-region transfers, data sharing costs, and external data integration per workload

Data Sources Needed

• Compute Usage: QUERY_HISTORY, QUERY_ATTRIBUTION_HISTORY, WAREHOUSE_METERING_HISTORY, WAREHOUSE_LOAD_HISTORY for per-query and per-warehouse cost attribution.​
• Storage Usage: STORAGE_USAGE, DATABASE_STORAGE_USAGE_HISTORY, TABLE_STORAGE_METRICS for data volume and retention cost analysis.​
• Data Pipelines: PIPE_USAGE_HISTORY, COPY_HISTORY, SNOWPIPE_STREAMING_FILE_MIGRATION_HISTORY for ingestion workload costs.​
• Serverless & AI Services: CORTEX_AISQL_USAGE_HISTORY, CORTEX_ANALYST_USAGE_HISTORY, SERVERLESS_TASK_HISTORY for token and serverless credit consumption.​
• Cloud Services & Governance: METERING_HISTORY, METERING_DAILY_HISTORY, ACCESS_HISTORY for overall cost reconciliation and audit trails.

Note: Data represents a point-in-time view only. For current schema definitions across compute, storage, pipeline, and AI usage views, refer to the Snowflake Account Usage Documentation. For Snowflake Intelligence capabilities and availability, refer to the Snowflake Intelligence Getting Started Guide.

Risks to Mitigate

• Incomplete workload tagging leads to inaccurate cost attribution and misleading ROI calculations across business units. Mitigate by overtagging.
• Short milestone windows may not capture full workload cost patterns, skewing business value conclusions. Mitigate by always interpreting the result of pilots next to the business value of longer term projects/investments.
• Underestimating hidden cost drivers (cloud services, data transfer, AI tokens) distorts total workload cost analysis. Mitigate by defining KPIs for all 3 recommended categories.

Dependencies

• Cross-functional alignment to prioritize workloads based on financial impact
• Teams agree to maintain accurate workload tagging and adhere to governance standards
• Business stakeholders commit to providing ROI validation for capacity requests
• ACCOUNT_USAGE schema access permissions granted to FinOps practitioners via USAGE_VIEWER or GOVERNANCE_VIEWER database roles

Workload Configuration Optimization (Optimize Usage and Cost)

FinOps Framework Capabilities: Usage Optimization

Challenge

Poor pruning, ineffective clustering, and unnecessary repetitive, redundant computation can dramatically increase Snowflake compute costs.

Business Value

Small technical decisions, such as table clustering strategies or model execution frequency can have outsized, long-term financial impact.

High-Level Solution

Identify savings opportunities through more efficient workload configurations (reducing query frequency and processing only new data) and table configurations.

Doing so will enable effective pruning (the process by which Snowflake skips reading micro-partitions that are not relevant to the query) and clustering (the process of organizing or ordering data in a table so that pruning can be effective).

Practical Steps

Validate pruning effectiveness on expensive queries

• Pruning is the process by which Snowflake skips reading micro-partitions (small chunks of table data) that are not relevant to a query.
• Start by reviewing your most compute-intensive queries using Snowflake’s Query Profile.
• Look at partitions scanned versus partitions total. High scan ratios indicate that pruning is not effective, which means your queries are scanning more data than needed, an opportunity to improve performance and reduce cost.

Identify high-value clustering candidates

• Clustering determines how data is organized across micro-partitions. Well-clustered tables group similar values together, which improves pruning and speeds up queries.
• Use Query History or Access History to find columns frequently used in filters, joins, or merge predicates. Prioritize columns with high cardinality and consistent usage patterns, as these provide the greatest pruning benefits.
• Clustering columns with many distinct values such as timestamps or IDs will be more effective than on a categorical column with 2 distinct values like a true or false, which will only achieve 50% pruning at most

Leverage natural clustering wherever possible

• Natural clustering occurs at no additional clustering service cost based on how data is ingested. It happens automatically when data is inserted sequentially. Leverage Snowflake’s natural clustering by aligning ingestion patterns with common query filters (for example, time-based columns such as created_at). This provides the best cost-to-performance ratio with no ongoing operational overhead.

Apply manual sorting for static or rarely updated tables

For tables that are rarely updated, you can manually reorganize data using commands like:

CREATE OR REPLACE TABLE my_table CLUSTER BY (order_date) AS

SELECT * FROM my_table ORDER BY order_date;

• This produces a well-clustered table that improves pruning. Avoid this on tables with active writes, as concurrent changes may reduce effectiveness.

Use automatic clustering selectively and monitor cost

• Automatic clustering is a managed Snowflake service that actively reorganizes micro-partitions to cluster a table along specified columns.
• Enable Snowflake’s automatic clustering service only when query patterns justify it.
  • It is effective even when data is inserted in a random order or query patterns don’t match insertion patterns.
  • However, it comes at extra cost because Snowflake must read and rewrite micro-partitions in the background.
  • Continuously evaluate both query performance improvements and clustering service costs to ensure a positive ROI.
  • Monitor the cost using WAREHOUSE_METERING_HISTORY to ensure the performance gains outweigh the compute spent on reorganizing partitions.

Reduce unnecessary recomputation in transformation workloads

• Full-refresh transformations (reprocessing entire tables) are common but expensive. Review scheduled queries and data models to confirm they are running no more frequently than required. Review the actual consumption cadence of each scheduled workload: hourly transformations feeding dashboards that are reviewed once daily represent unnecessary compute spend.
• For large datasets, replace full refresh patterns with incremental processing to avoid repeatedly scanning unchanged data.

Design queries to maximize pruning and filtering

• Query design affects how effectively Snowflake can prune micro-partitions:
  • Apply filters as early as possible in CTEs or subqueries.
  • Avoid using functions on filtered columns, which can prevent pruning.
  • Include well-clustered columns in join and merge predicates where it does not affect output, so Snowflake can skip irrelevant micro-partitions.
• Example: If merging updates into a large table, adding a filter on a clustered order_date column can drastically reduce scanned partitions.

Personas/Roles Involved

• Snowflake Administrator/Data Platform Engineer
• Workload/Product Owners

KPIs

• Data scanned per query – indicates how much data Snowflake reads from micro-partitions; reduced scanning shows effective pruning.
• Partitions scanned / partitions total – a technical metric showing pruning effectiveness.
• Query execution time – measures performance improvements from clustering, pruning, and optimized queries.
• ROI of optimization initiatives – estimated cost savings from pruning/clustering changes compared to engineer effort or clustering service cost.

Cost Drivers

• Data volume scanned: Queries that read large numbers of micro-partitions increase compute usage and costs.
• Inefficient table structures: Poor clustering or disorganized tables lead to more data being scanned per query.
• Query frequency: Frequently running reports or transformations (hourly vs daily) multiply compute costs.
• Full-table recomputations: Processing all rows every time instead of incremental updates wastes resources.

Note: Data represents a point-in-time view only. For current guidance on micro-partition clustering, pruning behavior, and automatic clustering costs, refer to the Snowflake Clustering and Micro-Partitions Guide and the Snowflake Query Profile Guide.

Data Sources Needed

• Query History / Access History: To identify which queries are most expensive, frequently run, or scan excessive data.
• Table Metadata: Micro-partition statistics, clustering depth, and column cardinality information to determine optimization candidates.
• Warehouse Usage Metrics: From Snowflake’s WAREHOUSE_METERING_HISTORY to track compute spend per warehouse, per time period.

Risks to Mitigate

• Manual sorting or table replacement operations on actively updated tables could temporarily disrupt data or overwrite new rows.
• Changes to table organization or filters could unintentionally affect query results if not tested.
• Failing to account for all users or queries could lead to pruning and clustering choices that don’t deliver expected cost savings.
• Cost of automation: Automatic clustering and frequent transformations can themselves become expensive if not monitored

Dependencies

• Cross-team coordination: Between Data Platform Engineers / Snowflake Administrators and Workload / Product Owners to prioritize workload optimizations based on financial impact
• Stable table schemas: Frequent schema changes can invalidate clustering or pruning strategies.

Anti-Pattern Identification and Resolution (Optimize Usage and Cost)

FinOps Framework Capabilities: Usage Optimization

Challenge

Persistent query and infrastructure anti-patterns such as full-table scans, Cartesian joins, repeated cache-busting queries, and oversized warehouses for lightweight workloads silently compound credit consumption over time. Unlike anomalies, which represent sudden spikes, anti-patterns are chronic inefficiencies that become normalized in dashboards and forecasts. Without systematic detection, they accumulate into material technical debt that is expensive to unwind at scale.

Business Value

Systematically identifying and resolving anti-patterns delivers durable, compounding cost savings rather than one-time fixes. Eliminating a single high-frequency anti-pattern, such as a BI tool issuing uncached full-table scans on every refresh can reduce credits consumed by that workload by 40–80% and improve query performance simultaneously, increasing both financial and operational efficiency.

High-Level Solution

ACCOUNT_USAGE.QUERY_INSIGHTS and QUERY_HISTORY to systematically surface recurring query-level anti-patterns across warehouses. Combine automated detection with a triage and remediation workflow that assigns each identified anti-pattern to a workload owner for resolution. Track resolution progress and credit savings as a standing FinOps optimization metric.

Practical Steps

1. Query QUERY_INSIGHTS for systemic anti-patterns: Filter for insight_type_id values indicating inefficiencies (full-table scans, join explosions, disk spills) across queries with total_elapsed_time >= 5 minutes and start_time within the last 30 days.
2. Identify top offenders by credit cost: Cross-reference QUERY_HISTORY with QUERY_ATTRIBUTION_HISTORY to rank anti-pattern queries by credit consumption; prioritize the top 10 by spend.
3. Assign to workload owners: Map queries to teams via USER_NAME, ROLE_NAME, QUERY_TAG, or warehouse ownership; create a remediation backlog with assigned owners.
4. Remediate: Apply fixes appropriate to the anti-pattern type, add clustering keys for full-table scans, rewrite joins to eliminate Cartesian products, enforce STATEMENT_TIMEOUT_IN_SECONDS for runaway queries, or adjust warehouse policies.
5. Track credit savings: Re-measure credit consumption for remediated query families after 30 days and report savings against the pre-remediation baseline.
6. Establish ongoing monitoring: Schedule a weekly QUERY_INSIGHTS review as a standing FinOps activity to prevent anti-pattern recurrence.

Personas/Roles Involved

• FinOps Practitioner: runs anti-pattern detection queries, maintains the remediation backlog, and tracks savings.
• Data/Analytics Engineers: primary owners of query-level remediation (query rewrites, clustering changes, incremental pipeline updates).
• Snowflake Administrator: implements statement timeout policies and warehouse-level controls.
• Engineering Managers: accountable for ensuring their teams remediate assigned anti-patterns within agreed SLAs.

KPIs

• Number of active query-level anti-patterns by type — tracks systemic issues; target is declining trend over time.
• Credits saved from resolved anti-patterns — measures the direct financial impact of the optimization program.
• Anti-pattern recurrence rate — percentage of previously remediated patterns that reappear within 90 days; indicates whether fixes are durable.

Cost Drivers

• Full-table scans without pruning: Queries that scan all micro-partitions consume credits proportional to table size rather than result set; the most common and impactful anti-pattern.
• Cartesian and unfiltered joins: Join explosions that generate intermediate result sets orders of magnitude larger than inputs can exhaust warehouse memory and spill to disk, multiplying cost.
• Repeated identical queries without caching: BI tools or pipelines that disable query result caching or run parameterised queries that bypass the cache generate avoidable repeat executions.
• Oversized warehouses for simple workloads: Lightweight queries running on XL or larger warehouses consume credits at a dramatically higher rate than necessary.

Data Sources Needed

• ACCOUNT_USAGE.QUERY_INSIGHTS — surface-level performance diagnostics by insight_type_id; primary source for anti-pattern detection.
• ACCOUNT_USAGE.QUERY_HISTORY — query execution details including bytes scanned, execution time, spill volumes, and user/warehouse context.
• ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY — per-query credit consumption to quantify the cost of each anti-pattern.

Refer to the Snowflake Account Usage and Query Insights documentation as the primary reference.

Note: Data represents a point-in-time view only. For current QUERY_INSIGHTS insight type definitions, field availability, and anti-pattern detection capabilities, refer to the Snowflake Query Insights Guide and the QUERY_INSIGHTS Account Usage View.

Risks to Mitigate

• Anti-pattern detection based solely on elapsed time may flag intentional long-running ELT queries; validate with workload owners before classifying as an issue.
• Over-aggressive statement timeouts applied as a blanket anti-pattern control can terminate legitimate batch workloads; scope timeouts by warehouse and user role.
• Excessive instrumentation and alerting can itself generate compute overhead; scope monitoring queries to appropriate time windows and use scheduled tasks rather than real-time polling.

Dependencies

• ACCOUNTADMIN or SNOWFLAKE.USAGE_VIEWER role to query ACCOUNT_USAGE.QUERY_INSIGHTS and QUERY_ATTRIBUTION_HISTORY.
• Consistent QUERY_TAG or role/warehouse naming conventions to attribute anti-patterns to owning teams.
• Engineering team agreement on remediation SLAs and accountability model.

Token Usage Optimization (Optimize Usage and Cost)

FinOps Framework Capabilities: Usage Optimization

Challenge

• Runaway Model Scale and Complexity: Foundation models have grown from millions to trillions of parameters, multiplying compute intensity and storage demands with each generation.
• Multidimensional Cost Attribution and Ownership: Cost structure for Cortex AI features follows a usage-based pricing model, with costs tied to compute, storage, and token consumption.
• Operational Risk from Ungoverned Usage: Complex prompts, premium models, and high-frequency workloads trigger token surges; idle endpoints create shadow waste without a resource limit.

Business Value

• Real-time Analytics and Insights: Cortex AI enables the delivery of real-time analytics, document intelligence, and automated insights directly within business workflows, accelerating decision cycles and unlocking time-sensitive opportunities.
• Enhanced Decision-Making and Democratization: AI-powered data products and language-driven analytics democratize data access, empowering cross-functional teams to make faster, more informed decisions without specialized expertise.

High-Level Solution

• Enforce tagging and ownership: Tag all AI endpoints, warehouses, and projects with team, environment, and cost center, and assign explicit owners.
• Shift to token-based economics: Standardize on token and credit-based unit costs for Cortex AI, enabling granular budgeting and optimization as AI usage scales.
• Architect with model selection logic: Use policy-driven model routing to default to the smallest effective model, escalating to premium models only when required.
• Integrate fine-tuning and distillation: Apply task-specific fine-tuning and model distillation to create smaller, efficient variants, lowering per-request token and compute requirements.
• Upskill on fine-tuning and distillation: Train data science and engineering teams on model fine-tuning and distillation so they can deploy smaller, task-specific models that preserve quality while reducing per-request token and compute consumption.​

Practical Steps

• Begin with a small or X-Small warehouse for most Cortex operations, LLM functions, Document AI, and Cortex Search setup. Upsizing rarely accelerates LLM processing, while substantially raising compute credits consumed.
• Minimize data transfer by processing directly within Snowflake using Snowpark or Snowflake Datasets, eliminating excess I/O. When preparing data for AI models, leverage efficient formats such as NumPy arrays or Arrow tables.
• Default to the smallest effective model, minimize prompt length, and regularly review high-frequency workflows and retiring unused endpoints. Use fault-tolerance features like TRY_COMPLETE to avoid accidental overuse.
• Trim extraneous input text, use the COUNT_TOKENS function to verify token usage, and avoid repetition or overly large context windows. Keep prompt templates simple to prevent using more tokens than needed.
• Use the COUNT_TOKENS helper function to evaluate token usage

  • SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic', 'Is Snowflake built on cloud MPP architecture?');

• Configure real-time spend dashboards and alert thresholds for Cortex usage to detect budget overruns, token spikes, and anomalous workloads as they occur.

Personas/Roles Involved

• Data Science Team
• AI/ML/Agentic AI Engineering Teams

KPIs

• Track credit usage per query/token, total credits consumed, and token counts per request to quickly identify inefficient prompts, verbose outputs, and high-cost workflows. Example:

• SELECT
    (input_tokens + output_tokens) * ai_model
    + serving_compute
    + embedding_compute
    + warehouse_compute AS cortex_cost
  FROM cortex_usage_summary;
  

• Regularly identify and retire inactive resources, such as Cortex Search Indexes or model endpoints with no queries or traffic.

Cost Drivers

• Model selection and complexity: Choosing larger or premium models significantly increases per-query credit spend; defaulting to smaller models and escalating only when necessary drives efficiency.​
• Endpoint serving and concurrency: Real-time Cortex endpoints incur baseline serving charges that rise with concurrency and uptime; idle or over-provisioned endpoints consume credits without delivering value.​
• Vector indexing and document processing: Building, refreshing embeddings, and processing documents for Cortex Search and Document AI create ongoing compute and storage costs that scale with data volume.

Data Sources Needed

• Cortex Functions usage views: Access CORTEX_AISQL_USAGE_HISTORY to capture per-query and hourly token and credit consumption by function and model, enabling precise identification of expensive operations.​
• Cortex Analyst usage: Query CORTEX_ANALYST_USAGE_HISTORY to track hourly credit consumption aggregated by user and message count, enabling cost accountability and identification of high-volume conversational analytics workflows.​​
• Search services usage: Access CORTEX_SEARCH_SERVING_USAGE_HISTORY and CORTEX_SEARCH_DAILY_USAGE_HISTORY to monitor embedding token consumption and serving credit charges for Cortex search and retrieval operations.​
• Document AI usage: Pull CORTEX_DOCUMENT_PROCESSING_USAGE_HISTORY to capture credits consumed per page for Document AI functions like PREDICT_DOCUMENT and PARSE_DOCUMENT, revealing costs driven by content volume and processing complexity.​
• Fine-tuning metrics: Query CORTEX_FINETUNING_USAGE_HISTORY to track hourly token counts and training credit consumption for custom model development, showing the cost and efficiency of task-specific model optimization.​
• Account and org-level AI metering: Query ACCOUNT_USAGE.METERING_HISTORY and ORGANIZATION_USAGE.METERING_DAILY_HISTORY filtered by SERVICE_TYPE=’AI_SERVICES’ to aggregate enterprise AI spending across accounts and track trends over time.

Note: Data represents a point-in-time view only. For current Cortex function pricing, model availability, and usage view field definitions across CORTEX_AISQL_USAGE_HISTORY, CORTEX_ANALYST_USAGE_HISTORY, and related views, refer to the Snowflake Cortex LLM Functions Guide and the CORTEX_AISQL_USAGE_HISTORY Account Usage View.

Risks to Mitigate

• Overprovisioned or idle AI endpoints: Underutilized Cortex endpoints and vector indexes continue incurring baseline serving credits without delivering value; establish regular usage reviews and scheduled shutdown policies.​
• Hallucinations and output accuracy: Inaccurate or hallucinated LLM outputs can propagate into downstream systems, causing operational errors, costly rework, and downstream cost amplification.​
• Monitoring blind spots and governance gaps: Weak tagging, unclear ownership, and limited native guardrails delay detection of anomalies and create unchecked budget growth; enforce consistent tagging and dashboard-driven accountability.

Dependencies

• Tooling and cost visibility platforms: Real-time dashboards, usage views, and monitoring tools exposing Cortex functions, Cortex Analyst, Search, and Document AI metrics are critical to detect anomalies and prevent budget drift.​
• Semantic models and data catalog: Well-structured semantic models, clean metadata, and consistently tagged resources enable accurate cost attribution, governance policies, and policy-driven model selection.

Architecting the Data Cloud Platform for FinOps Success

Designing a Data Cloud Platform requires a fundamental shift from provisioning fixed capacity to architecting for variable, value-driven consumption. In a greenfield environment, the architectural choices made on day one, specifically regarding compute isolation and storage lifecycle will dictate the organization’s ability to control unit economics for years to come. Practitioners must recognize that the Data Cloud Platform does not exist in a vacuum. The financial architecture must account for the granular, near real-time cost and usage of the entire data value chain, including upstream data ingestion, external object storage, and any downstream visualization tool costs that sit outside the primary platform. This will better enable a complete picture for value based decisions to be made.

Whether adopting a fully packaged platform like Snowflake or Databricks, or a custom-built solution, the architecture must facilitate transparency rather than obscure it. Packaged platforms abstract complex infrastructure into simplified “credits” or “units”; while this accelerates deployment, it creates a risk of disconnecting engineering actions from financial consequences. Therefore, the technical design must enable granular visibility by default, leveraging native capabilities such as Snowflake’s separation of storage and compute to ensure that every credit consumed can be traced back to a specific business purpose, rather than aggregated into a generic IT overhead cost bucket.

Finally, the Data Cloud Platform architecture must align seamlessly with the organization’s broader FinOps standards, including when adopted, alignment to the FinOps Open Cost and Usage Specification (FOCUS), for financial interoperability. Centralized policies regarding cost allocation, hierarchy definition, and financial reporting must be mapped to the platform’s resource structure before the first dataset is loaded. If the central FinOps team allocates costs by “Cost Center,” the Data Cloud Platform team must architect their virtual warehouses or computing clusters to mirror this structure. This alignment ensures that the platform is not just technically sound, but financially integrated, paving the way for advanced capabilities like AI readiness and automated chargeback.

Key Considerations for the FinOps & Data Cloud Platform Partnership

To build a cost-efficient foundation, FinOps, Finance, Product and Engineering/ Data Cloud Platform teams must collaborate to answer these critical architectural questions:

What is the Total Cost of Ownership (TCO) boundary?

Define if the Data Cloud Platform budget includes just the core platform (e.g., Snowflake, Databricks) or the end-to-end lifecycle, including ELT tools (e.g., Fivetran), external storage (e.g., S3/Blob), and visualization licenses.

How does Data Origin influence Ingestion architecture?

Determine if data is migrating from on-premises (requiring heavy initial load) or streaming from other clouds. Architecting for incremental loading vs. full refreshes significantly impacts compute uptime and ingress costs.

How will Workload Isolation be enforced?

Avoid shared, monolithic compute resources. For example, in Snowflake, design Virtual Warehouses by workload type (e.g., LOADING_WH, REPORTING_WH, DS_WH) or project to prevent “noisy neighbors” and ensure clear cost attribution.

What is the Granularity of Attribution?

Decide what needs to be measured to drive behavior. If you need to chargeback to a specific department, the architecture must support tagging at the warehouse or query level to link execution cost to business value.

Are we leveraging Cloud-Native capabilities vs. SQL Legacy patterns?

Ensure engineers are not applying “fixed hardware” logic to the Data Cloud Platform. Architect to use auto-suspend, zero-copy cloning, and ephemeral compute rather than keeping resources running 24/7 “just in case.”

Is the Metadata Strategy AI-Ready?

Future cost optimization and AI use cases require clean metadata. Establish a unified tagging governance framework now to ensure data lineage and cost categorization are automated, rather than retrofitted later.

Acknowledgments

We’d like to thank the following people for their work on this Paper:

Marcos Palma

Oracle

Rich Gibbons

Synyega

Alessandro Bellini

Max Mara Fashion Group

Frank Contrepois

FinOps Lead

Lorant Kiss

Delivery Hero

Priyanka Pandey

Delivery Hero

Simarpreet Arora

Snowflake

Cory Syvenky

Teck Resources Limited

Ermanno Attardo

Trilogy

Colleen Spence

Sedgwick

Alex Landis

Snowflake

Lindbergh Matillano

Avalara

Martin Faulkner

John Lewis Partnership

Marthe Naudts

Espresso AI

Velu Natarajan

GoodRx

Dhara Kansagara

BetaNXT

Tobi Olabode

NEXT