AWS Kosten senken – Savings Plans, RIs und Rightsizing

Cloud bringt dir Flexibilität und Tempo. Gleichzeitig können Kosten schleichend steigen: Instanzen laufen durch, Ressourcen sind zu groß dimensioniert oder Monitoring fehlt. Die Folge sind unnötige Ausgaben, obwohl die gleiche Leistung mit wenigen Maßnahmen günstiger möglich ist.

Die gute Nachricht: Mit Savings Plans, Reserved Instances (RIs) und Rightsizing senkst du die Rechnung nachhaltig, ohne an Qualität zu verlieren. Ergänzt mit Tagging, Budgets und Monitoring bekommst du Transparenz und triffst fundierte Entscheidungen statt Bauchgefühl.

Das Grundprinzip hinter AWS-Kosten

Kosten entstehen vor allem durch Compute, Speicher und Datenverkehr. Optimierung bedeutet daher: Grundbedarf günstig binden, Spitzen automatisch abfangen und Ressourcen passend zuschneiden. Mit einem leichten FinOps-Prozess prüfst du das regelmäßig und entwickelst dich schrittweise weiter.

Savings Plans – flexibel sparen

Savings Plans sind Commitments zu einem stündlichen Betrag (z. B. 5 USD pro Stunde) über 1 oder 3 Jahre. Im Gegenzug bekommst du Rabatte auf passende Nutzung.

Compute Savings Plans

Compute Savings Plans gelten accounts- und regionsübergreifend für EC2, Fargate und Lambda. Sie sind die flexibelste Variante, weil sie nicht an eine konkrete Instanzfamilie gebunden sind. Ideal, wenn sich Region, Instanzfamilie oder Architektur verändern können.

EC2 Instance Savings Plans

Diese Variante ist günstiger, aber spezifischer: Sie bindet dich an Instanzfamilie und Region (z. B. m6i in eu-central-1). Du bekommst mehr Rabatt, wenn dein Workload stabil ist.

Gute Praxis

Starte mit einem konservativen Betrag auf 1 Jahr, beobachte die Nutzung, erhöhe dann schrittweise. Wähle No Upfront für Flexibilität oder Partial/All Upfront für maximale Ersparnis. Wichtig ist ein realistischer Grundbedarf – den Rest deckst du On-Demand oder per Spot.

Reserved Instances – gezielt und planbar

Reserved Instances (RIs) sind Reservierungen für EC2 oder RDS. Sie sind ressourcenspezifischer als Savings Plans, können je nach Typ konvertierbar sein und bringen vergleichbare Rabatte.

Standard vs Convertible

Standard RIs liefern den höchsten Rabatt, sind aber weniger flexibel. Convertible RIs erlauben Tausch gegen andere Konfigurationen derselben Familie und bieten mehr Spielraum bei etwas geringerem Rabatt.

Wann RIs sinnvoll sind

Wenn du stetige Last auf klaren Instanzfamilien hast, passen RIs sehr gut. Für Datenbanken mit stabiler Größe sind RDS RIs oft ein No-Brainer.

Rightsizing – passend statt groß

Rightsizing heißt: Instanzen, Datenbanken und Volumes auf bedarfsgerechte Größen bringen. Viele Setups laufen im Schnitt mit Unterauslastung.

So gehst du vor

Nutze AWS Compute Optimizer und Cost Explorer als Startpunkt. Prüfe CPU, RAM, I/O und Netzwerk über einen repräsentativen Zeitraum. Senke die Größe, wenn P95-Auslastung klar unter dem Zielkorridor liegt. Wechsle auf neuere Instanzfamilien (z. B. von m5 auf m7g), wenn sie bessere Preis-Leistung bieten. Für Speicher: EBS-Typ und Provisioned IOPS kritisch prüfen, Snapshots und verwaiste Volumes aufräumen.

Autoscaling und Spot – Spitzen günstig abfangen

Autoscaling kombiniert Leistung und Kostenkontrolle. Definiere Zielmetriken (z. B. 60 Prozent CPU) und nutze Cooldowns, damit die Flotte ruhig skaliert. Ergänze Spot-Instanzen für stateless oder fehlertolerante Workloads. Spot ist deutlich günstiger, kann aber unterbrochen werden – plane Retries und Mehr-AZ ein.

Monitoring, Tagging, Budgets – Transparenz schaffen

Ohne Sichtbarkeit keine Optimierung. Führe einheitliches Tagging ein, mindestens Projekt, Umgebung und Kostenstelle. Richte AWS Budgets mit Warnschwellen ein und beobachte in Cost Explorer die Top-Treiber. CloudWatch zeigt dir Auslastung und Anomalien. So erkennst du Drift früh und kannst gegensteuern.

Speicher und Datenbanken – schnelle Gewinne

S3: Lege Lifecycle-Regeln fest. Heiß -> Standard, selten -> Standard-IA, Archiv -> Glacier. Prüfe Intelligent-Tiering, wenn Zugriffsmuster unklar sind.
EBS: Wähle den passenden Volume-Typ (gp3 statt gp2), setze IOPS nur so hoch wie nötig.
RDS/Aurora: Größen und Speicherklassen überprüfen, Read Replicas nur behalten, wenn sie genutzt werden. Aurora Serverless v2 kann Last feingranular anpassen.
Lambda: Prüfe Speicherzuweisung und Timeouts. Mehr Speicher kann die Laufzeit senken und insgesamt billiger sein.

Ein leichter FinOps-Workflow

Definiere monatlich Review-Termine: Savings Plans/RIs Auslastung, Top-10 Kostentreiber, Rightsizing-Empfehlungen, Anomalien. Jede Maßnahme bekommt Owner und Termin. So bleibt Optimierung laufend statt einmalig.

Entscheidungshilfe – wie du startest

Wenn du schnell sparen willst, beginne mit Rightsizing und EBS/S3-Hygiene. Sichere dann den Grundbedarf mit Savings Plans. Für sehr stabile Datenbanken prüfe RDS RIs. Baue parallel Tagging, Budgets und Dashboards auf. Danach kommt Autoscaling plus Spot, wo es technisch passt.

Häufige Missverständnisse

„Reservierungen machen unflexibel.“ – Binde nur den Grundbedarf. Spitzen bleiben On-Demand.
„Serverless ist immer billiger.“ – Nur wenn der Durchsatz wirklich ereignisgetrieben ist.
„Kostenoptimierung heißt Leistung runterdrehen.“ – Ziel ist gleiche oder bessere Performance bei weniger Verschwendung.

Fazit

Savings Plans und Reserved Instances senken deinen Grundpreis, Rightsizing entfernt Verschwendung und Autoscaling puffert Spitzen ab. Mit Tagging, Budgets und Monitoring bekommst du Transparenz und bleibst steuerbar. Starte klein, miss Ergebnisse und erweitere systematisch – so wird AWS Kostenoptimierung zu einem Plan statt zu einer Feuerwehrübung.