5.2 Managed Reader Accounts for External Consumers

5.2 Managed Reader Accounts for External Consumers

While Snowflake Direct Data Sharing provides seamless data exchange between existing Snowflake accounts, enterprise data providers frequently need to share live datasets with external partners, suppliers, B2B clients, or regulatory agencies that do not have a Snowflake account.

Historically, organizations addressed this by building custom REST APIs, maintaining SFTP file dump pipelines, or licensing expensive third-party web portals. Snowflake eliminates these anti-patterns through Managed Reader Accounts (also known simply as Reader Accounts). A Reader Account is a specialized, dedicated Snowflake account provisioned, managed, and financially sponsored by the data provider for the sole purpose of consuming shared data.

Reader Account Architecture & Provisioning Lifecycle

A reader account is created directly by the provider account and exists as a first-class tenant within Snowflake. However, unlike standard accounts, reader accounts have no independent billing relationship with Snowflake.

┌────────────────────────────────────────────────────────────────────────┐
│                            PROVIDER ACCOUNT                            │
│                                                                        │
│   ┌─────────────────────┐               ┌──────────────────────────┐   │
│   │   ACCOUNTADMIN      │──────────────►│ CREATE MANAGED ACCOUNT   │   │
│   │  (Sponsors Costs)   │               │      (TYPE = READER)     │   │
│   └──────────┬──────────┘               └─────────────┬────────────┘   │
│              │                                        │                │
│              │ Billed for all Compute                 │ Provisions     │
│              ▼                                        ▼                │
│   ┌─────────────────────┐               ┌──────────────────────────┐   │
│   │  Resource Monitor   │               │   Shared Inbound Data    │   │
│   │  (Enforces Quota)   │               │   (Via ALTER SHARE ...)  │   │
│   └─────────────────────┘               └─────────────┬────────────┘   │
└───────────────────────────────────────────────────────┼────────────────┘
                                                        │
                                                        ▼
