Linden Consulting.
FinOps

AWS-Kosten senken: die 7 häufigsten Einsparmöglichkeiten

2026-03-23 · 9 Min. Lesezeit

Wenn ich bei einem neuen Kunden das erste Mal in die AWS-Rechnung schaue, finde ich in nahezu jedem Account dieselben sieben Kostentreiber. Das Muster ist so vorhersehbar, dass ich inzwischen eine Checkliste habe, die ich innerhalb eines halben Tages durchgehe. Die Ergebnisse sprechen für sich: Im Schnitt lassen sich 25-40 % der monatlichen AWS-Ausgaben einsparen — ohne Leistungseinbußen, ohne große Umbauten.

In diesem Beitrag zeige ich Ihnen die sieben häufigsten Einsparmöglichkeiten, die ich in über 15 Jahren AWS-Consulting immer wieder sehe. Zu jedem Punkt gibt es konkrete CLI-Befehle und Tipps für den AWS Cost Explorer, damit Sie sofort loslegen können.

1. NAT Gateway-Kosten — der versteckte Kostentreiber Nummer eins

Wenn ich nach dem größten Überraschungsposten auf der AWS-Rechnung gefragt werde, lautet die Antwort fast immer: NAT Gateways. Viele Teams sind ehrlich schockiert, wenn sie sehen, wie viel Geld allein durch Datenverkehr über NAT Gateways fließt.

Warum ist das so teuer? Ein NAT Gateway kostet 0,045 USD pro Stunde — das sind rund 33 USD im Monat, was erst einmal überschaubar klingt. Aber: Zusätzlich fallen 0,045 USD pro verarbeitetem Gigabyte an. Bei einer typischen Microservice-Architektur, in der dutzende Services über das NAT Gateway mit externen APIs, S3 oder anderen AWS-Diensten kommunizieren, summiert sich das schnell auf mehrere tausend Euro im Monat.

So finden Sie das Problem:

# NAT Gateway Data-Transfer im Cost Explorer identifizieren
aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-03-31 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"USAGE_TYPE","Values":["EUW1-NatGateway-Bytes"]}}'

Die Lösung: Prüfen Sie zunächst, ob Traffic zu AWS-Diensten wie S3, DynamoDB oder SQS über das NAT Gateway läuft. Für diese Dienste gibt es VPC Endpoints, die den Verkehr im AWS-Netzwerk halten und die NAT-Gateway-Kosten drastisch senken.

# VPC Gateway Endpoint für S3 erstellen
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123def456 \
  --service-name com.amazonaws.eu-central-1.s3 \
  --route-table-ids rtb-0abc123def456

Bei einem meiner Kunden hat allein diese Maßnahme die monatlichen Netzwerkkosten um 4.200 EUR gesenkt — in weniger als einer Stunde Arbeit.

2. Überdimensionierte EC2-Instanzen

Das zweithäufigste Problem sind EC2-Instanzen, die deutlich mehr Ressourcen haben, als sie benötigen. Der Grund ist menschlich nachvollziehbar: Teams wählen bei der initialen Bereitstellung lieber eine Nummer größer, um auf der sicheren Seite zu sein — und passen die Größe danach nie an.

So identifizieren Sie überdimensionierte Instanzen:

# AWS Compute Optimizer Empfehlungen abrufen
aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=Finding,values=OVER_PROVISIONED \
  --output table

Alternativ können Sie direkt die CloudWatch-Metriken prüfen:

# Durchschnittliche CPU-Auslastung der letzten 14 Tage
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --start-time 2026-03-01T00:00:00Z \
  --end-time 2026-03-15T00:00:00Z \
  --period 86400 \
  --statistics Average

Faustregel: Liegt die durchschnittliche CPU-Auslastung dauerhaft unter 20 % und die Memory-Auslastung unter 30 %, ist die Instanz mit hoher Wahrscheinlichkeit überdimensioniert. Ein Wechsel von einer m5.xlarge auf eine m5.large halbiert die Compute-Kosten — bei vielen Workloads ohne messbare Auswirkung auf die Performance.

Tipp für den Cost Explorer: Nutzen Sie den Rightsizing-Report unter Cost Management > Rightsizing Recommendations. AWS zeigt dort konkrete Instanzempfehlungen inklusive der erwarteten monatlichen Ersparnis.

3. Fehlende Savings Plans und Reserved Instances

On-Demand-Preise sind die teuerste Art, AWS zu nutzen. Trotzdem sehe ich regelmäßig Accounts, in denen 80-90 % aller Workloads on-demand laufen — obwohl die Grundlast seit Monaten stabil ist.

Savings Plans vs. Reserved Instances: Savings Plans sind in den meisten Fällen die bessere Wahl, weil sie flexibler sind. Ein Compute Savings Plan gilt über EC2, Fargate und Lambda hinweg. Reserved Instances sind dagegen an eine bestimmte Instanzfamilie und Region gebunden.

