Cloud-Kostenoptimierung: Hören Sie auf, zu viel für Ihr MVP zu bezahlen

Letztes Quartal habe ich die AWS-Rechnung eines Startups geprüft und festgestellt, dass sie 2.800 $/Monat für Infrastruktur ausgaben, die bequem für 900 $ laufen könnte. Sie hatten eine t3.2xlarge, die eine Node.js-API betrieb, die bei maximal 12 % CPU-Auslastung lag. Drei ungenutzte Elastic IPs, die zu je 3,65 $/Monat untätig herumlagen. Ein RDS Multi-AZ Deployment für eine Datenbank mit 200 Zeilen. Ein NAT Gateway, das Traffic routete, der über einen VPC Endpoint kostenlos hätte laufen können. Nichts davon war böswillig oder besonders nachlässig — es war die Ansammlung von „provisioniere einfach etwas, das funktioniert"-Entscheidungen, die während eines Sprints zum Ausliefern getroffen wurden.

Das ist die Norm, nicht die Ausnahme. Die meisten Startups in der Frühphase verschwenden 40-60 % ihrer Cloud-Ausgaben, weil niemand im Team die Zeit oder den Anreiz hat, Kosten zu optimieren, wenn es Features zu bauen gibt. Das Problem verstärkt sich: Sobald Infrastruktur provisioniert ist und funktioniert, fasst sie niemand mehr an.

Die größten Kostenfallen, die ich immer wieder sehe

Bevor wir uns den Lösungen widmen, hilft es zu verstehen, wohin das Geld tatsächlich fließt. Das sind die Fallen, denen ich am häufigsten begegne, wenn ich Startup-Infrastruktur überprüfe.

Überdimensionierte Compute-Instanzen

Das ist die einzelne größte Quelle von Verschwendung. Teams wählen eine Instanzgröße während der Ersteinrichtung — meist basierend auf einem Blogbeitrag oder einer „zur Sicherheit"-Mentalität — und überprüfen sie nie wieder. Ich habe m5.xlarge-Instanzen gesehen, die Cron-Jobs ausführen, die 30 Sekunden pro Stunde laufen. Die Instanz sitzt 59,5 Minuten untätig herum und verbrennt 0,192 $/Stunde (140 $/Monat), um im Wesentlichen nichts zu tun.

Die Ursache ist psychologisch: Niemand will die Person sein, die den Server unterdimensioniert hat und einen Ausfall verursacht hat. Also rundet jeder auf. Doppelt.

# Check your EC2 instance CPU utilization over the past 2 weeks
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum

Wenn Ihre durchschnittliche CPU unter 20 % und Ihr Spitzenwert unter 50 % liegt, sind Sie mit ziemlicher Sicherheit überdimensioniert. Reduzieren Sie um eine oder zwei Instanzgrößen, überwachen Sie eine Woche und passen Sie an.

Vergessene EBS-Volumes und Snapshots

Wenn Sie eine EC2-Instanz beenden, werden die angeschlossenen EBS-Volumes nicht automatisch gelöscht, es sei denn, Sie haben das beim Start konfiguriert. Das bedeutet, dass beendete Instanzen verwaiste Volumes hinterlassen, die weiter abgerechnet werden. Ich habe Accounts mit Dutzenden unattached gp3-Volumes gesehen, die jeweils 0,08 $/GB/Monat kosten, insgesamt Hunderte Dollar für Storage, den niemand nutzt.

Snapshots sind noch heimtückischer. Automatisierte Backup-Skripte erstellen tägliche Snapshots ohne Lifecycle-Policy, sodass sie sich unbegrenzt ansammeln. Ein 500-GB-Volume, das täglich ein Jahr lang gesnapshot wird, erzeugt 365 Snapshots, und obwohl EBS-Snapshots inkrementell sind, summieren sich die Kosten zu echtem Geld.

# Find all unattached EBS volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Find snapshots older than 90 days
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-12-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
  --output table

NAT Gateway: Der stille Budget-Killer

