Skip to main content
Vantage integrates with your Snowflake account through a secure, read-only user that has access to Snowflake usage tables. Optionally, you can create a specific schema for the Vantage user. Vantage requires read-only access to the following tables:
As a best practice, it is suggested you create a schema specifically for the vantage user. Note, however, that this is optional. See the steps below for details on how to create this schema.
https://assets.vantage.sh/docs/logos/logo-icon-snowflake.svg

Want to query Vantage data inside Snowflake?

This page covers connecting Snowflake so Vantage can ingest Snowflake costs. Snowflake Data Sharing goes the other direction: it gives your Snowflake warehouse read-only SQL access to your Vantage cost data through a Secure Data Share.

​
Connect Your Snowflake Account

​
Prerequisites

​
Snowflake IP Allowed List

If your Snowflake cluster uses an IP allow list for access control, you will need to add the following IPs to that allowed list: 
54.87.66.45
3.95.43.133
54.162.3.72
44.199.143.63
3.218.103.23

​
Snowflake Schema for Vantage

After creating the below schema, you can add the required views to that schema and grant the vantage user access to the schema.
The below commands are based on the Snowflake documentation.
1
From the top navigation in Vantage, click Settings.
2
On the left navigation, select Integrations and select Snowflake.
3
The Snowflake integrations page is displayed. Ensure you are on the Connect tab.
4
Copy the code that’s provided under Create Vantage User and Role to Snowflake. This SQL creates a user named vantage, a role named vantage, and a warehouse named vantage. It also grants the necessary permissions.
Vantage automatically generates an RSA public key for you to use when creating the Vantage user and role. You need to copy the code directly from the Vantage integration page to add the RSA key.
If your security policy requires periodic credential rotation, or if you ever need to replace this key, you can rotate Snowflake RSA keys later from the Vantage console without recreating the integration.
Sample of code. Copy directly from Vantage console to get RSA key.
USE role accountadmin;
CREATE DATABASE vantage;
CREATE ROLE vantage;
CREATE USER vantage;
GRANT ROLE vantage to user vantage;
GRANT ROLE vantage to role accountadmin;
CREATE WAREHOUSE vantage;
GRANT ALL ON WAREHOUSE vantage TO ROLE vantage;
ALTER USER vantage SET DEFAULT_WAREHOUSE=vantage, DEFAULT_ROLE=vantage;
ALTER USER vantage SET password='';
ALTER USER vantage SET RSA_PUBLIC_KEY='{YOUR_RSA_KEY_GENERATED_BY_VANTAGE}';
5
Copy the next code block to set up the Vantage-specific schema to read billing and usage data from your account.
USE WAREHOUSE vantage;
DROP VIEW IF EXISTS VANTAGE.PUBLIC.QUERY_HISTORY;
CREATE VIEW VANTAGE.PUBLIC.QUERY_HISTORY AS
SELECT QUERY_ID, QUERY_TEXT, WAREHOUSE_SIZE, QUERY_PARAMETERIZED_HASH, USER_NAME, WAREHOUSE_ID, WAREHOUSE_NAME, ROLE_NAME, TOTAL_ELAPSED_TIME, END_TIME, QUERY_TAG
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY;
DROP VIEW IF EXISTS VANTAGE.PUBLIC.WAREHOUSE_METERING_HISTORY;
CREATE VIEW VANTAGE.PUBLIC.WAREHOUSE_METERING_HISTORY AS
SELECT START_TIME, CREDITS_USED_COMPUTE, WAREHOUSE_ID, WAREHOUSE_NAME, ACCOUNT_LOCATOR, ORGANIZATION_NAME, REGION
FROM SNOWFLAKE.ORGANIZATION_USAGE.WAREHOUSE_METERING_HISTORY;
DROP VIEW IF EXISTS VANTAGE.PUBLIC.USAGE_IN_CURRENCY_DAILY;
CREATE VIEW VANTAGE.PUBLIC.USAGE_IN_CURRENCY_DAILY AS
SELECT USAGE_DATE, USAGE_IN_CURRENCY, ACCOUNT_NAME, ACCOUNT_LOCATOR, ORGANIZATION_NAME, REGION, CURRENCY, USAGE_TYPE
FROM SNOWFLAKE.ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY;
GRANT USAGE ON SCHEMA vantage.public TO ROLE vantage;
GRANT USAGE ON DATABASE vantage TO ROLE vantage;
GRANT SELECT ON ALL VIEWS IN SCHEMA vantage.public TO ROLE vantage;
6
Test your setup in Snowflake.
USE role vantage;
SELECT * FROM vantage.public.query_history LIMIT 1;
7
At the bottom of the Vantage console Snowflake integration page, click Add Connection.
8
Add the following information to the form:
  • Server URL: In the format <account_identifier>.<region>.snowflakecomputing.com.
  • Database: The name of the database the usage views are in (e.g., vantage).
  • Schema: The name of the schema the usage views are in (e.g., public).
  • Username set for the vantage user.