So analysieren Sie Ihr Sparpotenzial:

# Savings Plan Empfehlungen von AWS abrufen
aws savingsplans describe-savings-plans-offering-rates \
  --savingsPlanType COMPUTE_SP \
  --products EC2

Im Cost Explorer gibt es unter Savings Plans > Recommendations eine detaillierte Analyse, die auf Basis Ihres bisherigen Nutzungsverhaltens den optimalen Commitment-Level berechnet. Starten Sie konservativ: Decken Sie zunächst 60-70 % Ihrer stabilen Grundlast mit einem 1-Jahres-Plan ab (keine Vorauszahlung). Das allein bringt typischerweise 20-30 % Ersparnis.

Wichtig: Kaufen Sie Savings Plans nicht blind. Analysieren Sie mindestens 30 Tage Nutzungsdaten und berücksichtigen Sie geplante Architekturänderungen. Wenn Sie beispielsweise in sechs Monaten auf Serverless migrieren wollen, ist ein 3-Jahres-Commitment auf EC2 keine gute Idee.

4. Ungenutzte Ressourcen: EBS Volumes, Elastic IPs und mehr

Die sogenannten „Zombie-Ressourcen" sind einer der ärgerlichsten Kostenpunkte, weil sie keinen Mehrwert liefern. Typische Kandidaten sind:

  • Nicht angehängte EBS Volumes: Werden nach dem Terminieren einer EC2-Instanz oft vergessen.
  • Ungenutzte Elastic IPs: Kosten 3,65 USD pro Monat, wenn sie keiner laufenden Instanz zugewiesen sind.
  • Verwaiste Snapshots: Alte EBS-Snapshots, die sich über Monate und Jahre ansammeln.
  • Leerlaufende Load Balancer: ALBs oder NLBs, hinter denen keine gesunden Targets mehr stehen.
# Nicht angehängte EBS Volumes finden
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Ungenutzte Elastic IPs finden
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}' \
  --output table

