Snowflake Cloud Services : tarifs et suivi

Le calcul s'effectue chaque jour en fuseau UTC. Snowflake additionne vos crédits de compute warehouse et vos crédits Cloud Services du jour. L'ajustement correspond au plus petit des deux montants suivants : (10 % des crédits warehouse) ou (crédits Cloud Services consommés). Votre montant facturable correspond aux crédits Cloud Services moins l'ajustement.

Exemple 1 : sous le seuil (aucun frais)

• Compute warehouse : 100 crédits
• Cloud Services : 8 crédits
• Ajustement : 8 crédits (Cloud Services est inférieur au seuil de 10 %)
• Cloud Services facturés : 0 crédit
• Total facturé : 100 crédits

Exemple 2 : au-dessus du seuil (facturation partielle)

• Compute warehouse : 100 crédits
• Cloud Services : 20 crédits
• Ajustement : 10 crédits (le montant correspondant au seuil de 10 %)
• Cloud Services facturés : 10 crédits
• Total facturé : 110 crédits

Exception importante : les fonctionnalités serverless telles que Snowpipe, Automatic Clustering et Materialized Views n'entrent PAS dans l'ajustement de 10 %. Elles font l'objet d'une facturation distincte, ligne par ligne.

Les crédits Cloud Services sont consommés par les activités de la couche de services de Snowflake :

• Compilation et optimisation des requêtes – chaque requête passe par une phase de compilation avant son exécution
• Opérations sur les métadonnées – commandes DDL (CREATE, ALTER, DROP), zero-copy cloning, commandes SHOW, requêtes sur INFORMATION_SCHEMA
• Authentification et contrôle d'accès – connexion utilisateur, changement de rôle, vérification des permissions
• Mise en cache des résultats de requêtes – gestion et restitution des résultats mis en cache
• Listing de fichiers – les commandes COPY listent les fichiers depuis l'object storage avant chargement

Le schéma ACCOUNT_USAGE de Snowflake fournit des vues pour suivre Cloud Services, avec une latence de 2 heures et une rétention de 365 jours.

Facturation quotidienne de Cloud Services

Identifiez les jours où des frais ont effectivement été appliqués :

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;

Toute valeur positive de billed_cloud_services signifie que vous avez été facturé ce jour-là.

Cloud Services par type de requête

La vue query_history de Snowflake propose une colonne credits_used_cloud_services très utile pour repérer les types de requêtes qui consomment le plus de 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;

Requêtes à forte consommation de Cloud Services

La même approche permet d'isoler les requêtes individuelles dont la dépense Cloud Services est élevée.

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;

L'expérience auprès des clients Snowflake fait ressortir certains schémas récurrents qui pèsent sur les coûts Cloud Services.

1. Requêtes de métadonnées à haute fréquence

Exécuter des requêtes simples comme SELECT 1, SELECT CURRENT_SESSION() ou des requêtes show des dizaines de milliers de fois par jour finit par peser lourd. De même, les requêtes sur INFORMATION_SCHEMA n'utilisent que Cloud Services (aucun compute warehouse).

Solution : réduisez la fréquence de ces health checks si votre historique de requêtes montre qu'ils alourdissent la facture. Vous pouvez basculer sur le schéma account_usage plutôt que information_schema si la latence est acceptable. Mais procédez avec prudence : il est généralement préférable d'éviter de démarrer un warehouse.

2. DDL et clonage excessifs

Les opérations DDL portent uniquement sur les métadonnées. Créer ou supprimer fréquemment de grands schémas, ou cloner des bases entières pour faire des sauvegardes, fait grimper la consommation Cloud Services.

Solution : clonez au niveau de granularité le plus fin possible. Préférez des tables individuelles aux schémas, et des schémas aux bases complètes. Réduisez la fréquence des clonages dès que possible. Veillez aussi à n'exécuter que les DDL réellement nécessaires sur votre compte.

3. Inserts ligne par ligne et fragmentation de schéma

Snowflake n'est pas un système OLTP. Les inserts ligne par ligne consomment énormément de ressources Cloud Services, car ces opérations remplacent souvent des micro-partitions entières. Par ailleurs, les architectures multi-tenant avec un schéma par client génèrent une masse excessive de métadonnées.

Solution : privilégiez les chargements par lots ou en masse. Pour les applications multi-tenant, Snowflake recommande, lorsque c'est possible, d'utiliser des schémas partagés avec des tables clusterisées sur customer_id et des vues sécurisées pour l'isolation.

4. Commandes COPY peu sélectives

Les commandes COPY listent les fichiers depuis l'object storage, ce qui sollicite le compute Cloud Services. Lister des milliers de fichiers pour n'en copier que quelques-uns entraîne une forte consommation.

Solution : structurez votre object storage avec des préfixes de date. Utilisez des motifs de fichiers précis dans vos commandes COPY.

-- Au lieu de tout lister
COPY INTO target FROM @stage/raw_data/;

-- Lister uniquement des chemins précis : année/mois/jour
COPY INTO target FROM @stage/raw_data/2025/10/24/;

5. Compilation de requêtes complexes

Les requêtes comportant de nombreuses jointures, de grandes opérations ensemblistes (IN, NOT IN, EXISTS) ou des produits cartésiens consomment beaucoup de Cloud Services lors de la compilation.

Solution : simplifiez la structure de vos requêtes. Remplacez les longues listes IN par des tables temporaires et des JOIN. Décomposez les requêtes complexes en CTE.

Suivez la consommation régulièrement. Mettez en place une revue hebdomadaire de la consommation Cloud Services. Établissez votre référence pour repérer rapidement les anomalies.

Groupez les opérations. Qu'il s'agisse de DDL, de DML ou de chargement de données, le traitement par lots est presque toujours plus efficace que les opérations unitaires.

Passez en revue les requêtes des outils tiers. Outils de BI, plateformes ETL et systèmes d'orchestration génèrent souvent des schémas de requêtes de métadonnées qui vous échappent. Quelques ajustements de configuration peuvent réduire fortement les requêtes inutiles.

Mettez en place des alertes. Encapsulez vos requêtes de monitoring dans des tâches planifiées avec des intégrations de notification. Mieux encore, utilisez les monitors SELECT pour des alertes clé en main.