9
Click Connect Account.
After adding your integration, you will see the status of your integration change to Importing within the Vantage console. This status indicates that Vantage is actively importing your Snowflake cost data. It may take several hours to populate within Vantage depending on the query volume of your warehouse. See the Integration Status documentation for details on integration statuses.
As soon as costs are processed, they will be available on your All Resources Cost Report. If you decide to remove your Snowflake integration from Vantage, all costs associated with your Snowflake integration will be removed from the Vantage console.

​
Next Steps - Manage Workspace Access

Once the import is complete and the integration status changes to Stable, you can select which workspaces this integration is associated with. See the Workspaces documentation for information.

​
Rotate Snowflake RSA Keys

You can rotate the RSA key pair for an existing Snowflake integration from the Vantage console. This lets you add and test a secondary key before replacing the primary key that Vantage uses to connect to Snowflake. Before you begin, make sure you have permission to manage integrations in Vantage and a Snowflake role that can run ALTER USER for the Snowflake user configured on the Vantage integration.
Copy the SQL commands directly from your Vantage console. The examples below show the shape of each command, but Vantage generates keys that are unique to each Snowflake connection.
1
In Vantage, navigate to your Snowflake integration:
  • From the top navigation, click Settings.
  • On the left navigation, select Integrations and select Snowflake.
  • Click the Snowflake connection you want to rotate.
2
In the Secondary Keys section, click Create Secondary Key Set. Vantage creates a new secondary RSA key pair and displays a Key Rotation checklist.
3
Copy the first generated SQL command from Vantage and run it in Snowflake. This adds the new public key as the user’s secondary public key.
ALTER USER vantage SET RSA_PUBLIC_KEY_2='{SECONDARY_PUBLIC_KEY_GENERATED_BY_VANTAGE}';
If your Vantage integration uses a Snowflake username other than vantage, use the username shown in the Vantage-generated command.
4
In Vantage, click Test Connection to verify that the secondary key works. The connection test may take a few minutes. Wait for it to complete before continuing.When the test succeeds, Vantage refreshes the page and enables Promote Secondary Keys. If the test fails, leave the primary key unchanged and follow the troubleshooting guidance below.
5
Copy the next generated SQL command from Vantage and run it in Snowflake. This makes the validated secondary key the primary public key in Snowflake.
ALTER USER vantage SET RSA_PUBLIC_KEY='{SECONDARY_PUBLIC_KEY_GENERATED_BY_VANTAGE}';
6
Copy the generated cleanup command from Vantage and run it in Snowflake. This removes the secondary public key from the Snowflake user.
ALTER USER vantage UNSET RSA_PUBLIC_KEY_2;
7
In Vantage, click Promote Secondary Keys. This updates Vantage to use the validated secondary private key as the primary key and clears the temporary secondary key set.
If you click Create Secondary Key Set again before promotion, Vantage replaces the previous unpromoted secondary key set. Run the latest SQL commands shown in the console.

