Skip to main content
Your progress
0 of 4 lessons complete0%
T2 / M2.12 / L1 OF 4 / Engineer TIER / 9 min

Connecting Snowflake

Outcome

By the end of this lesson, you will be able to connect a Snowflake account as a standalone connection, choose between key-pair JWT and PAT authentication, and predict which of the nine discovered resource types appear at the top level and which are parented.


TierEngineer
JTBD”Get Snowflake spend into the same cost surface as my cloud estate.”
PersonasPlatform Engineer · Data Engineer · FinOps Lead
PrerequisitesT1.M1.1 (connecting a cloud account)
Time9 minutes
Bloom verbConnect (Apply), Choose (Evaluate), Predict (Apply)

1. Concept

Snowflake is a standalone connection, not something that rides an existing AWS, GCP or Azure account. It gets provider="snowflake", its own credentials row, and its own place in the account list.

Terminal window
THE CONNECTION MODEL, COMPARED
Databricks on AWS/GCP standalone connection (own creds)
Databricks on Azure rides the Azure subscription
Snowflake ALWAYS standalone, on every cloud
ROSA / OpenShift standalone, against an OCM org

The underlying cloud is derived from the account host rather than asked for. A Snowflake account on AWS, one on GCP and one on Azure all connect the same way; ZopNight reads which cloud it sits on from the host and records it. You do not need the corresponding cloud account connected, and connecting it does not merge the two.

Two authentication methods

Terminal window
KEY-PAIR JWT recommended
You generate an RSA key pair, register the public key on
a Snowflake user, and give ZopNight the private key.
No shared secret travels, and rotation is a key swap.
PAT (personal access token)
A Snowflake-issued token. Simpler to obtain, and it
carries the issuing user's own privileges.

The choice mirrors the pattern everywhere else in ZopNight: the keyless-ish option is recommended, and the token option exists because it is faster to get through a change-approval process.

The nine resource types

Terminal window
TOP LEVEL
account the Snowflake account itself
warehouse compute. This is where the money is.
database a logical container
user a Snowflake user
resource-monitor Snowflake's own credit guardrail
PARENTED TO THEIR DATABASE
table
materialized-view
stage
pipe

The parented four fold the schema into the UID rather than discovering schemas as their own type. That keeps the hierarchy two levels deep instead of three, which matters when a warehouse-heavy account has thousands of tables.

Where discovery reads from

Terminal window
SNOWFLAKE.ACCOUNT_USAGE the account-usage views
+ SHOW queries for live object state
Everything ZopNight knows about a Snowflake account comes
from queries the connected user is allowed to run. There is
no control-plane API separate from the warehouse, which has
one consequence worth planning for: discovery itself
consumes a small amount of compute.

What this increment does not cover

Worth stating plainly so nobody builds a plan on it:

Terminal window
NO SECURITY POSTURE
There are no Snowflake security or compliance rules in
this increment. Recommendations are cost-optimisation
only. If you need "which users have ACCOUNTADMIN", that
is not here.

Sizing the permission you grant

The connected user needs to read SNOWFLAKE.ACCOUNT_USAGE and run SHOW queries across the objects you want discovered, plus OPERATE on the warehouses you intend to schedule. Granting more than that buys nothing: there is no rule that reads anything else.


2. Demo

A first connection, and the shape of what came back:

Terminal window
CONNECT
Provider: Snowflake
Account host: xy12345.us-east-1.snowflakecomputing.com
-> cloud derived: AWS, us-east-1
Auth: key-pair JWT
User: ZOPNIGHT_SVC
Role: ZOPNIGHT_READER (+ OPERATE on warehouses)
FIRST DISCOVERY, 4 minutes later
account 1
warehouse 14 <- the cost surface
database 22
user 61
resource-monitor 3
─────────────────────────
table 4,180 parented to their database
materialized-view 37
stage 19
pipe 8
WHAT THE TEAM EXPECTED AND DID NOT GET
- schemas as their own rows. They are folded into the
table/view/stage/pipe UIDs instead.
- roles and grants. Not discovered; there is no security
posture in this increment.
- query history as a resource. Not a resource type;
usage feeds cost, not inventory.
THE ONE SURPRISE WORTH NOTING
61 users appeared, and none of them cost anything. Users
are discovered because several warehouse recommendations
need to reason about who is driving a warehouse, not
because a user carries spend.

3. Hands-on (6 min)

Terminal window
1. Before connecting, decide the auth method:
Can you register a public key on a Snowflake user? Y / N
If N, PAT is your path. Note who has to approve it:
______________________________________________
2. Identify your account host and read the cloud off it:
host: ________________________ cloud: ________
3. Predict, before discovery runs:
warehouses you expect: ______
databases you expect: ______
Compare to what appears. A warehouse count that is
higher than you expected is the most common finding,
and usually means per-team warehouses nobody retired.
4. After discovery, filter Resources to type=warehouse
and sort by cost. What share of your Snowflake spend
sits in the top 3 warehouses? ______%
5. Confirm what is NOT there: search for a role or a
grant. Record what you would still need another tool
for: ______________________________________

4. Knowledge check

Q1

A team runs Snowflake on Azure and already has their Azure subscription connected to ZopNight. To get Snowflake spend in, they should:

A. Create a separate standalone Snowflake connection
B. Nothing; it will be discovered through the Azure subscription, like Azure Databricks
C. Use the generic API integration
D. Connect it as a Databricks-style credential on the Azure account

Show answer

Correct: A. Snowflake is always standalone regardless of the underlying cloud, and the cloud is derived from the account host rather than from a linked cloud account. Azure Databricks is the exception that makes this confusing: that one genuinely rides the Azure subscription. Snowflake never does, on any cloud.

Q2

Which four Snowflake resource types are parented rather than top-level?

A. warehouse, database, user and resource-monitor, which are the four billable ones in the catalog
B. account, warehouse, database, user
C. table, materialized-view, stage and pipe, all parented to their database with the schema folded into the UID
D. Only tables

Show answer

Correct: C. Schemas are not discovered as their own type. Folding the schema into the UID keeps the hierarchy two levels deep, which matters in an account with thousands of tables.

Q3

A security team asks for a report of Snowflake users holding ACCOUNTADMIN. ZopNight’s Snowflake integration:

A. Does not
B. Provides it under compliance recommendations
C. Provides it through the IAM Import feature
D. Provides it only with PAT authentication

Show answer

Correct: A. This increment ships cost-optimisation recommendations only and no security posture, so roles and grants are outside its scope even though users are discovered. Users are discovered because warehouse recommendations reason about who drives a warehouse, not to support access review. Saying so early is better than having the gap found during a security review.


5. Apply

Connect your Snowflake account from Cloud Accounts, choosing key-pair JWT unless your change process makes a PAT materially faster.

Then go straight to the warehouse list. Fourteen warehouses where you expected six is the normal first finding, and it is usually the largest single savings opportunity in the account.


Glossary terms touched

Standalone connection · Key-pair JWT · ACCOUNT_USAGE · Virtual warehouse


Start with the bill.

Foundations takes about five hours. The first lesson is nine minutes.

Open curriculum. No login. No paywall. 290 lessons across 7 courses, three publicly verifiable credentials. Read it on the train, take the exam on a Saturday, list the credential on your résumé Monday.

5h median time to finish Foundations
0 logins, paywalls, or marketing forms
open curriculum, public credential verifier
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·