Snowflake Cloud Services: Preise und Monitoring

Die Berechnung erfolgt täglich in UTC. Snowflake summiert Ihre Warehouse-Compute-Credits und Cloud-Services-Credits für den jeweiligen Tag. Die Verrechnung entspricht dem kleineren der beiden Werte: 10 % der Warehouse-Credits oder die tatsächlich verbrauchten Cloud-Services-Credits. Abgerechnet werden die Cloud-Services-Credits abzüglich dieser Verrechnung.

Beispiel 1: Unterhalb der Schwelle (keine Kosten)

• Warehouse-Compute: 100 Credits
• Cloud Services: 8 Credits
• Verrechnung: 8 Credits (Cloud Services liegt unter der 10-%-Schwelle)
• Abgerechnete Cloud Services: 0 Credits
• Gesamt abgerechnet: 100 Credits

Beispiel 2: Oberhalb der Schwelle (anteilige Kosten)

• Warehouse-Compute: 100 Credits
• Cloud Services: 20 Credits
• Verrechnung: 10 Credits (entspricht der 10-%-Schwelle)
• Abgerechnete Cloud Services: 10 Credits
• Gesamt abgerechnet: 110 Credits

Wichtige Ausnahme: Serverless-Features wie Snowpipe, Automatic Clustering und Materialized Views fließen NICHT in die 10-%-Verrechnung ein. Sie werden als separate Posten abgerechnet.

Cloud-Services-Credits werden durch Aktivitäten im Services Layer von Snowflake verbraucht:

• Query-Kompilierung und -Optimierung – Jede Query wird vor der Ausführung kompiliert
• Metadaten-Operationen – DDL-Befehle (CREATE, ALTER, DROP), Zero-Copy-Cloning, SHOW-Befehle, INFORMATION_SCHEMA-Queries
• Authentifizierung und Zugriffskontrolle – User-Login, Rollenwechsel, Berechtigungsprüfungen
• Query-Result-Caching – Verwaltung und Bereitstellung gecachter Ergebnisse
• File-Listing-Operationen – COPY-Befehle listen Dateien aus dem Object Storage auf, bevor sie geladen werden

Das ACCOUNT_USAGE-Schema von Snowflake stellt Views bereit, mit denen sich Cloud Services tracken lassen – mit 2 Stunden Latenz und 365 Tagen Aufbewahrung.

Tägliche Cloud-Services-Abrechnung

Prüfen Sie, an welchen Tagen tatsächlich Kosten entstanden sind:

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;

Jeder positive Wert in billed_cloud_services bedeutet, dass Ihnen an diesem Tag Cloud Services in Rechnung gestellt wurden.

Cloud Services nach Query-Typ

Die View query_history von Snowflake enthält die Spalte credits_used_cloud_services. Damit lässt sich gut erkennen, welche Query-Typen die meisten Cloud Services verbrauchen:

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;

Queries mit hohem Cloud-Services-Verbrauch

Mit demselben Ansatz lassen sich einzelne Queries mit hohem Cloud-Services-Verbrauch herausfiltern.

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;

In der Arbeit mit Snowflake-Kunden tauchen immer wieder bestimmte Muster als Treiber der Cloud-Services-Kosten auf.

1. Hochfrequente Metadaten-Queries

Einfache Queries wie SELECT 1, SELECT CURRENT_SESSION() oder show-Befehle, die zigtausendmal pro Tag laufen, summieren sich. Auch Queries gegen das INFORMATION_SCHEMA nutzen ausschließlich Cloud Services (kein Warehouse-Compute).

Lösung: Reduzieren Sie die Frequenz solcher Health-Checks, wenn Ihre Query-History zeigt, dass sie die Rechnung in die Höhe treiben. Sofern die Latenz akzeptabel ist, können Sie statt des information_schema das account_usage-Schema nutzen. Gehen Sie damit aber mit Bedacht um: Häufig ist es sinnvoller, gar nicht erst ein Warehouse zu starten.

2. Übermäßige DDL- und Cloning-Operationen

DDL-Operationen sind reine Metadaten-Operationen. Häufiges Erstellen oder Löschen großer Schemas oder das Klonen ganzer Datenbanken für Backups treibt den Cloud-Services-Verbrauch nach oben.

Lösung: Klonen Sie auf der feinstmöglichen Ebene – einzelne Tabellen statt ganzer Schemas, Schemas statt ganzer Datenbanken. Reduzieren Sie die Cloning-Frequenz, wo immer möglich. Stellen Sie zudem sicher, dass in Ihrem Account nur wirklich notwendige DDL läuft.

3. Single-Row-Inserts und Schema-Fragmentierung

Snowflake ist kein OLTP-System. Single-Row-Inserts verbrauchen erhebliche Cloud-Services-Ressourcen, da solche Operationen oft ganze Micro-Partitionen ersetzen. Hinzu kommt: Multi-Tenant-Architekturen mit einem Schema pro Kunde erzeugen exzessiv viele Metadaten.

Lösung: Setzen Sie auf Batch- oder Bulk-Loads. Für Multi-Tenant-Anwendungen empfiehlt Snowflake nach Möglichkeit gemeinsam genutzte Schemas mit auf customer_id geclusterten Tabellen sowie Secure Views zur Isolation.

4. COPY-Befehle mit unscharfer Dateiauswahl

COPY-Befehle listen Dateien aus dem Object Storage auf, was Cloud-Services-Compute verbraucht. Tausende Dateien zu listen, um am Ende nur wenige zu kopieren, führt zu hohem Verbrauch.

Lösung: Strukturieren Sie den Object Storage mit Datums-Präfixen. Verwenden Sie in COPY-Befehlen präzise Dateimuster.

-- Statt alles aufzulisten
COPY INTO target FROM @stage/raw_data/;

-- Nur bestimmte Pfade auflisten: year/month/day
COPY INTO target FROM @stage/raw_data/2025/10/24/;

5. Komplexe Query-Kompilierung

Queries mit zu vielen Joins, großen Mengenoperationen (IN, NOT IN, EXISTS) oder kartesischen Produkten verbrauchen schon bei der Kompilierung erhebliche Cloud-Services-Ressourcen.

Lösung: Vereinfachen Sie die Query-Struktur. Ersetzen Sie große IN-Listen durch Temp-Tables und JOINs. Zerlegen Sie komplexe Queries in CTEs.

Regelmäßig überwachen. Etablieren Sie wöchentliche Reviews des Cloud-Services-Verbrauchs. Legen Sie eine Baseline fest, um Anomalien frühzeitig zu erkennen.

Operationen bündeln. Ob DDL, DML oder Datenladen – Batch-Verarbeitung ist fast immer effizienter als viele Einzeloperationen.

Queries von Drittanbieter-Tools prüfen. BI-Tools, ETL-Plattformen und Orchestrierungssysteme erzeugen oft Metadaten-Query-Muster, die Sie nicht direkt steuern. Über Konfigurationsanpassungen lassen sich unnötige Queries deutlich reduzieren.

Alerts einrichten. Packen Sie Monitoring-Queries in geplante Tasks mit Notification-Integrationen. Noch besser: Nutzen Sie SELECT Monitors für schlüsselfertiges Alerting.