​
Data Refresh

See the provider data refresh documentation for information on when data for each provider refreshes in Vantage.

​
View Snowflake Metrics on Cost Reports

You can import Snowflake SQL query results as business metrics to view alongside Cost Reports. Snowflake business metric imports reuse a connected Snowflake integration, but the configured Snowflake role must have SELECT access to the metric tables or views referenced in your query. See the Unit Costs documentation for more information.

​
Troubleshoot Snowflake Errors

Common integration errors are described below.

​
Promote Secondary Keys Is Disabled

The Promote Secondary Keys button is disabled until the secondary key passes the Vantage connection test. Complete the Test Connection step first. The test may take a few minutes; while it is running, Vantage shows a progress indicator and waits for the result. If the test times out, click Test Connection again. If it continues to time out, confirm that Snowflake is reachable from the Vantage IPs in the Snowflake IP Allowed List, then contact support@vantage.sh for assistance.

​
Snowflake Rejected the Secondary Key

If the Vantage connection test returns Snowflake rejected the secondary key., Snowflake rejected authentication with the secondary RSA key. The most common causes are:
  • The generated RSA_PUBLIC_KEY_2 command was not run in Snowflake.
  • The public key was copied incompletely or modified before being pasted into Snowflake.
  • The command was run for a different Snowflake user than the one configured in Vantage.
  • The command was run in a different Snowflake account than the one connected to Vantage.
  • A Snowflake network policy is blocking Vantage.
To resolve the issue:
1
In Vantage, copy the latest command from step 1 of the Key Rotation checklist.
2
In Snowflake, run the copied command again for the user shown in the command.
3
Confirm your Snowflake network policy allows the Vantage IPs listed in the Snowflake IP Allowed List.
4
Click Test Connection in Vantage again.

​
Connection Fails After Promoting Keys

If the Snowflake connection fails after you promote secondary keys in Vantage, confirm that you first ran the generated ALTER USER ... SET RSA_PUBLIC_KEY='...' command in Snowflake. Vantage should only be promoted after Snowflake’s primary public key has been updated to the new key. If Snowflake was not updated first, create a new secondary key set in Vantage and repeat the key rotation process using the latest generated SQL commands.

​
query_history Column Count Mismatch

Snowflake occasionally makes changes to the queries/tables that get used for cost and usage attribution, causing the views in Vantage to then be based on an old query. You may see an error in the Vantage console, similar to the below error: 
View definition for 'VANTAGE.PUBLIC.QUERY_HISTORY' declared 66 column(s), but view query produces 77 column(s).
To fix the issue, replace the three Vantage views in Snowflake and ensure the vantage user is granted permission on those views.
After you’ve completed the below steps, contact support@vantage.sh to reimport your Snowflake data.
USE WAREHOUSE vantage;
DROP VIEW IF EXISTS VANTAGE.PUBLIC.QUERY_HISTORY;
CREATE VIEW VANTAGE.PUBLIC.QUERY_HISTORY AS
SELECT QUERY_ID, QUERY_TEXT, WAREHOUSE_SIZE, QUERY_PARAMETERIZED_HASH, USER_NAME, WAREHOUSE_ID, WAREHOUSE_NAME, ROLE_NAME, TOTAL_ELAPSED_TIME, END_TIME, QUERY_TAG
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY;
DROP VIEW IF EXISTS VANTAGE.PUBLIC.WAREHOUSE_METERING_HISTORY;
CREATE VIEW VANTAGE.PUBLIC.WAREHOUSE_METERING_HISTORY AS
SELECT START_TIME, CREDITS_USED_COMPUTE, WAREHOUSE_ID, WAREHOUSE_NAME, ACCOUNT_LOCATOR, ORGANIZATION_NAME, REGION
FROM SNOWFLAKE.ORGANIZATION_USAGE.WAREHOUSE_METERING_HISTORY;
DROP VIEW IF EXISTS VANTAGE.PUBLIC.USAGE_IN_CURRENCY_DAILY;
CREATE VIEW VANTAGE.PUBLIC.USAGE_IN_CURRENCY_DAILY AS
SELECT USAGE_DATE, USAGE_IN_CURRENCY, ACCOUNT_NAME, ACCOUNT_LOCATOR, ORGANIZATION_NAME, REGION, CURRENCY, USAGE_TYPE
FROM SNOWFLAKE.ORGANIZATION_USAGE.USAGE_IN_CURRENCY_DAILY;
GRANT USAGE ON SCHEMA vantage.public TO ROLE vantage;
GRANT USAGE ON DATABASE vantage TO ROLE vantage;
GRANT SELECT ON ALL VIEWS IN SCHEMA vantage.public TO ROLE vantage;