┌────────────────────────────────────────────────────────────────────────┐
│                     MANAGED READER ACCOUNT (CLIENT)                    │
│                                                                        │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │ Dedicated Account URL (https://org-reader.snowflakecomputing)  │   │
│   │                                                                │   │
│   │   ┌──────────────────────────┐    ┌────────────────────────┐   │   │
│   │   │  Local Virtual Warehouse │    │ Mounted Shared DB      │   │   │
│   │   │  (X-Small, Auto-Suspend) │───►│ (Read-Only Live Access)│   │   │
│   │   └──────────────────────────┘    └────────────────────────┘   │   │
│   │                 ▲                                              │   │
│   │                 │ Executes Queries                             │   │
│   │   ┌─────────────┴────────────┐                                 │   │
│   │   │ Client Users / BI Tools  │                                 │   │
│   │   │ (Tableau, Power BI, SQL) │                                 │   │
│   │   └──────────────────────────┘                                 │   │
│   └────────────────────────────────────────────────────────────────┘   │
└────────────────────────────────────────────────────────────────────────┘

Declarative Account Provisioning

To create a reader account, a user with ACCOUNTADMIN (or a role granted the global CREATE ACCOUNT privilege) in the provider account executes CREATE MANAGED ACCOUNT specifying TYPE = READER. By default a provider can create 20 reader accounts, and a dropped reader account keeps counting against that limit for its 7-day retention period:

USE ROLE ACCOUNTADMIN;

-- Provision the managed reader account
CREATE MANAGED ACCOUNT client_acme_reader
  ADMIN_NAME = 'acme_admin'
  ADMIN_PASSWORD = 'InitialTemporaryStrongPassword2026!'
  TYPE = READER
  COMMENT = 'Reader account for ACME partner logistics telemetry';

The output returns the new account's locator and URL. Share that URL, together with the initial administrator credentials, with the consumer. SHOW MANAGED ACCOUNTS lists the reader accounts a provider owns.

Associating Shares with the Reader Account

Once the reader account is provisioned, the provider adds the reader account to one or more existing shares:

-- Add the newly created reader account to the target share
ALTER SHARE logistics_telemetry_share ADD ACCOUNTS = client_acme_reader;

Administrative Oversight and Access Delegation

The provider retains supreme administrative oversight over the reader account:

1. Bootstrap tasks happen inside the reader account: Using the initial administrator user, someone logs in to the reader account and creates users, custom roles, warehouses, resource monitors, and a database from each share. The account starts with a single administrator user.
2. Support model: Because a reader account has no contract with Snowflake, its users get support from the provider, who escalates to Snowflake Support when needed.
3. De-provisioning: If the business relationship ends, the provider revokes share access or drops the account:

-- Revoke share access
ALTER SHARE logistics_telemetry_share REMOVE ACCOUNTS = client_acme_reader;

-- Permanently drop the reader account
DROP MANAGED ACCOUNT client_acme_reader;

Resource & Cost Governance: The Provider Liability Model

The most critical architectural concept regarding reader accounts tested on the SnowPro Advanced: Architect exam is the financial liability model.

Architect Exam Rule: Reader accounts do not pay Snowflake for any service. ALL compute credits consumed by virtual warehouses operating within a reader account are billed directly to the PROVIDER'S Snowflake contract.

If an external partner runs poorly optimized queries, cartesian product joins, or connects uncurated BI dashboards that refresh every thirty seconds, the data provider pays for every single credit burned.

The Cost Control Strategy: Three Mandatory Layers

To prevent runaway compute spend in reader accounts, architects must enforce a three-layer governance framework:

Layer 1: Strict Virtual Warehouse Sizing & Parameters

When provisioning warehouses inside a reader account (either directly as provider or via initial bootstrap scripts), configure conservative parameters:

-- Executed within the Reader Account context
USE ROLE ACCOUNTADMIN;

CREATE WAREHOUSE reader_reporting_wh WITH
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60              -- Suspend after 1 minute of inactivity
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE
  STATEMENT_TIMEOUT_IN_SECONDS = 300  -- Hard kill queries running > 5 minutes
  STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = 60
  COMMENT = 'Conservative compute warehouse for external partner reporting';

• Restrict warehouse size: Keep sizes to XSMALL or SMALL. Avoid creating large multi-cluster warehouses unless explicitly budgeted.
• Aggressive AUTO_SUSPEND: Standard default is 10 minutes (600 seconds); reduce this to 60 seconds to eliminate idle credit burn.
• STATEMENT_TIMEOUT_IN_SECONDS: Prevents runaway queries by terminating any execution exceeding the threshold (e.g., 300 seconds).

Layer 2: Resource Monitors Created Inside the Reader Account

Snowflake's guidance is explicit: without resource monitors, warehouses in a reader account can consume an unlimited number of credits, all billed to the provider. Resource monitors are created in the reader account (while logged in as its administrator) and can control all warehouses in the account or individual warehouses:

-- Executed while logged in to the READER account as its administrator
USE ROLE ACCOUNTADMIN;

CREATE RESOURCE MONITOR rm_acme_reader_cap
  WITH CREDIT_QUOTA = 200          -- Monthly budget of 200 credits
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO SUSPEND        -- Prevent new queries
    ON 100 PERCENT DO SUSPEND_IMMEDIATE; -- Cancel running queries

-- Apply it to every warehouse in the reader account
ALTER ACCOUNT SET RESOURCE_MONITOR = rm_acme_reader_cap;

Exam Trap: There is no ALTER MANAGED ACCOUNT ... SET RESOURCE_MONITOR command. MANAGED ACCOUNT supports only CREATE, DROP, and SHOW. Spend controls are configured inside the reader account, and the provider cannot rely on the consumer to do it.

Layer 3: Spend Telemetry & Auditing

Providers audit reader consumption from the provider account through the SNOWFLAKE.READER_ACCOUNT_USAGE schema, whose views (for example WAREHOUSE_METERING_HISTORY, QUERY_HISTORY, LOGIN_HISTORY, RESOURCE_MONITORS, STORAGE_USAGE) cover all reader accounts created by the provider and include a READER_ACCOUNT_NAME column:

-- Inspect reader account warehouse usage from the provider account
USE ROLE ACCOUNTADMIN;

SELECT reader_account_name, warehouse_name, SUM(credits_used) AS credits
FROM snowflake.reader_account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY credits DESC;

Operational Restrictions & Security Boundaries

A reader account is intended mainly for querying data shared by its provider, so Snowflake blocks anything that loads or modifies data.

What Reader Accounts CANNOT Do

1. Upload or modify data: INSERT, UPDATE, DELETE, MERGE, and COPY INTO <table> are not allowed.
2. Create stages, pipes, or shares: CREATE STAGE, CREATE PIPE, and CREATE SHARE are blocked, so readers cannot build ingestion pipelines or re-share data.
3. Create governance or ML objects: CREATE MASKING POLICY, CREATE ROW ACCESS POLICY, CREATE MODEL, CREATE SERVICE, CREATE STREAMLIT, and CREATE IMAGE REPOSITORY are blocked, as is setting data metric functions.
4. Unload through a storage integration: not allowed — but a reader can still run COPY INTO <location> with its own cloud credentials to unload query results. Reader accounts are therefore not an exfiltration control; the provider must decide what data to share in the first place.
5. Consume other providers' data: a reader account can consume data only from the provider that created it.

Everything else is allowed — for example, creating materialized views on shared data to speed up the reader's own queries.

What Reader Accounts CAN Do (Allowed Capabilities)

• Mount and Query Shares: Mount shared databases and execute queries against shared tables and secure views.
• User & Role Administration: The reader account administrator can create local users and custom roles on top of the standard system roles (SYSADMIN, SECURITYADMIN, PUBLIC), and should grant SECURITYADMIN and SYSADMIN to at least one other user to share administration.
• Network Policies: Configure account-level and user-level network policies to restrict access to the reader account from specific partner corporate IP ranges.
• BI and Driver Connectivity: Connect seamlessly via standard Snowflake drivers (JDBC, ODBC, Python, .NET, Go) and business intelligence tools (Tableau, Power BI, Looker, ThoughtSpot, Excel).

Standard Consumer Account vs. Managed Reader Account