# Verwaiste Snapshots älter als 90 Tage auflisten
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<`2025-12-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
  --output table

Automatisierung ist der Schlüssel. Manuelle Aufräumaktionen helfen kurzfristig, aber das Problem kehrt immer wieder. Setzen Sie AWS Config Rules ein, um ungenutzte Ressourcen automatisch zu erkennen, und nutzen Sie AWS Systems Manager Automation, um sie nach einer Karenzzeit automatisch zu löschen.

5. Falsche Storage-Klassen in S3

S3 bietet mittlerweile sieben verschiedene Speicherklassen, und die Preisunterschiede sind erheblich: S3 Standard kostet 0,023 USD/GB/Monat, S3 Glacier Deep Archive nur 0,00099 USD/GB/Monat — ein Faktor von über 20.

Trotzdem liegt bei vielen Kunden der Großteil der Daten in S3 Standard, obwohl ein signifikanter Anteil selten oder nie abgerufen wird.

So analysieren Sie Ihre S3-Nutzung:

# S3 Storage Lens aktivieren (falls noch nicht geschehen)
aws s3control put-storage-lens-configuration \
  --account-id 123456789012 \
  --config-id default-account-dashboard \
  --storage-lens-configuration '{"Id":"default-account-dashboard","IsEnabled":true,"AccountLevel":{"BucketLevel":{}}}'

# Bucket-Größen und Zugriffsfrequenz prüfen
aws s3api list-buckets --query 'Buckets[*].Name' --output text | \
  xargs -I {} aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name NumberOfObjects \
  --dimensions Name=BucketName,Value={} Name=StorageType,Value=AllStorageTypes \
  --start-time 2026-03-01 --end-time 2026-03-15 \
  --period 86400 --statistics Average

Meine Empfehlung: Aktivieren Sie S3 Intelligent-Tiering für alle Buckets, bei denen Sie die Zugriffsmuster nicht genau kennen. Intelligent-Tiering verschiebt Objekte automatisch zwischen Speicherklassen basierend auf dem tatsächlichen Zugriffsmuster — ohne Abrufgebühren und ohne operativen Aufwand.

Für Daten, die nachweislich nur für Compliance-Zwecke aufbewahrt werden (Audit-Logs, alte Backups), ist ein direkter Umzug nach S3 Glacier oder Glacier Deep Archive sinnvoll. Bei einem Kunden mit 40 TB an Log-Daten hat das allein 800 EUR pro Monat gespart.

6. Datenübertragungskosten

Datenübertragungskosten sind der am häufigsten unterschätzte Posten auf der AWS-Rechnung. Während eingehender Traffic grundsätzlich kostenlos ist, fallen für ausgehenden Verkehr je nach Ziel 0,02 bis 0,09 USD pro Gigabyte an. Noch teurer wird es bei Cross-Region- und Cross-AZ-Traffic.

Die häufigsten Fehler:

  • Cross-AZ-Traffic in Microservice-Architekturen: Wenn Services über mehrere Availability Zones verteilt sind und intensiv miteinander kommunizieren, summieren sich die Cross-AZ-Kosten (0,01 USD/GB in jede Richtung) schnell.
  • CloudFront nicht genutzt: Statische Assets und API-Responses, die direkt von EC2 oder ALB ausgeliefert werden, kosten mehr als über CloudFront.
  • S3-Zugriffe aus der falschen Region: Wenn Ihre Applikation in eu-central-1 läuft, aber auf einen S3-Bucket in us-east-1 zugreift, zahlen Sie Cross-Region-Transfer.

So finden Sie die Kostentreiber:

Im Cost Explorer können Sie nach Usage Type Group: Data Transfer filtern und nach Service gruppieren. Das zeigt Ihnen sofort, welche Dienste den meisten ausgehenden Verkehr verursachen.

# Data Transfer Kosten nach Service aufschlüsseln
aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-03-31 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE \
  --filter '{"Dimensions":{"Key":"USAGE_TYPE_GROUP","Values":["EC2: Data Transfer - Internet (Out)","EC2: Data Transfer - Inter AZ"]}}'

Schnelle Maßnahmen: Setzen Sie CloudFront vor Ihre öffentlichen Endpunkte, nutzen Sie VPC Endpoints für AWS-Service-Kommunikation (siehe Punkt 1), und prüfen Sie, ob Services, die intensiv miteinander kommunizieren, in derselben AZ platziert werden können.

7. Fehlende Auto-Scaling-Konfiguration

Der letzte Punkt klingt banal, ist aber erstaunlich verbreitet: EC2-Instanzen oder ECS-Services, die rund um die Uhr mit konstanter Kapazität für die Spitzenlast laufen, obwohl der Traffic stark variiert.

Ein typisches Beispiel: Eine Webanwendung hat zwischen 9 und 18 Uhr zehnmal mehr Traffic als nachts. Trotzdem laufen 24/7 die gleiche Anzahl Instanzen. Das bedeutet, dass in 14 von 24 Stunden — also 58 % der Zeit — für ungenutzte Kapazität bezahlt wird.

Target Tracking Scaling einrichten:

# Auto Scaling Policy mit Target Tracking (70% CPU)
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-app-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 70.0,
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

Für vorhersehbare Muster empfehle ich zusätzlich Scheduled Scaling, um die Kapazität proaktiv vor den Stoßzeiten hochzufahren:

# Morgens um 8:30 hochskalieren
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-app-asg \
  --scheduled-action-name scale-up-morning \
  --recurrence "30 8 * * MON-FRI" \
  --desired-capacity 6

# Abends um 20:00 herunterskalieren
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-app-asg \
  --scheduled-action-name scale-down-evening \
  --recurrence "0 20 * * MON-FRI" \
  --desired-capacity 2

Vergessen Sie nicht die Datenbank: Aurora Serverless v2 und DynamoDB On-Demand skalieren automatisch. Wenn Sie noch auf provisionierten RDS-Instanzen laufen, prüfen Sie, ob ein Wechsel sinnvoll ist — gerade für Dev- und Staging-Umgebungen.

So starten Sie: ein konkreter Fahrplan

Die sieben Punkte auf einmal anzugehen, kann überwältigend wirken. Mein Rat: Arbeiten Sie die Liste von oben nach unten ab, denn sie ist grob nach dem typischen Einsparpotenzial sortiert.

Woche 1: NAT Gateways und VPC Endpoints analysieren und umsetzen. Ungenutzte Ressourcen identifizieren und aufräumen.

Woche 2: EC2 Rightsizing durchführen. Savings Plan Empfehlungen prüfen und konservativ starten.

Woche 3: S3-Storage-Klassen optimieren und Datenübertragungskosten analysieren.

Woche 4: Auto-Scaling einrichten und die gesamte Optimierung als wiederkehrenden Prozess etablieren.

Richten Sie außerdem AWS Budgets ein, um bei unerwarteten Kostenanstiegen sofort benachrichtigt zu werden:

# Budget mit 80% Alarm erstellen
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Monatliches-AWS-Budget",
    "BudgetLimit": {"Amount": "5000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80
    },
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "team@example.com"}]
  }]'

Fazit

AWS-Kostenoptimierung ist kein einmaliges Projekt, sondern eine fortlaufende Disziplin. Die gute Nachricht: Die sieben Punkte in diesem Artikel decken erfahrungsgemäß 80-90 % des Einsparpotenzials ab. Starten Sie mit den Quick Wins — NAT Gateways, ungenutzte Ressourcen, Rightsizing — und arbeiten Sie sich dann zu den strategischeren Themen wie Savings Plans und Architekturanpassungen vor.

Wenn Sie Unterstützung bei der Analyse und Optimierung Ihrer AWS-Kosten benötigen, kontaktieren Sie mich gerne. In einem kostenlosen Erstgespräch identifizieren wir gemeinsam die größten Einsparpotenziale in Ihrem Account.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen