Wie automatische AWS- und Snowflake-Budgetwarnungen dazu beitragen, rechtzeitige Korrekturen einzuleiten
Wer große Marketing-Kampagnen verantwortet, kennt wahrscheinlich das Problem: Cloud-Kosten überraschen oft erst mit der Rechnung.
In dieser Case Study zeigen wir, wie eine automatische Budgetwarnung greift, sobald die monatlichen Ausgaben 130 Prozent des geplanten Budgets überschreiten. Die Schwelle ist bewusst gewählt, denn zu frühe Signale werden oftmals ignoriert. Das System läuft in DEV und PROD und nimmt Teams die täglichen Dashboard-Routinen ab, damit der Fokus auf der Steuerung und Wirkung des Marketings liegt.
Das Ergebnis sind planbarere Budgets, weniger Risiko und schnelleres Handeln im Kampagnenalltag.
Cloud-Kosten sind oft eine unvorhersehbare Position im Marketing-Budget. Sie können von Monat zu Monat schwanken, insbesondere wenn Ihre Pipelines Daten aus mehreren Quellen ziehen und umfangreiche Transformationen erfordern.
Für Unternehmen, die groß angelegte Marketingkampagnen durchführen, kann diese Volatilität riskant sein. Datenpipelines können schnell skalieren und wenn die Ausgaben nicht eng überwacht werden, können Rechnungen für AWS (Amazon Web Services) und Snowflake ohne Vorwarnung sprunghaft ansteigen. Sich ausschließlich auf manuelle Prüfungen zu verlassen ist zeitaufwendig und birgt das Risiko, diese Kosten zu übersehen, bis es zu spät ist.
Ein E-Commerce Unternehmen kam mit genau dieser Herausforderung zu uns. Ziel war es, ein automatisiertes Kosten-Monitoring einzuführen, um die Kontrolle über das Cloud-Budget zurückzugewinnen.
02 Die Lösung
1. EINRICHTEN DER UMGEBUNGEN
Diese Pipeline ist für zwei Umgebungen ausgelegt: DEV und PROD.
- DEV (Development) dient zum Testen und Validieren von Konfigurationsänderungen, damit Anpassungen am Terraform-Code oder an der Logik der Benachrichtigungen korrekt funktionieren, bevor sie produktive Systeme beeinflussen.
- PROD (Production) ist die Live-Umgebung, die Kostenwarnungen auf realen Cloud-Ressourcen überwacht und durchsetzt.
Jede Umgebung entspricht einem eigenen AWS-Konto. Das sorgt für klare Trennung der Workloads, Transparenz bei den Kosten und sauberes Infrastruktur-Management.
In jedem AWS-Konto (DEV und PROD) haben wir manuell ein S3-Bucket angelegt, in dem die Datei terraform.tfstate gespeichert wird.
So stellt Terraform eine konsistente und sichere Dokumentation der bereitgestellten Infrastruktur sicher.
Nach dem Anlegen mussten Name, Key und Region des S3-Buckets in folgenden Dateien fest hinterlegt werden:
- backend/dev.tfbackend
- backend/prod.tfbackend
Beispiel für die Datei backend/dev.tfbackend:
bucket = "terraform-s3-state-4637483747"
key = "terraform.tfstate"
region = "eu-central-1"2. BUDGET DEFINIEREN
Budgets sind nicht statisch. Sie werden in der Regel auf Basis vergangener Ausgaben festgelegt, sodass sich Warnungen an die veränderte Nutzung über die Zeit anpassen.
- Für AWS:
In der AWS Management Console unter Billing and Cost Management können Sie Ausgaben nach Service sowie die gesamten monatlichen Kosten einsehen. - Für Snowflake:
In Snowflake unter Admin → Cost Management sehen Sie die Nutzung von Credits und Währung in einem definierten Zeitraum.
Nachdem wir die bisherigen Ausgaben geprüft und Ihre Budgetgrenzen festgelegt hatten, haben wir diese Werte in die Datei locals.tf eingetragen.
So stellt die Terraform-Automatisierung sicher, dass beim Monitoring und beim Auslösen von Warnungen die richtigen Budgetgrenzen verwendet werden.
locals {
aws_limits = {
dev = 10 # insert your AWS budget limit for DEV (integer or float)
prod = 20 # insert your AWS budget limit for PROD (integer or float)
}
snowflake_limits = {
dev = 100 # insert your Snowflake budget limit for DEV (integer or float)
prod = 200 # insert your Snowflake budget limit for PROD (integer or float)
}
aws_limit = lookup(local.aws_limits, var.environment)
snowflake_limit = lookup(local.snowflake_limits, var.environment)
}3. KANÄLE FÜR BENACHRICHTUNGEN EINRICHTEN
Benachrichtigungen werden über AWS SNS (Simple Notification Service) gesteuert.
So werden Budgetwarnungen zeitnah an die relevanten Teammitglieder zugestellt.
- Mehrere Teammitglieder können das SNS-Topic abonnieren.
- Sobald die Ausgaben die definierte Schwelle überschreiten, wird automatisch eine E-Mail an alle hinterlegten Empfänger:innen gesendet.
Die Terraform-Konfiguration für diese Benachrichtigungsressourcen wurde definiert in:
- aws_alarm.tf → verwaltet AWS Budgetwarnungen
- snowflake_alarm.tf → verwaltet Snowflake Budgetwarnungen
Terraform-Code-Beispiel:
resource "aws_sns_topic" "aws_budget_alerts" {
# AWS SNS topic for AWS budget notifications
...
}
resource "aws_sns_topic_subscription" "aws_budget_emails" {
# Email subscriptions for AWS budget alerts
...
}
resource "aws_sns_topic" "snowflake_budget_alerts" {
# AWS SNS topic for Snowflake budget notifications
...
}
resource "aws_sns_topic_subscription" "snowflake_budget_emails" {
# Email subscriptions for Snowflake budget alerts
...
}Jede:r Abonnent:in erhielt nach der Bereitstellung der Konfiguration eine E-Mail-Einladung, um das Abonnement zu bestätigen.
Wer Budgetwarnungen erhalten sollte, wurde in der Datei variables.tf über die Variable budget_alert_emails festgelegt. Dort wurden die entsprechenden E-Mail-Adressen eingetragen:
variable "budget_alert_emails" {
type = list(string)
default = [
"your-first-email-address",
"your-second-email-address",
]
}Es lassen sich beliebig viele Empfänger:innen hinzufügen.
Beim Ausführen von Terraform erhalten alle gelisteten Empfänger:innen Bestätigungs-E-Mails von AWS SNS und müssen die Einladungen annehmen, um Benachrichtigungen zu erhalten.
4. AWS BUDGET KONFIGURIEREN
AWS Budgets überwacht fortlaufend die monatlichen AWS-Kosten und vergleicht sie mit dem Budget.
Wir haben die Warnschwelle auf 130 Prozent des definierten Budgetlimits gesetzt. Dieser Puffer hilft, ungewöhnliche Kostensprünge zu erkennen und Fehlalarme zu minimieren.
resource "aws_budgets_budget" "aws_monthly_cost_budget" { ...
notification {
comparison_operator = "GREATER_THAN"
threshold = 130
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_sns_topic_arns = [
aws_sns_topic.aws_budget_alerts.arn
]
}}Sobald die Kosten 130 Prozent des definierten Budgetlimits überschreiten, löst AWS Budgets eine Benachrichtigung aus und setzt sich anschließend für den nächsten Monat zurück.
5. SNOWFLAKE KOSTEN MONITOREN
Um Snowflake-Kosten automatisch zu überwachen, fragt eine Lambda-Funktion die Nutzungsdaten täglich ab und sendet eine Warnung, sobald die Kosten die definierte Schwelle überschreiten.
5.1. Snowflake-User und -Rolle anlegen
Zunächst haben wir einen dedizierten Snowflake-User und eine passende Rolle angelegt, damit AWS Lambda sicher verbinden und Kostendaten abfragen konnte.
Um dies zu tun, haben wir die folgenden SQL-Befehle direkt in Snowflake ausgeführt:
CREATE ROLE IF NOT EXISTS BILLING_MONITOR;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE BILLING_MONITOR;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE BILLING_MONITOR;
CREATE USER IF NOT EXISTS LAMBDA_SNOWFLAKE_COST
PASSWORD = ''
DEFAULT_ROLE = BILLING_MONITOR
DEFAULT_WAREHOUSE = COMPUTE_WH
MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE BILLING_MONITOR TO USER LAMBDA_SNOWFLAKE_COST;
ALTER USER LAMBDA_SNOWFLAKE_COST SET RSA_PUBLIC_KEY='ABCD';- Der Public Key wurde in Snowflake gespeichert (
RSA_PUBLIC_KEY). - Der Private Key wurde sicher im AWS Systems Manager Parameter Store hinterlegt (siehe nächster Schritt).
5.2 Anmeldedaten im AWS Parameter Store speichern
Anschließend erstellten wir im AWS Systems Manager Parameter Store einen Eintrag mit dem Namen snowflake_cost_alarm.
In diesem Parameter werden die Snowflake-Zugangsdaten sicher gespeichert (User, Account, Rolle, Warehouse und Private Key).
Beispielstruktur (Werte aus Sicherheitsgründen weggelassen):
{
"user": "lambda_snowflake_cost",
"account": "your-snowflake-account",
"warehouse": "default_wh",
"role": "billing_monitor",
"private_key": "-----BEGIN PRIVATE KEY-----\nABCDE..."
}So kann die Lambda-Funktion die Zugangsdaten dynamisch abrufen, ohne sensible Informationen hart im Code zu hinterlegen.
5.3 Lambda-Funktion zum Abfragen der Snowflake-Nutzung
Eine Lambda-Funktion prüft täglich die Snowflake-Nutzung.
Sie fragt die Tabelle SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY ab, um den gesamten Credit-Verbrauch des aktuellen Monats zu berechnen.
Python-Code-Auszug:
first_day_of_current_month = today.replace(day=1)
cur.execute(f"""
SELECT SUM(CREDITS_USED) AS total_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE DATE_TRUNC('month', START_TIME)::DATE = '{first_day_of_current_month}'
""")
result = cur.fetchone()
credits_used = result[0] or 0
logging.info (f"Credits used are {credits_used} for this month {first_day_of_month}")
cost_usd = float(credits_used) * 2.60
threshold = float(snowflake_limit) * 1.30
# Compare against the threshold and send an SNS alert if exceeded
if cost_usd > threshold:
sns = boto3.client("sns")
sns.publish(
TopicArn=topic_arn,
Subject=f"Snowflake cost alert for {environment} environment",
Message=f"Snowflake cost for {year_month} month is ${cost_usd:.2f}, exceeding threshold ${threshold:.2f}."
)Die Lambda-Funktion ruft die Anmeldedaten automatisch aus dem AWS Systems Manager Parameter Store ab, stellt per schlüsselbasierter Authentifizierung eine Verbindung zu Snowflake her und veröffentlicht Warnungen im konfigurierten SNS-Topic, wenn die Nutzung die Warnschwelle überschreitet, die als 130 Prozent des in locals.tf definierten Budgetlimits berechnet wird.
5.4 Tägliche Ausführung über EventBridge planen
Die Lambda-Funktion wird täglich durch eine Amazon EventBridge-Regel um 10:00 UTC ausgelöst.
# ---------- EventBridge Rule ----------
resource "aws_cloudwatch_event_rule" "daily" {
name = "snowflake-cost-checker-daily"
description = "Triggers Snowflake cost checker Lambda every day at 10:00 UTC"
schedule_expression = "cron(0 10 * * ? *)"
}
# ---------- EventBridge Target ----------
resource "aws_cloudwatch_event_target" "lambda_trigger" {
rule = aws_cloudwatch_event_rule.daily.name
target_id = "SnowflakeCostCheckerLambda"
arn = aws_lambda_function.snowflake_cost_checker.arn
}5.5 Berechtigungen
Die Lambda-Ausführungsrolle umfasst die erforderlichen Berechtigungen, um:
- Parameter aus dem AWS Systems Manager Parameter Store (SSM Parameter Store) abzurufen
- Nachrichten an AWS SNS Topics zu veröffentlichen
- Mit Amazon EventBridge für terminierte Auslösungen zu interagieren
Diese IAM-Berechtigungen (Identity and Access Management) gewährleisten einen sicheren, automatisierten Betrieb des Monitoring-Workflows.
6. INFRASTRUKTUR MIT TERRAFORM BEREITSTELLEN
Sobald Terraform-Code, Budgets, SNS-Themen und Lambda-Funktionen konfiguriert waren, konnten wir die Monitoring-Pipeline bereitstellen.
Der Bereitstellungs-Workflow war für DEV und PROD identisch. Der einzige Unterschiede betreffen die Backend-Konfiguration und die Umgebungsvariable.
6.1 Terraform installieren
Wenn Sie diese Schritte nachvollziehen möchten, stellen Sie sicher, dass Terraform auf Ihrem Rechner installiert ist. Sie können es von der offiziellen Terraform-Website herunterladen und den Installationsanweisungen für Ihr Betriebssystem folgen.
Überprüfen Sie die Installation:
terraform version6.2 Terraform initialisieren
Initialisieren Sie Terraform in Ihrem Arbeitsverzeichnis. Dadurch werden alle benötigten Module und Provider geladen und das Remote-Backend eingerichtet.
Für die DEV-Umgebung:
terraform init -backend-config="backend/dev.tfbackend" -migrate-stateFür die PROD-Umgebung ändern Sie einfach die Backend-Datei:
terraform init -backend-config="backend/prod.tfbackend" -migrate-stateDie Markierung-migrate-state stellt sicher, dass der State bei Bedarf korrekt in den konfigurierten S3-Bucket migriert wird.
6.3 Geplante Änderungen prüfen
Vor der Anwendung prüfen Sie bitte, welche Ressourcen erstellt, geändert oder gelöscht werden:
terraform plan -var environment="dev"Für PROD:
terraform plan -var environment="prod"Prüfen Sie die Ausgabe sorgfältig, damit die Änderungen Ihren Erwartungen entsprechen.
6.4 Änderungen anwenden
Sobald der Plan passt, wenden Sie die Änderungen an:
terraform apply -var environment="dev"Bestätigen Sie die Ausführung, wenn Sie dazu aufgefordert werden.
Für PROD führen Sie aus:
terraform apply -var environment="prod"
Proaktives Monitoring von Cloud-Kosten ist nicht nur Technik, sondern vor allem finanzielle Steuerung.
Mit automatisierten Warnungen für AWS und Snowflake können Unternehmen:
- Unerwartete Budgetüberschreitungen vermeiden
- Zeit der Engineering-Teams für manuelle Prüfungen einsparen
- Cloud-Kosten planbarer machen und damit Planung und Ressourceneinsatz verbessern
Kurz gesagt: den Überblick haben, Geld sparen und die Kontrolle behalten.
“Uns ist wichtig, dass Teams durch unsere Hilfe die Übersicht behalten können. Benachrichtigungen sollen nur dann kommen, wenn sie wirklich nötig sind. Darum setzen wir die Schwelle bei 130 Prozent. Warnungen bei 70 Prozent führen oft zur Gewöhnung. Eine präzise E-Mail im richtigen Moment verhindert Eskalation und ermöglicht rechtzeitiges Gegensteuern, bevor die Rechnung überrascht.”
Federico Erroi, Senior Data Engineering Specialist
Hopmann Marketing Analytics