AWS-Kostensteuerung: Die fünf Praktiken, die Ihre Rechnung beherrschbar machen

Vor einigen Wochen schloss ich ein Kostenoptimierungsprojekt bei einem Münchner SaaS-Unternehmen ab. Die AWS-Rechnung war in zehn Monaten von 16.000 EUR auf 28.000 EUR gestiegen — nicht durch einen einzelnen Vorfall, sondern weil niemand die Ausgaben systematisch beobachtete. Als wir genauer hinsahen, fanden wir das Übliche: überdimensionierte Instanzen, vergessene Dev-Umgebungen, Cross-Region-Datentransfer zwischen Services, die besser in derselben Region laufen sollten. Aber der eigentliche Grund war einfacher: Es gab kein System, das Kostendrift frühzeitig sichtbar macht. Kosten waren unsichtbar, bis sie es nicht mehr waren.

Notfallmaßnahmen sind das, was man tut, nachdem die Rechnung explodiert ist. Kostensteuerung ist das, was man aufbaut, damit die Explosion gar nicht erst passiert. Dieser Beitrag handelt vom Aufbau dieses Systems.

In mehr als 15 Jahren AWS-Consulting habe ich FinOps-Programme für Accounts von 5.000 EUR/Monat bis zu siebenstelligen Jahresausgaben aufgebaut. Die Unternehmen, die dauerhaft 20-35 % weniger ausgeben als vergleichbare Betriebe, teilen fünf Praktiken. Keine davon ist technisch besonders anspruchsvoll. Alle erfordern konsequente Durchführung.

1. Verpflichtendes Tagging: Jeden Euro zuordenbar machen

Was man nicht messen kann, kann man nicht optimieren. Was man nicht zuordnen kann, kann man nicht messen. Tagging ist das Fundament jedes FinOps-Programms — und der Bereich, in dem der Aufwand am unattraktivsten wirkt und der Nutzen am direktesten ist.

Der typische Fehler: Tagging wird als optionale Hygienemaßnahme behandelt. Ein Jahr später sind 40-60 % der Ressourcen ungetaggt, und die Kostendaten in Cost Explorer sind für Accountability-Zwecke wertlos.

Das Tag-Schema, das in der Praxis funktioniert:

Nach vielen Experimenten habe ich mich auf vier verpflichtende Tags für jede Ressource in jedem Account geeinigt:

Tagging mit Tag-Policies und AWS Config durchsetzen:

Tag Policies auf Ebene der AWS Organizations verhindern, dass Ressourcen ohne Pflicht-Tags erstellt werden:

# Tag-Policy erstellen, die den 'project'-Tag vorschreibt
aws organizations create-policy \
  --name "ProjektTagPflicht" \
  --type TAG_POLICY \
  --description "Pflicht-Tag 'project' für alle taggbaren Ressourcen" \
  --content '{
    "tags": {
      "project": {
        "tag_key": {
          "@@assign": "project"
        },
        "enforced_for": {
          "@@assign": [
            "ec2:instance",
            "ec2:volume",
            "rds:db",
            "lambda:function",
            "ecs:service",
            "s3:bucket"
          ]
        }
      }
    }
  }'

Für bestehende Ressourcen nutzen Sie die AWS Config Managed Rule required-tags, um nicht-konforme Ressourcen zu finden:

# Wie viele Ressourcen fehlen Pflicht-Tags?
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name required-tags \
  --compliance-types NON_COMPLIANT \
  --query 'EvaluationResults[*].EvaluationResultIdentifier.EvaluationResultQualifier.ResourceId' \
  --output table

Cost-Allocation-Tags in Cost Explorer aktivieren:

# Verfügbare Tags prüfen
aws ce list-cost-allocation-tags \
  --status Inactive \
  --query 'CostAllocationTags[*].[TagKey,Status]' \
  --output table

# Wichtige Tags für die Kostenaufschlüsselung aktivieren
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status '[
    {"TagKey":"project","Status":"Active"},
    {"TagKey":"environment","Status":"Active"},
    {"TagKey":"team","Status":"Active"}
  ]'

Sobald die Tags aktiv sind, lässt sich Cost Explorer nach beliebigen Kombinationen dieser Dimensionen filtern. Bei jenem Münchner Kunden stellten wir nach dem Nachtaggen der Ressourcen fest, dass Dev- und Staging-Umgebungen zusammen 7.200 EUR/Monat kosteten — fast ein Viertel der Gesamtrechnung. Ohne den environment-Tag war dieser Anteil im Gesamtrauschen verschwunden.

Die Maßnahme: Dev-Instanzen nach 19 Uhr und am Wochenende automatisch abschalten, drei Staging-Umgebungen stilllegen, die seit vier Monaten ungenutzt liefen. Ersparnis: 4.800 EUR/Monat.

2. Dreistufige Budget-Alarme: Warnung bevor es zu spät ist

Ein einziger Budget-Alarm bei 100 % des Monatsbudgets ist wie ein Rauchmelder, der erst auslöst, wenn das Haus schon brennt. Wenn dieser Alarm kommt, ist der Monat vorbei.

Die Budget-Architektur, die ich für jeden Kunden einrichte, hat drei Stufen:

Stufe 1 — 50 %-Schwelle: Frühwarnung Dieser Alarm löst Mitte des Monats aus, wenn das aktuelle Ausgabetempo auf eine Überschreitung hinweist. Bei 50 % des Monatsbudgets bleibt noch eine halbe Monatszeit zur Gegensteuerung.

Stufe 2 — 80 %-Schwelle: Handlungsbedarf Bei 80 % müssen Sie aktiv nachforschen. Dieser Alarm trifft typischerweise in der letzten Woche des Monats ein. Die Reaktion: identifizieren, was die Überschreitung treibt, und entweder nicht-kritische Workloads stoppen oder die Mehrausgabe bewusst genehmigen.

Stufe 3 — 100 %-Schwelle: Eskalation Bei 100 % geht es an die Führungsebene — nicht als Schuldbekenntnis, sondern als Signal, dass entweder das Budget angepasst oder eine grundlegende Architekturentscheidung getroffen werden muss.

Die Drei-Stufen-Konfiguration in der CLI:

# Monatsbudget anlegen
aws budgets create-budget \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --budget '{
    "BudgetName": "Monatsbudget-AWS-Gesamt",
    "BudgetLimit": {"Amount": "25000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 50,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "finops@beispiel.de"}
      ]
    },
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "finops@beispiel.de"},
        {"SubscriptionType": "EMAIL", "Address": "engineering-leitung@beispiel.de"}
      ]
    },
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 100,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "finops@beispiel.de"},
        {"SubscriptionType": "EMAIL", "Address": "cto@beispiel.de"}
      ]
    }
  ]'

Prognosealarm für frühzeitige Anomalieerkennung:

Prognosealame sind oft unterschätzt, aber sehr wertvoll. Sie lösen aus, wenn AWS auf Basis des aktuellen Ausgabetempos projiziert, dass das Monatsbudget überschritten wird — auch wenn der Schwellenwert noch nicht erreicht ist:

# Prognose-Alarm bei 110 %
aws budgets create-budget \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --budget '{
    "BudgetName": "Monatsbudget-Prognose",
    "BudgetLimit": {"Amount": "25000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[
    {
      "Notification": {
        "NotificationType": "FORECASTED",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 110,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "finops@beispiel.de"}
      ]
    }
  ]'

Team-spezifische Budgets für dezentrale Accountability:

Zusätzlich zum Account-Gesamtbudget lohnen sich Team-Budgets mit Cost-Allocation-Tag-Filtern. Damit wird die Verantwortung direkt beim Team verankert, das die Kosten verursacht:

# Budget für das Data-Platform-Team
aws budgets create-budget \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --budget '{
    "BudgetName": "Team-DataPlatform",
    "BudgetLimit": {"Amount": "7000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "CostFilters": {
      "TagKeyValue": ["user:team$data-platform"]
    }
  }' \
  --notifications-with-subscribers '[
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {"SubscriptionType": "EMAIL", "Address": "data-team-lead@beispiel.de"}
      ]
    }
  ]'

Wenn Team-Leads ihre eigenen Budget-Alarme empfangen, wird die AWS-Rechnung ihr Problem — nicht nur das des zentralen FinOps-Teams. Diese Verschiebung der Eigenverantwortung ist oft mehr wert als jede technische Optimierungsmaßnahme.

3. Savings-Plan-Lifecycle: Zielgerichtet committen

Savings Plans sind eines der wirksamsten Instrumente zur AWS-Kostensenkung — aber sie erfordern Disziplin. Ich habe Kunden gesehen, die 35-45 % ihrer Compute-Kosten durch gut verwaltete Savings Plans gespart haben, und ich habe Kunden gesehen, die nach übereilten Käufen in ungünstigen Commitments feststeckten.

Die Grundregel: Erst optimieren, dann committen. Ein Savings Plan bindet für ein oder drei Jahre. Wer committed, bevor er rechtsgesized hat, zahlt unter Umständen für Kapazitäten, die er danach nicht mehr braucht.

Die richtige Reihenfolge:

1. Waste eliminieren und rechtsizen (4-6 Wochen)
2. Stabile Grundlast 2-4 Wochen beobachten
3. Savings Plans für 60-70 % der Grundlast kaufen (konservativ starten)
4. Quartalsweise überprüfen und bei Bedarf aufstocken

Aktuelle Coverage und Utilization prüfen:

# Savings-Plan-Coverage der letzten 30 Tage
aws ce get-savings-plans-coverage \
  --time-period Start=2026-01-15,End=2026-02-15 \
  --granularity MONTHLY \
  --metrics "CoverageHours" \
  --query 'SavingsPlansCoverages[*].Coverage'

# Utilization: Wird genutzt, was gekauft wurde?
aws ce get-savings-plans-utilization \
  --time-period Start=2026-01-15,End=2026-02-15 \
  --query 'Total.Utilization'

Liegt die Utilization unter 80 %, haben Sie zu viel committed — Sie zahlen für Savings-Plan-Credits, die Sie nicht nutzen. Liegt die Coverage unter 50 %, gibt es erhebliche nicht-committete Ausgaben, die von einem Kauf profitieren würden.

AWS-Kaufempfehlung abrufen:

# Compute Savings Plan Empfehlung — 1 Jahr, keine Vorauszahlung
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[0:3]'

Compute SP vs. EC2 Instance SP — wann welchen Typ wählen:

Starten Sie immer mit Compute Savings Plans. Sie bieten die Flexibilität, Instanztypen zu wechseln, Regionen zu ändern und Workloads zu Fargate oder Lambda zu verschieben, ohne das Commitment zu verlieren. EC2 Instance Savings Plans sind erst dann sinnvoll, wenn Sie absolut sicher sind, dass eine bestimmte Instanzfamilie für das nächste Jahr stabil bleibt.

Quartalsweise Review im Kalender verankern:

Tragen Sie am ersten Montag jedes Quartals einen festen 30-Minuten-Termin ein: Coverage prüfen, Utilization prüfen, neue Kaufempfehlungen prüfen, Entscheidung über zusätzliches Commitment treffen. Dieses Ritual ist bares Geld wert.

4. Compute Optimizer: Kontinuierliches Rightsizing

Rightsizing ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Workloads verändern sich. Traffic-Muster verschieben sich. Wer vor sechs Monaten optimiert hat, läuft heute bereits wieder mit suboptimalen Instanzen.

AWS Compute Optimizer analysiert Ihre CloudWatch-Metriken und empfiehlt den kosteneffizientesten Instanztyp, die optimale Lambda-Speicherkonfiguration und die passende ECS-Task-Definition für jede Ressource. Der Dienst ist kostenlos zu aktivieren und identifiziert in meiner Erfahrung konsistent 15-25 % zusätzliche Ersparnis über das hinaus, was Teams manuell finden.

Compute Optimizer aktivieren:

# Compute Optimizer für den Account aktivieren
aws compute-optimizer update-enrollment-status --status Active

# Bei Organizations: alle Member-Accounts einschließen
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

Compute Optimizer benötigt mindestens 14 Tage CloudWatch-Daten für Empfehlungen. Für maximale Genauigkeit empfehle ich, 30 Tage nach der Aktivierung mit der ersten Auswertung zu starten.

EC2-Empfehlungen in der Übersicht:

# Alle EC2-Empfehlungen — sortiert nach potenziellem Einsparpotenzial
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[*].{
    Instanz:instanceArn,
    AktuellerTyp:currentInstanceType,
    EmpfohlenerTyp:recommendationOptions[0].instanceType,
    Bewertung:finding,
    Ersparnis:recommendationOptions[0].estimatedMonthlySavings.value
  }' \
  --output table

Lambda-Memory-Optimierung:

Lambda wird im Rightsizing-Prozess oft vergessen, weil die Beträge pro Funktion gering erscheinen. Aber in Summe ist das Potenzial erheblich: Eine Funktion mit 1.024 MB allokiertem Memory, die nur 180 MB nutzt, zahlt 5,7-mal zu viel.

# Lambda-Empfehlungen von Compute Optimizer
aws compute-optimizer get-lambda-function-recommendations \
  --query 'lambdaFunctionRecommendations[*].{
    Funktion:functionArn,
    AktuellesMemory:currentMemorySize,
    EmpfohlenesMemory:memorySizeRecommendationOptions[0].memorySize,
    Bewertung:finding
  }' \
  --output table

Rightsizing als Sprint-Aufgabe etablieren:

Teams, die den größten Nutzen aus Compute Optimizer ziehen, behandeln Rightsizing wie einen Produkt-Backlog-Eintrag. Alle zwei Wochen zieht jemand die Empfehlungen, priorisiert nach Einsparpotenzial und erstellt Tickets für die größten Möglichkeiten. Ein typischer Account mit 50-100 EC2-Instanzen hat pro Zyklus 5-10 umsetzbare Empfehlungen, von denen jede 30-60 Minuten Aufwand bedeutet.

Über ein Quartal bringt diese Kadenz typischerweise 10-20 % zusätzliche Compute-Kostenreduzierung.

5. FinOps-Kultur: Kosten zur gemeinsamen Verantwortung machen

Die vier vorangegangenen Praktiken sind technischer Natur. Diese hier ist organisatorisch — und sie ist in meiner Erfahrung die schwierigste und wichtigste.

In Teams ohne FinOps-Kultur ist die AWS-Rechnung das Problem von jemand anderem. Entwickler provisionieren, was sie brauchen, ohne über die Kosten nachzudenken. Produktmanager priorisieren Features ohne Berücksichtigung der Betriebskosten. Die Finanzabteilung sieht am Monatsende eine Zahl und stellt vage Fragen. Die Lücke zwischen denen, die Kosten verursachen, und denen, die dafür verantwortlich sind, ist das, was Waste ermöglicht.

Der zentrale Wandel: Von zentraler Verantwortung zu dezentraler Accountability

Statt eines zentralen FinOps-Teams, das für die Kosten aller verantwortlich ist, ist das Ziel ein Modell, in dem jedes Team seine eigenen AWS-Ausgaben besitzt. Die FinOps-Funktion liefert Werkzeuge, Governance und Coaching — keine Kostenpolizei.

Monatliches Kosten-Review als Ritual:

Das wirksamste Werkzeug, das ich kenne, ist ein einfaches monatliches Review-Meeting. Jeder Team-Lead kommt vorbereitet mit drei Zahlen: Ausgaben des letzten Monats nach Team-Tag, Abweichung vom Budget, und die drei größten Kostentreiber. Das Meeting läuft 30 Minuten. Anomalien werden offen besprochen.

Das klingt banal. Kein einziger meiner Kunden hat das vor unserem gemeinsamen Engagement konsequent durchgeführt.

Kosten-Dashboard für alle sichtbar machen:

# Cost-Category-Definition für Team-Attribution anlegen
aws ce create-cost-category-definition \
  --name "Team-Attribution" \
  --rules '[
    {
      "Value": "Platform",
      "Rule": {
        "Tags": {
          "Key": "team",
          "Values": ["platform"]
        }
      }
    },
    {
      "Value": "Growth",
      "Rule": {
        "Tags": {
          "Key": "team",
          "Values": ["growth"]
        }
      }
    },
    {
      "Value": "DataPlatform",
      "Rule": {
        "Tags": {
          "Key": "team",
          "Values": ["data-platform"]
        }
      }
    }
  ]' \
  --rule-version "CostCategoryExpression.v1"

Automatisiertes Herunterfahren von Nicht-Produktionsumgebungen:

Eine der wirksamsten Governance-Maßnahmen ist das automatische Abschalten von Dev- und Staging-Umgebungen außerhalb der Geschäftszeiten. Eine Dev-Instanz vom Typ m5.xlarge in eu-central-1, die 24/7 läuft, kostet rund 130 EUR/Monat. Dieselbe Instanz, die nur Montag bis Freitag von 08:00 bis 20:00 läuft, kostet rund 48 EUR/Monat — 63 % Ersparnis ohne jeden Produktivitätsverlust.

# Dev-Instanzen mit Auto-Shutdown-Tag versehen
aws ec2 create-tags \
  --resources i-0abc123def456 i-0def789abc012 \
  --tags Key=AutoShutdown,Value=enabled Key=environment,Value=dev

# Abends um 19:00 herunterfahren (Systems Manager Automation)
aws ssm create-association \
  --name "AWS-StopEC2Instance" \
  --targets '[{"Key":"tag:AutoShutdown","Values":["enabled"]}]' \
  --schedule-expression "cron(0 19 ? * MON-FRI *)" \
  --association-name "DevUmgebung-Herunterfahren"

# Morgens um 07:00 starten
aws ssm create-association \
  --name "AWS-StartEC2Instance" \
  --targets '[{"Key":"tag:AutoShutdown","Values":["enabled"]}]' \
  --schedule-expression "cron(0 7 ? * MON-FRI *)" \
  --association-name "DevUmgebung-Starten"

Der Governance-Kalender

Die fünf Praktiken bilden ein System, keine Checkliste. So fügen sie sich in einen regelmäßigen Rhythmus:

Wöchentlich (15 Minuten):

• Budget-Alarme prüfen: Liegt die Ausgabenentwicklung im erwarteten Bereich?
• AWS Cost Anomaly Detection Benachrichtigungen lesen

# Anomalie-Erkennung mit wöchentlichem Digest einrichten
aws ce create-anomaly-subscription \
  --anomaly-subscription '{
    "SubscriptionName": "WoechentlicheKostenAnomalie",
    "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/MONITOR_ID"],
    "Subscribers": [
      {"Address": "finops@beispiel.de", "Type": "EMAIL"}
    ],
    "Threshold": 100,
    "Frequency": "WEEKLY"
  }'

Monatlich (60 Minuten):

• Cost-Explorer-Report nach Team und Umgebung auswerten
• Compute-Optimizer-Empfehlungen prüfen, Top-5-Tickets anlegen
• Savings-Plan-Coverage und Utilization prüfen
• Ungenutzte Ressourcen identifizieren und aufräumen

Quartalsweise (90 Minuten):

• Savings-Plan-Kaufempfehlungen prüfen, ggf. nachkaufen
• Team-Budgets auf Basis der tatsächlichen Ausgaben anpassen
• Tag-Policies aktualisieren, wenn neue Teams oder Projekte entstanden sind
• Auto-Shutdown-Konfigurationen überprüfen und aktualisieren

Was das in der Praxis bedeutet

Der Münchner Kunde, den ich zu Beginn erwähnte: Sechs Monate nach Einführung der fünf Praktiken liegt seine Rechnung bei 17.000 EUR/Monat — von 28.000 EUR auf dem Höhepunkt. Wichtiger noch: Kostenüberraschungen gibt es nicht mehr. Jeder Anstieg ist im Voraus sichtbar, einem Team zugeordnet und im monatlichen Review besprochen.

Die Ersparnis im Überblick:

• Tagging + Attribution → 4.800 EUR/Monat aus ungenutzten Dev-Umgebungen identifiziert
• Budget-Alarme → Datentransfer-Anomalie im zweiten Monat frühzeitig erkannt, 1.600 EUR gespart
• Savings Plans → 30 % Rabatt auf 9.000 EUR committete Compute-Ausgaben, 2.700 EUR/Monat
• Compute Optimizer → 20 % Rightsizing-Reduktion auf EC2-Flotte, 1.800 EUR/Monat
• Automatisierte Abschaltung → 1.100 EUR/Monat durch optimierte Nicht-Produktionsumgebungen

Das sind zusammen rund 12.000 EUR/Monat wiederkehrende Ersparnis — ohne Neuarchitektur, ohne Leistungseinbußen, allein durch konsequente Governance.

Wo anfangen

Wenn Sie ein Kostensteuerungsprogramm von Grund auf aufbauen wollen, starten Sie mit Tagging — alles andere hängt davon ab. Die zweite Priorität ist das dreistufige Budget-Setup, weil es Frühwarnung liefert, während Sie die restlichen Praktiken aufbauen.

Buchen Sie ein kostenloses 30-minütiges Erstgespräch und ich gehe Ihre aktuelle Cost-Explorer-Konfiguration mit Ihnen durch, identifiziere, wo Governance fehlt, und erstelle einen priorisierten Maßnahmenplan für Ihren Account.