Snowpark Container Services verstehen: Bausteine und Preise für Einsteiger

Mit Snowpark Container Services lassen sich containerisierte Anwendungen direkt innerhalb von Snowflake ausführen. Es ist Snowflakes Pendant zu AWS ECS, Google Cloud Run oder Azure Container Instances. Statt in Ihrem Cloud-Account laufen Ihre Container jedoch in der Compute-Umgebung von Snowflake und greifen nativ auf Ihre Snowflake-Daten zu.

Das Beste daran: Ihre Container können direkt Snowflake-Tabellen abfragen, Snowflake-Funktionen aufrufen und auf Ihre Daten zugreifen – ganz ohne Service-Account, ohne Credential-Management für Datenzugriffe und ohne die Daten aus der Plattform herauszubewegen. Auch die Nutzer Ihrer App erhalten Zugriff über ein simples GRANT-Statement; Sie müssen also keine Authentifizierungs-Software entwickeln und keine Benutzer/Passwörter verwalten. Vor Kurzem habe ich eine Container-App für einen AWS-/Snowflake-Kunden ausgerollt, und er hat sich für SPCS statt ECS entschieden, weil User-Management und Security deutlich einfacher sind.

Es gibt bereits viele Artikel mit Beispielen zum Deployment von Apps in Snowpark Container Services. In diesem Beitrag konzentrieren wir uns vor allem auf die Bausteine (Terminologie), die Preisgestaltung sowie einige Nuancen und Unterschiede gegenüber klassischen Container-Diensten.

Sehen wir uns die vier wichtigsten Objekte an, mit denen Sie arbeiten werden:

1. Image Repository

Das ist die Container-Registry von Snowflake, vergleichbar mit Docker Hub oder Amazon ECR. Sie pushen Ihre Docker-Images hierhin, und Snowflake holt sie sich beim Start Ihrer Services von dort.

1CREATE IMAGE REPOSITORY my_app_repo;

Snowpark Container Services zieht Container-Images nicht direkt aus externen Registries wie Docker Hub. Sie können beim lokalen Build zwar öffentliche Base-Images nutzen, doch vor dem Deployment in Snowflake muss das finale Image in ein Snowflake Image Repository in Ihrem Account gepusht werden. Services können ausschließlich Images ausführen, die im Repository-System von Snowflake liegen.

2. Compute Pool

Hier weicht es von dem ab, was Sie möglicherweise gewohnt sind. Ein Compute Pool ist eine Sammlung virtueller Maschinen, die einen oder mehrere Container ausführt. Stellen Sie ihn sich als Ihren Cluster aus Nodes vor, der viele Services oder Apps betreiben kann.

CREATE COMPUTE POOL my_pool
  MIN_NODES = 1
  MAX_NODES = 3
  INSTANCE_FAMILY = CPU_X64_XS
  AUTO_RESUME = TRUE
  AUTO_SUSPEND_SECS = 60;

Wichtige Parameter:

• MIN_NODES / MAX_NODES: Wie viele VM-Instanzen laufen dürfen (das ist Ihre Kapazität, nicht die Anzahl der Container). MIN_NODES muss größer als null sein. Der Pool wird automatisch suspendiert, wenn keine Services laufen.
• INSTANCE_FAMILY: Größe/Typ der VM (CPU_X64_S, CPU_X64_M, GPU_NV_S usw.)
• AUTO_RESUME: Ob der Pool bei Bedarf automatisch startet
• AUTO_SUSPEND_SECS: Wie lange gewartet wird, bis ein leerer Pool ohne laufende Services suspendiert wird.

3. Service

Ein Service ist die laufende containerisierte Anwendung. Er definiert, welches Image ausgeführt wird, wie viele Instanzen (Container) starten und wie der Traffic geroutet wird.

-- minimum required code:
CREATE SERVICE my_web_app
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml';

-- more common properties...
CREATE SERVICE my_api_service
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml'
  MIN_INSTANCES = 1
  MAX_INSTANCES = 5 -- Scale up to 5 based on CPU
  MIN_READY_INSTANCES = 1 -- Need at least 1 for service to be ready
  EXTERNAL_ACCESS_INTEGRATIONS = (api_eai, cdn_eai)

Expand Code

Der Service liest eine YAML-Spezifikationsdatei (in einem Stage abgelegt), die Ihre Container beschreibt – ähnlich einem Kubernetes-Deployment oder einer Docker-Compose-Datei. Hier ein Beispiel einer SPECIFICATION_FILE.yml, die der Service beim Start einliest:

spec:
  containers:
  - name: my_app_container
    image: /dbt_dev/my_app/repo/my_app_container:latest
    env:
      # your app env vars here
      ## This app reads data from Snowflake using these vars
      SNOWFLAKE_WAREHOUSE: COMPUTE_WH
      SNOWFLAKE_DATABASE: FIVETRAN
      SNOWFLAKE_SCHEMA: SAP_ECC
      SNOWFLAKE_ROLE: DBT_ROLE
      APP_HOST: 0.0.0.0
      APP_PORT: "8080"
    readinessProbe:
      port: 8080

Expand Code

4. External Access Integration (optional)

Wenn Ihr Container externe APIs oder Services außerhalb von Snowflake aufrufen muss, benötigen Sie eine External Access Integration. So steuert Snowflake ausgehenden Netzwerkverkehr.

CREATE EXTERNAL ACCESS INTEGRATION my_api_access
  ALLOWED_NETWORK_RULES = (my_network_rule)
  ENABLED = TRUE;

Wie Sie sehen, gibt es hier einige neue Konzepte, die sehr spezifisch für diesen Service sind. Allgemeines Snowflake- oder Cloud-Wissen hilft beim Einstieg, aber diese neuen Begriffe müssen Sie wirklich verinnerlichen.

Die Preisgestaltung von SPCS finde ich durchaus fair. Im Vergleich zu klassischen Container-Diensten (ECS, Cloud Run, ACI) ist es zwar teurer, doch die zusätzlichen Vorteile durch Snowflake-Governance und Datennähe sind das oft wert. Hier ein Überblick über die verschiedenen Kostenpositionen bei SPCS.

Compute Pools

Die Hauptkostenkomponente von SPCS sind die Compute Pools. Auf den ersten Blick wirkt SPCS sehr günstig. Ein Extra Small kostet nur 0,06 Credits pro Stunde. Bei 3 $ pro Credit kostet ein XS also 4,32 $ pro Tag bzw. 1.576 $ pro Jahr. Vergleichbare Hardware auf Cloud Run läge bei knapp unter 3 $ pro Tag. SPCS ist also teurer, bietet dafür aber die genannten Zusatzvorteile.

Wenn ein Compute Pool wieder anläuft, werden Ihnen mindestens 5 Minuten in Rechnung gestellt.

Vergleich mit den Kosten von Snowflake Virtual Warehouses

Im Vergleich dazu kostet das kleinste Snowflake Virtual Warehouse 1 Credit pro Stunde. SPCS ist damit eine deutlich günstigere Alternative für leichtgewichtige Aufgaben wie das Ausführen von Python-Skripten oder das Hosten von Notebooks. Wie oben gezeigt, betreiben Sie eine Compute-Node zu nur 6 % der Gesamtkosten eines XS-Warehouses!

Speicherkosten

Speicher ist günstig, und SPCS verbraucht keine Unmengen davon – trotzdem sollten Sie diesen Aspekt im Blick haben. Diese Speicherposten können anfallen:

• Image Repository: technisch als Stage implementiert, daher gelten die üblichen Speicherpreise.
• Block-Volumes für Container: speichern den Status Ihrer Anwendung, vergleichbar mit AWS EBS oder Google Persistent Disk. Das ist der teuerste Speicherposten – etwa 82 bis 100 $ pro TB und Monat.
• Logging in die Event-Table von Snowflake (Standardspeicher)
• Sonstige Stages/Tabellen, die Ihre App verwendet (Standardspeicher)