NAT Gateways kosten 0,045 $/Stunde (32,40 $/Monat) allein für ihre Existenz, plus 0,045 $ pro GB verarbeiteter Daten. Für ein Startup, das häufig API-Aufrufe an externe Dienste aus privaten Subnetzen macht, können die Datenverarbeitungsgebühren allein 100 $/Monat übersteigen. Ich habe gesehen, wie NAT-Gateway-Kosten 15-20 % der gesamten AWS-Rechnung eines kleinen Startups ausmachten.

Die Lösung hängt davon ab, welcher Traffic durch das NAT fließt:

• Traffic zu AWS-Diensten (S3, DynamoDB, SQS): Verwenden Sie VPC Gateway Endpoints (kostenlos für S3 und DynamoDB) oder Interface Endpoints (7,20 $/Monat pro Stück, aber immer noch günstiger als NAT für Hochvolumen-Traffic).
• Traffic zum Internet von Lambda-Funktionen: Überlegen Sie, ob diese Funktionen tatsächlich in einem VPC sein müssen. Viele Lambda-Funktionen werden „für die Sicherheit" in ein VPC platziert, obwohl sie auf keine VPC-Ressourcen zugreifen.
• Geringes ausgehendes Traffic-Volumen: Eine NAT-Instanz auf einer t4g.nano (3,02 $/Monat) bewältigt moderaten Traffic für einen Bruchteil der NAT-Gateway-Kosten.

Data-Transfer-Gebühren

AWS berechnet 0,09 $/GB für Daten, die eine Region verlassen, und Cross-AZ-Traffic kostet 0,01 $/GB in jede Richtung. Diese Gebühren sind unsichtbar, bis sie es nicht mehr sind. Eine geschwätzige Microservices-Architektur, die über drei Availability Zones verteilt ist und deren Services sich hundertmal pro Sekunde gegenseitig aufrufen, kann überraschende Data-Transfer-Rechnungen erzeugen.

Die architektonische Lösung: Services, die häufig kommunizieren, in derselben AZ für nicht-kritische Workloads zusammenlegen, oder interne Load Balancer mit AZ-Affinität verwenden.

Richtig-Dimensionierung: Ein systematischer Ansatz

Richtig-Dimensionierung ist keine einmalige Übung. Sie sollte vierteljährlich überprüft werden. Hier ist der Prozess, dem ich folge.

Schritt 1: Auslastungsdaten sammeln

AWS Compute Optimizer ist kostenlos und liefert Right-Sizing-Empfehlungen für EC2, EBS, Lambda und ECS. Aktivieren Sie ihn und lassen Sie ihn mindestens 14 Tage Daten sammeln, bevor Sie auf seine Empfehlungen reagieren.

Für granularere Analyse sind CloudWatch-Metriken Ihre primäre Datenquelle. Die wichtigsten Metriken:

• EC2: CPUUtilization, NetworkIn/Out, MemoryUtilization (erfordert CloudWatch Agent)
• RDS: CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS
• ElastiCache: CPUUtilization, CurrConnections, BytesUsedForCache

Schritt 2: Workloads kategorisieren

Nicht jeder Workload sollte gleich dimensioniert werden. Ich kategorisiere sie in drei Gruppen:

Gleichmäßige Workloads (API-Server, Datenbanken): Diese brauchen konsistente Kapazität. Dimensionieren Sie auf die kleinste Instanz, die die Spitzenlast mit 30 % Reserve bewältigt. Verwenden Sie Reserved Instances oder Savings Plans für die Baseline.

Variable Workloads (Batch-Verarbeitung, Build-Server): Diese sollten Auto Scaling Groups mit passenden Skalierungsrichtlinien verwenden, oder Spot Instances für fehlertolerante Batch-Jobs.

Periodische Workloads (Cron-Jobs, geplante Reports): Diese sollten überhaupt nicht auf dedizierten Instanzen laufen. Verlagern Sie sie auf Lambda, Fargate Spot oder Step Functions.

Schritt 3: Inkrementell handeln

Dimensionieren Sie nie alles auf einmal um. Reduzieren Sie jeweils eine Instanzgröße, überwachen Sie eine Woche und entscheiden Sie dann, ob Sie weitergehen. Die Kosten einer kurzen Überdimensionierungsphase sind weit geringer als die Kosten eines Produktionsausfalls durch aggressives Downsizing.

Reserved Instances vs Savings Plans vs Spot

Hier passieren die echten Einsparungen — 30-72 % Rabatt auf On-Demand-Preise — aber die Commitment-Mechanismen sind verwirrend genug, dass viele Startups sie einfach meiden.

Reserved Instances (RIs)

Sie verpflichten sich für einen bestimmten Instanztyp in einer bestimmten Region für 1 oder 3 Jahre. Dafür erhalten Sie 30-40 % Rabatt (ohne Vorauszahlung, 1 Jahr) bis 60 % Rabatt (vollständige Vorauszahlung, 3 Jahre). Der Haken: Wenn Sie Instanztypen ändern müssen, sind Standard-RIs nicht flexibel. Convertible RIs bieten mehr Flexibilität bei einem etwas geringeren Rabatt (etwa 45 % für 3-Jahres-Vorauszahlung).

Wann RIs verwenden: Datenbanken und andere Workloads, bei denen Instanztyp und -größe wirklich stabil sind. RDS Reserved Instances lohnen sich fast immer — Datenbanken ändern selten die Größe.

Savings Plans

Savings Plans sind die moderne Alternative zu RIs für Compute. Sie verpflichten sich zu einem Dollar-Betrag an Compute pro Stunde (z.B. 0,10 $/Stunde) für 1 oder 3 Jahre. Das Commitment gilt automatisch für EC2-, Fargate- und Lambda-Nutzung und ist flexibel über Instanzfamilien, Größen, Betriebssysteme und Regionen hinweg.

Wann Savings Plans verwenden: Fast immer EC2-RIs für Compute-Workloads vorzuziehen. Compute Savings Plans bieten das beste Verhältnis von Flexibilität zu Rabatt. Beginnen Sie mit einem Commitment, das Ihre Minimum-Baseline-Ausgaben abdeckt.

# Example: Calculating Savings Plan commitment
# Current on-demand spend: $500/month on EC2
# Minimum baseline (never drops below): $350/month
# Recommended Savings Plan commitment: $350/month = ~$0.48/hour
# Expected savings: ~30% on the committed amount = ~$105/month
# Remaining $150/month stays on-demand for flexibility

Spot Instances

Spot Instances bieten 60-90 % Rabatt, können aber mit 2 Minuten Vorwarnung unterbrochen werden. Sie eignen sich ideal für:

• CI/CD-Build-Agents (verwenden Sie Spot Fleet mit mehreren Instanztypen)
• Batch-Verarbeitungsjobs, die Checkpoints setzen und fortfahren können
• Entwicklungs- und Staging-Umgebungen
• Lasttests

Sie eignen sich nicht für Produktions-API-Server, Datenbanken oder alles, was keine plötzliche Beendigung verkraftet.

# Example: GitHub Actions self-hosted runner on Spot
# This saves roughly 70% compared to GitHub-hosted runners
# for compute-heavy builds
Resources:
  SpotFleet:
    Type: AWS::EC2::SpotFleet
    Properties:
      SpotFleetRequestConfigData:
        IamFleetRole: !GetAtt SpotFleetRole.Arn
        TargetCapacity: 2
        AllocationStrategy: lowestPrice
        LaunchSpecifications:
          - InstanceType: c5.xlarge
            SpotPrice: "0.06"
          - InstanceType: c5a.xlarge
            SpotPrice: "0.06"
          - InstanceType: c6i.xlarge
            SpotPrice: "0.06"

Serverless-Kostenmodelle: Nicht immer günstiger

Es gibt einen hartnäckigen Mythos, dass Serverless für Startups immer günstiger ist. Bei geringer Last ist es oft günstiger, aber die Wirtschaftlichkeit kippt mit zunehmendem Traffic.

Lambda-Preisrealität

Lambda berechnet pro Anfrage (0,20 $ pro Million) und pro GB-Sekunde Compute (0,0000166667 $). Für einen typischen API-Endpunkt, der 200 ms mit 256 MB Speicher läuft:

• 1.000 Anfragen/Tag: ~0,03 $/Monat. Praktisch kostenlos.
• 100.000 Anfragen/Tag: ~3,00 $/Monat. Immer noch sehr günstig.
• 1.000.000 Anfragen/Tag: ~30 $/Monat. Beginnt sich mit einer kleinen EC2-Instanz zu vergleichen.
• 10.000.000 Anfragen/Tag: ~300 $/Monat. Eine t3.medium (30 $/Monat) mit ordentlichem Caching bewältigt das problemlos.

Der Umkehrpunkt hängt stark von Ausführungsdauer und Speicherzuweisung ab, aber für die meisten API-Workloads ist Lambda irgendwo zwischen 1-5 Millionen Anfragen pro Tag nicht mehr kosteneffizient. Unter diesem Schwellenwert ist es fast immer die günstigste Option.

API Gateway-Kosten summieren sich

Man vergisst leicht, dass Lambda-Funktionen hinter API Gateway zusätzliche Kosten verursachen. API Gateway kostet 3,50 $ pro Million Anfragen (REST API) oder 1,00 $ pro Million (HTTP API). Bei Skalierung übersteigen die API-Gateway-Kosten die Lambda-Kosten. Wenn Sie genug Traffic haben, um sich über Lambda-Kosten Gedanken zu machen, sollten Sie Application Load Balancer (0,008 $ pro LCU-Stunde) statt API Gateway verwenden.

Fargate: Der Mittelweg

AWS Fargate liegt zwischen Lambda und EC2 in Kosten und operativer Komplexität. Sie zahlen für vCPU und Speicher pro Sekunde, ohne Instanzverwaltung. Für Workloads, die kontinuierlich laufen müssen, aber Sie keine Server verwalten möchten, bietet Fargate mit Spot Capacity Providers eine gute Balance.

Eine Fargate-Aufgabe mit 0,25 vCPU und 0,5 GB Speicher kostet etwa 9 $/Monat im Dauerbetrieb. Das ist wettbewerbsfähig mit einer t4g.nano, und Sie erhalten automatische Platzierung, Health Checks und Skalierung ohne Verwaltung des zugrundeliegenden Hosts.

Monitoring und Alerting bei Kosten

Was man nicht misst, kann man nicht optimieren. Hier ist der Monitoring-Stack, den ich für jedes Projekt einrichte.

AWS Cost Explorer

Aktivieren Sie Cost Explorer und richten Sie ein monatliches Budget mit Alerts bei 50 %, 80 % und 100 % Schwellenwerten ein. Das ist das Minimum. Die Ansicht „Kosten nach Service" im Cost Explorer zeigt sofort, wohin das Geld fließt.

# Create a budget with email alerts
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Monthly-Total",
    "BudgetLimit": {"Amount": "500", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "team@startup.com"
    }]
  }]'

Infracost für Infrastructure as Code

Wenn Sie Terraform verwenden, integriert sich Infracost in Ihre CI-Pipeline und zeigt Kostenschätzungen für jede Infrastrukturänderung, bevor sie angewendet wird. Das ist transformativ — es verschiebt das Kostenbewusstsein von einer monatlichen Überraschung zu einer Pull-Request-Diskussion.

# .github/workflows/infracost.yml
name: Infracost
on: pull_request
jobs:
  infracost:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}
      - name: Generate cost estimate
        run: |
          infracost breakdown --path=. \
            --format=json --out-file=/tmp/infracost.json
          infracost comment github \
            --path=/tmp/infracost.json \
            --repo=$GITHUB_REPOSITORY \
            --pull-request=${{ github.event.pull_request.number }} \
            --github-token=${{ secrets.GITHUB_TOKEN }}

Kostenanomalie-Erkennung

AWS Cost Anomaly Detection nutzt Machine Learning, um ungewöhnliche Ausgabenmuster zu identifizieren. Es ist kostenlos und sendet Alerts, wenn Ausgaben von historischen Mustern abweichen. Aktivieren Sie es für jeden Service und richten Sie SNS-Benachrichtigungen an Slack ein.

Architektur-Patterns, die Geld sparen

Über die Richtig-Dimensionierung einzelner Ressourcen hinaus ändern bestimmte architektonische Entscheidungen Ihre Kostenstruktur grundlegend.

Aggressives Caching

Eine CloudFront-Distribution vor Ihrer API für cachbare Antworten kostet 0,085 $/10.000 HTTPS-Anfragen und 0,085 $/GB Transfer — eliminiert aber diese Anfragen von Ihrem Backend. Für leseintensive APIs (was die meisten sind) bedeutet eine 90-prozentige Cache-Trefferquote, dass Ihr Backend 10x weniger Traffic verarbeitet.

Noch einfacher: Ein In-Memory-Cache wie Redis oder ein lokaler LRU-Cache in Ihrer Anwendung kann redundante Datenbankabfragen eliminieren. Ich habe gesehen, wie Datenbankkosten um 60 % sanken, nachdem ein 15-Minuten-Cache auf die 5 am häufigsten abgefragten Endpunkte gesetzt wurde.

S3 intelligent nutzen

S3 hat mehrere Storage-Klassen, und die richtige zu verwenden ist wichtig:

Storage-Klasse	Kosten/GB/Monat	Anwendungsfall
S3 Standard	0,023 $	Aktive Daten, häufiger Zugriff
S3 Infrequent Access	0,0125 $	Backups, Logs älter als 30 Tage
S3 Glacier Instant	0,004 $	Archive mit sofortigem Zugriff
S3 Glacier Deep Archive	0,00099 $	Langzeitarchive, seltener Zugriff

Richten Sie S3 Lifecycle Policies ein, um Objekte automatisch zwischen Storage-Klassen zu verschieben:

{
  "Rules": [
    {
      "ID": "TransitionToIA",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_INSTANT_RETRIEVAL"
        }
      ]
    }
  ]
}

Managed Services vs Self-Hosted

Dieser Kompromiss ist nuanciert. Managed Services (RDS, ElastiCache, OpenSearch Service) kosten mehr pro Compute-Einheit als Self-Hosting auf EC2, beinhalten aber Patching, Backups, Failover und Monitoring. Für ein Startup ohne dedizierten Ops-Mitarbeiter rechtfertigt die eingesparte Engineering-Zeit fast immer den Aufpreis.

Die Ausnahme: Managed Services auf den höchsten Stufen. Eine db.r6g.2xlarge RDS-Instanz kostet deutlich mehr als die äquivalente EC2-Instanz mit PostgreSQL. Sobald Sie ein ops-fähiges Team haben und mehr als 1.000 $/Monat für einen einzelnen Managed Service ausgeben, lohnt es sich, Self-Hosting zu evaluieren.

Konsolidieren wo möglich

Separate RDS-Instanzen für Staging-, QA- und Entwicklungsumgebungen zu betreiben ist teuer. Optionen:

• Verwenden Sie eine einzelne RDS-Instanz mit separaten Datenbanken für Nicht-Produktionsumgebungen.
• Verwenden Sie Aurora Serverless v2 für Dev/Staging — es skaliert auf null, wenn es inaktiv ist.
• Betreiben Sie Dev-Datenbanken auf einer einzelnen EC2 Spot Instance mit Docker.

Ein realer Kostenoptimierungs-Leitfaden

Hier ist der schrittweise Prozess, dem ich bei Kostenoptimierungsprojekten folge. Typischerweise werden damit 30-50 % Einsparungen innerhalb des ersten Monats erzielt.

Woche 1: Audit

1. AWS Cost Explorer aktivieren, falls noch nicht aktiv.
2. Einen 3-Monats-Kostenaufschlüsselung nach Service abrufen.
3. Die Top 5 Services nach Ausgaben identifizieren.
4. AWS Compute Optimizer und Trusted Advisor ausführen.
5. Alle unattached EBS-Volumes, ungenutzten Elastic IPs und untätigen Load Balancer auflisten.

Woche 2: Quick Wins

1. Im Audit identifizierte ungenutzte Ressourcen löschen.
2. Die am stärksten überdimensionierten Instanzen richtig dimensionieren (1 Größe runter, überwachen).
3. VPC Endpoints für S3- und DynamoDB-Traffic einrichten.
4. S3 Lifecycle Policies auf allen Buckets aktivieren.
5. Budget-Alerts einrichten.

Woche 3: Commitments

1. Gleichmäßige Workloads auf Savings-Plan-Eignung analysieren.
2. Compute Savings Plans für Baseline-Compute-Ausgaben kaufen.
3. RDS Reserved Instances für Produktionsdatenbanken kaufen.
4. Geeignete Workloads auf Spot Instances umstellen.

Woche 4: Architektur

1. Caching-Schichten dort hinzufügen, wo sinnvoll.
2. Serverless-Migration für geeignete Workloads evaluieren.
3. Nicht-Produktionsumgebungen konsolidieren.
4. Infracost in der CI-Pipeline einrichten.
5. Die Kosten-Baseline für laufendes Monitoring dokumentieren.

Was Sie nicht optimieren sollten

Kostenoptimierung hat abnehmenden Grenznutzen, und manche „Einsparungen" schaffen mehr Probleme als sie lösen.

Opfern Sie nicht Zuverlässigkeit für Kosten. Eine Produktionsdatenbank in einer Single-AZ-Bereitstellung zu betreiben, um Multi-AZ-Kosten zu sparen, ist eine falsche Sparsamkeit. Der erste Ausfall wird mehr kosten als Jahre an Multi-AZ-Aufpreisen.

Optimieren Sie nicht übermäßig für die aktuelle Skalierung. Wenn Ihr Startup monatlich 20 % wächst, ist eine Woche für die Optimierung eines 50-$/Monat-Services keine gute Zeitverwendung. Konzentrieren Sie sich auf die großen Posten.

Kämpfen Sie nicht gegen das Preismodell des Cloud-Anbieters. AWS ist darauf ausgelegt, teuer zu sein, wenn Sie gegen seine Konventionen arbeiten. Nutzen Sie Managed Services wie vorgesehen, nutzen Sie Free Tiers und die angebotenen Commitment-Rabatte. Zu versuchen, sich durch übermäßig clevere Architekturen um die Preisgestaltung herumzubauen, geht meist nach hinten los.

Entfernen Sie kein Monitoring, um Geld zu sparen. CloudWatch kostet Geld, aber blind zu fliegen kostet mehr. Die 15 $/Monat, die Sie für detailliertes Monitoring ausgeben, bewahren Sie vor der 500-$-Überraschung, die detailliertes Monitoring erkannt hätte.

Der Zinseszinseffekt

Das stärkste Argument für frühe Kostenoptimierung sind nicht die sofortigen Einsparungen — es sind die Gewohnheiten und die Infrastruktur, die Sie aufbauen. Ein Startup, das Budget-Alerts einrichtet, Infracost in CI nutzt und monatlich Kosten überprüft, wird effiziente Infrastruktur beibehalten, während es skaliert. Ein Startup, das Kosten bis zur Series B ignoriert, wird sich mit 30.000 $/Monat AWS-Rechnungen konfrontiert sehen, die sechs Monate dedizierter Arbeit brauchen, um sie zu entwirren.

Beginnen Sie mit dem Audit. Die Zahlen werden Ihnen sagen, worauf Sie sich konzentrieren sollten.