Snowflake Cloud Services: prezzi e monitoraggio

Il calcolo viene effettuato ogni giorno nel fuso orario UTC. Snowflake somma i crediti di compute dei warehouse e i crediti dei cloud services consumati nella giornata. La rettifica è pari al minore tra: (10% dei crediti warehouse) o (crediti cloud services utilizzati). L'importo fatturabile corrisponde ai crediti cloud services meno la rettifica.

Esempio 1: sotto la soglia (nessun addebito)

• Compute warehouse: 100 crediti
• Cloud services: 8 crediti
• Rettifica: 8 crediti (i cloud services sono inferiori alla soglia del 10%)
• Cloud Services fatturati: 0 crediti
• Totale fatturato: 100 crediti

Esempio 2: sopra la soglia (addebito parziale)

• Compute warehouse: 100 crediti
• Cloud services: 20 crediti
• Rettifica: 10 crediti (l'importo corrispondente alla soglia del 10%)
• Cloud Services fatturati: 10 crediti
• Totale fatturato: 110 crediti

Un'eccezione importante: le funzionalità serverless come Snowpipe, Automatic Clustering e Materialized Views NON rientrano nella rettifica del 10%. Hanno una fatturazione separata come voce a sé.

I crediti dei cloud services vengono consumati dalle attività del services layer di Snowflake:

• Compilazione e ottimizzazione delle query - Ogni query viene compilata prima di essere eseguita
• Operazioni sui metadati - Comandi DDL (CREATE, ALTER, DROP), zero-copy cloning, comandi SHOW, query su INFORMATION_SCHEMA
• Autenticazione e controllo degli accessi - Login degli utenti, cambio di ruolo, verifica dei permessi
• Caching dei risultati delle query - Gestione e distribuzione dei risultati in cache
• Listing dei file - I comandi COPY elencano i file nell'object storage prima del caricamento

Lo schema ACCOUNT_USAGE di Snowflake mette a disposizione viste per tracciare i cloud services, con una latenza di 2 ore e una retention di 365 giorni.

Fatturazione giornaliera dei Cloud Services

Per verificare in quali giorni si sono effettivamente generati addebiti:

SELECT
    usage_date,
    credits_used_cloud_services,
    credits_adjustment_cloud_services,
    credits_used_cloud_services + credits_adjustment_cloud_services AS billed_cloud_services,
    credits_used_compute,
    ROUND(credits_used_cloud_services / NULLIF(credits_used_compute, 0) * 100, 2) AS cs_pct_of_compute
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(month, -1, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
ORDER BY billed_cloud_services DESC;

Qualsiasi valore positivo di billed_cloud_services indica un addebito in quella giornata.

Cloud Services per tipo di query

La vista query_history di Snowflake espone una colonna credits_used_cloud_services molto utile per capire quali tipi di query consumano più cloud services:

SELECT
    query_type,
    SUM(credits_used_cloud_services) AS total_cs_credits,
    COUNT(1) AS num_queries,
    AVG(credits_used_cloud_services) AS avg_cs_per_query
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
GROUP BY query_type
ORDER BY total_cs_credits DESC;

Query con elevato consumo di Cloud Services

Lo stesso approccio permette di isolare le singole query con un consumo elevato di Cloud Services.

SELECT
    query_id,
    user_name,
    warehouse_name,
    query_type,
    credits_used_cloud_services,
    SUBSTRING(query_text, 1, 100) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0.001
ORDER BY credits_used_cloud_services DESC
LIMIT 100;

Dall'esperienza con i clienti Snowflake, alcuni pattern emergono in modo ricorrente come fattori di costo dei cloud services.

1. Query sui metadati ad alta frequenza

Eseguire query semplici come SELECT 1, SELECT CURRENT_SESSION() o query show decine di migliaia di volte al giorno incide sui costi. Inoltre, le query su INFORMATION_SCHEMA utilizzano esclusivamente cloud services (senza compute warehouse).

Soluzione: riduca la frequenza di questi health check se la cronologia delle query mostra che stanno facendo lievitare la fattura. Può passare allo schema account_usage al posto di information_schema se la latenza è accettabile. Lo faccia però con cautela: di solito ha più senso evitare di accendere un warehouse.

2. DDL e cloning eccessivi

Le operazioni DDL sono interamente operazioni sui metadati. Creare ed eliminare frequentemente schemi di grandi dimensioni o clonare interi database per il backup fa lievitare il consumo di cloud services.

Soluzione: cloni al livello di granularità minimo necessario. Cloni le singole tabelle anziché gli schemi, gli schemi anziché i database. Riduca la frequenza dei cloning dove possibile. Si accerti inoltre che nel suo account vengano eseguite solo le DDL davvero necessarie.

3. Insert riga per riga e frammentazione degli schemi

Snowflake non è un sistema OLTP. Gli insert riga per riga consumano risorse significative dei cloud services, perché spesso queste operazioni sostituiscono intere micro partizioni. Anche le architetture multi-tenant con uno schema per cliente generano metadati in eccesso.

Soluzione: usi caricamenti batch o bulk. Per le app multi-tenant, quando possibile, Snowflake consiglia di adottare schemi condivisi con tabelle clusterizzate su customer_id e secure view per l'isolamento.

4. Comandi COPY con scarsa selettività dei file

I comandi COPY elencano i file presenti nell'object storage, e questo listing sfrutta il compute dei cloud services. Elencare migliaia di file per copiarne pochi si traduce in un consumo elevato.

Soluzione: strutturi l'object storage con prefissi temporali. Usi pattern di file precisi nei comandi COPY.

-- Invece di elencare tutto
COPY INTO target FROM @stage/raw_data/;

-- Elenchi solo percorsi specifici: anno/mese/giorno
COPY INTO target FROM @stage/raw_data/2025/10/24/;

5. Compilazione di query complesse

Le query con un numero eccessivo di join, grandi set operation (IN, NOT IN, EXISTS) o prodotti cartesiani consumano molti cloud services in fase di compilazione.

Soluzione: semplifichi la struttura delle query. Sostituisca le liste IN molto lunghe con tabelle temporanee e JOIN. Suddivida le query complesse in CTE.

Monitoraggio costante. Pianifichi revisioni settimanali del consumo di cloud services. Definisca una baseline per individuare rapidamente le anomalie.

Operazioni in batch. Che si tratti di DDL, DML o caricamento dati, il batching è quasi sempre più efficiente delle operazioni singole.

Verifichi le query dei tool di terze parti. Strumenti di BI, piattaforme ETL e sistemi di orchestrazione generano spesso pattern di query sui metadati che non controlla direttamente. Bastano alcune modifiche di configurazione per ridurre sensibilmente le query superflue.

Imposti gli alert. Inserisca le query di monitoraggio in task pianificati con integrazioni di notifica. Meglio ancora, utilizzi i monitor di SELECT per un alerting pronto all'uso.