Hier werden viele Einsteiger überrascht (ich war einer davon). Wer Cloud Run, AWS Lambda, ECS oder ähnliche "serverlose" Container-Plattformen gewohnt ist, erwartet, dass ein Service automatisch heruntergefahren wird, wenn ihn niemand nutzt. Tut er aber nicht.

So sehen SPCS-Kosten wirklich aus

Ben Franklin sagte: "Experience is the best teacher, but a fool will learn from no other." Leider habe ich Folgendes auf die harte Tour gelernt – Sie können also hoffentlich aus meinen Fehlern lernen!

Compute Pools haben zwar AUTO_SUSPEND_SECS, doch das greift nur, wenn der Pool leer ist. Sobald ein Service auf dem Compute Pool läuft, bleibt der Pool aktiv. AUTO_SUSPEND_SECS = 60 suspendiert den Pool also nicht, solange ein Service läuft – und Services suspendieren sich nicht selbst.

Services laufen standardmäßig rund um die Uhr. Wenn Sie einen Service mit MIN_INSTANCES = 1 anlegen (0 ist nicht erlaubt), hält Snowflake permanent einen Container am Laufen. Das heißt: Sie zahlen 24/7 für Compute, bis Sie den Service explizit suspendieren. Anders als bei Cloud Run wird nicht auf null skaliert, wenn niemand zugreift. Die Eigenschaft auto_suspend_secs des Services ist ein Preview-Feature; sie funktioniert für interne Apps ohne öffentliche Endpunkte, etwa Service Functions und Service-to-Service-Kommunikation. Webanwendungen in Containern werden im Leerlauf jedoch nicht automatisch suspendiert. Snowflake wertet zur Erkennung von Inaktivität nur interne Service-Function-Aufrufe aus – nicht den eingehenden HTTP-Traffic.

Wie oben erwähnt, ist das wegen der niedrigen Credit-Rate trotzdem bezahlbar, selbst wenn Sie alles 24/7 laufen lassen (4,32 $/Tag bei 3 $/Credit und XS). Es ist nur ein Punkt, auf den man achten sollte – mich hat es überrascht.

Der zweistufige Suspend-Tanz

Damit der Compute Pool automatisch suspendiert wird, müssen Sie zuerst den Service suspendieren:

-- Step 1: Suspend the service
ALTER SERVICE my_app SUSPEND;

-- Step 2: Now AUTO_SUSPEND_SECS will kick in if you wait for it
-- OR you can force it immediately:
ALTER COMPUTE POOL my_pool SUSPEND;
-- you can suspend compute pool by itself which will suspend the service.

Auto-Resume funktioniert (aber nur für Services)

Der Lichtblick: Auch wenn Services nicht automatisch suspendiert werden, fahren sie sehr wohl automatisch wieder hoch, sobald jemand auf den Endpunkt zugreift – vorausgesetzt, Sie aktivieren das:

ALTER SERVICE my_app SET AUTO_RESUME = TRUE;

-- Now:
-- 1. You manually suspend the service
-- 2. Someone hits your service endpoint
-- 3. The service automatically wakes up
-- 4. The compute pool automatically resumes (because AUTO_RESUME = TRUE on pool)

Strategien zum Kostenmanagement für Snowpark Container Services

Angesichts dieser Einschränkungen gibt es einige praxisnahe Ansätze, wenn Ihre App nicht 24/7 laufen soll:

1. Manuelles Suspend/Resume (ideal für Dev/Test)

-- When you're done working:
ALTER SERVICE my_app SUSPEND;

-- The service will auto-resume when someone accesses it
-- This is manual but reliable

2. Geplante Tasks (gut bei vorhersehbarer Nutzung)

-- Suspend every night at 6 PM
CREATE TASK suspend_service_nightly
  SCHEDULE = 'USING CRON 0 18 * * * America/New_York'
AS
  ALTER SERVICE my_app SUSPEND;

-- it will auto resume when someone uses next.