​
Invalid username or password Error

If your Snowflake integration shows an Invalid username or password error in the Vantage console, the cause is almost always a username or RSA public key issue, not a password issue. Snowflake returns the Invalid username or password message for several underlying authentication failures, including:
  • JWT_TOKEN_INVALID_PUBLIC_KEY_FINGERPRINT_MISMATCH — the RSA public key configured in Snowflake does not match the public key generated by Vantage.
  • INCOMING_REQUEST_BLOCKED — Snowflake rejected the signed JWT, typically due to a key mismatch or a network policy.
  • A vantage user that does not exist in your Snowflake account.
A public key mismatch can occur if:
  • The public key was manually modified in Snowflake.
  • The integration was recreated in Vantage, generating a new public key.
  • The public key was incorrectly copied during initial setup.
To resolve this issue:
1
Navigate to your Snowflake integration in Vantage:
  • From the top navigation, click Settings
  • On the left navigation, select Integrations and select Snowflake
  • Click on your Snowflake connection to open the Manage Connection page
2
Copy the Primary Public Key from the Vantage console. This is the RSA public key that Vantage generated for your integration.
3
In Snowflake, update the vantage user’s RSA public key to match the one from Vantage:
USE role accountadmin;
ALTER USER vantage SET RSA_PUBLIC_KEY='{YOUR_RSA_KEY_GENERATED_BY_VANTAGE}';
Replace {YOUR_RSA_KEY_GENERATED_BY_VANTAGE} with the exact public key copied from the Vantage console.
4
Verify the connection is working. The error should be resolved once the public keys match.
The public key must match exactly between Vantage and Snowflake. Ensure you copy the entire key from the Vantage console without any modifications or extra characters.
If you continue to encounter errors after following these steps, contact support@vantage.sh for assistance.

​
Snowflake Reporting Dimensions

On Snowflake Cost Reports, you can filter across several dimensions:
  • Account (account name)
  • Category (e.g., Data Cloud Data Transfer)
  • Metadata (e.g., environment is staging)
  • Region (e.g., AWS EU West 1)
  • Organization (organization name)
  • Service (e.g., Data Cloud)
  • Tags: Includes Virtual Tags created in Vantage for this provider. The following tags are also available for filtering and grouping. These are derived from columns in the Snowflake usage views Vantage reads (e.g., QUERY_HISTORY), not from Snowflake object tags.
    • user: The user who ran the query (from USER_NAME), allowing you to filter and group costs by user.
    • warehouse: The warehouse name (from WAREHOUSE_NAME), allowing you to filter and group costs by warehouse.
    • role: The role name when present (from ROLE_NAME), allowing you to filter and group costs by role.
    • query_tag: The session query tag when present (from the QUERY_TAG column in query history). This can be a single value or, if set as JSON (e.g., ALTER SESSION SET query_tag = '{"team":"eng"}'), parsed into tag key/value pairs for filtering and grouping.
  • Charge Type (e.g., Usage)

​
Active Resources

Snowflake queries are synced as active resources and available in resource reports.