3. Monitoring und Alerts (unverzichtbar für Produktion)

-- show commands don't run an a warehouse
SHOW SERVICES;

-- If you want to use sql for calcs and filtering...
SELECT
  service_name,
  status,
  compute_pool_name,
  current_instances,
  DATEDIFF('hour', last_resumed, CURRENT_TIMESTAMP()) as hours_running
FROM INFORMATION_SCHEMA.SERVICES
WHERE status = 'RUNNING';

Zugriff auf suspendierte SPCS-URLs

Solange der Service suspendiert ist, sehen Nutzer beim Aufruf der URL diesen Fehler:

{
  "responseType": "ERROR",
  "requestId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "detail": "Service EXAMPLE_SERVICE not reachable: no service hosts found."
}

Solange für Service und Compute Pool Auto-Resume aktiv ist, fahren sie beim URL-Aufruf hoch. Das dauert etwa 39–60 Sekunden, danach lässt sich die Seite per Refresh aufrufen. Das ist nicht ideal, aber gut handhabbar, wenn die Nutzer wissen, was sie erwartet.

Da SPCS Compute Pools deutlich günstigere Kosten pro Credit haben, lassen sie sich elegant nutzen, um Python- (oder beliebige andere) Batch-Jobs günstiger in Snowflake auszuführen. Angenommen, Sie haben einen containerisierten Python-Job, der in eine Snowflake-Registry gepusht ist, sowie eine YAML-Datei mit der Servicebeschreibung in einem Stage. Dann lässt sich der Code im Container über execute job service ... starten. Diese Services beenden sich nach Abschluss von selbst, sodass der Compute Pool ganz normal automatisch suspendiert. Ein schöner Trick, um günstigere Compute in Snowflake zu nutzen!

EXECUTE JOB SERVICE
  IN COMPUTE POOL my_compute_pool
  NAME = my_batch_job
  FROM @my_stage
  SPEC = 'job_spec.yaml';

Die Snowsight-Oberfläche bietet eine bequeme Möglichkeit, SPCS-Ausgaben im Blick zu behalten. Mit der Rolle ACCOUNTADMIN oder einer Rolle mit Berechtigung zum Usage-Monitoring navigieren Sie zu Admin → Cost Management → Consumption und stellen den Filter "Service Type" auf SPCS.

✅ Dedizierte Rolle für das Container-Management anlegen

✅ Datenbank, Schema, Image Repository und Stage einrichten

✅ External Access Integration einrichten, falls externe APIs aufgerufen werden

✅ Compute Pool mit passender Größe und Auto-Suspend-Einstellungen anlegen

✅ Servicespezifikation in den Stage hochladen

✅ Service mit AUTO_RESUME = TRUE anlegen

✅ Manuelle Suspend-Verfahren dokumentieren oder geplante Tasks anlegen

✅ Monitoring-Queries einrichten, um laufende Services und Kosten zu verfolgen

✅ Suspend/Resume-Zyklus vor dem Produktiv-Deployment testen

Snowpark Container Services bringt die Power containerisierter Anwendungen direkt zu Ihren Daten in Snowflake. Allerdings gibt es eine Lernkurve: Sie müssen Image Repositories, Compute Pools, Services und ihr Zusammenspiel verstehen. Sobald Sie diese Bausteine und die Eigenheiten des Kostenmanagements im Griff haben, lassen sich leistungsstarke Datenanwendungen direkt neben Ihren Daten betreiben – ohne die Snowflake-Plattform jemals zu verlassen.

Jeff ist Data- und Analytics-Consultant mit über 15 Jahren Erfahrung darin, Insights zu automatisieren und Geschäftsprozesse datengetrieben zu steuern. Technologisch spezialisiert er sich auf Snowflake + dbt + Tableau. Inhaltlich bringt er Erfahrung aus den Bereichen Versorgungswirtschaft, klinische Studien, Verlagswesen, CPG und Fertigung mit. Schreiben Sie ihm jederzeit: [email protected].