Datenbankkosten senkt man über eine Handvoll Hebel, von denen jeder eine Preisdimension der verwalteten Datenbank trifft: die Instanzklasse, den Speichertyp und die bereitgestellte Leistung, die Abrechnung der I/O, die Laufzeit, die Aufbewahrung der Backups, die Zahl der Kopien und das Alter der Engine-Version. Einige dieser Entscheidungen lassen sich nur mit Migration oder Ausfallzeit zurücknehmen. Die Preisdimensionen erklärt Verwaltete Datenbanken, die Commitments Reservierte Kapazität.
So funktioniert es
| Hebel | Was er senkt | Was ihn begrenzt |
|---|---|---|
| Kleinere Instanzklasse, neuere Generation | Instanzstunden, bei Multi-AZ und Replikaten mehrfach | Speicher- und I/O-Bedarf, Neustart, an den Klassentyp gebundene Reservierungen |
| Speichertyp und bereitgestellte IOPS | Speicher und IOPS | Speicher wächst leicht und schrumpft schwer |
| I/O-Konfiguration bei Aurora | I/O-Gebühren oder höhere Instanz- und Speicherpreise | Wechsel nur in einer Richtung jederzeit |
| Serverless mit Pause, Stoppen | Compute in Leerlaufzeiten | Anlaufzeit, Höchstdauer eines Stopps |
| Backup-Aufbewahrung und Snapshots | Backup-Speicher | Anforderungen an die Wiederherstellung |
| Replikate und Testkopien | zusätzliche Instanzen und Speicher | Lese- und Verfügbarkeitsbedarf |
| Engine-Upgrade | Aufschläge für Extended Support | Testaufwand für die neue Hauptversion |
Das Rightsizing folgt der Logik bei Instanzen; die Werkzeuge der Provider wenden eigene Regeln an.
AWS
AWS Compute Optimizer empfiehlt Instanzklassen und Speicher für RDS for MySQL, RDS for PostgreSQL und Aurora: für RDS Volumetyp und IOPS, für Aurora die Speicherkonfiguration mit geschätzten Instanz-, Speicher- und I/O-Kosten; auf Wunsch zeigt es auch Graviton-Instanzen. Auf gp3 liefert RDS 3.000 IOPS und 125 MiB/s als Grundleistung, für Db2, MariaDB, MySQL und PostgreSQL ab 400 GiB (Oracle ab 200 GiB) 12.000 IOPS und 500 MiB/s; zusätzliche IOPS und Durchsatz lassen sich außer bei SQL Server erst ab dieser Schwelle bereitstellen. Zugewiesener Speicher lässt sich dagegen nicht verkleinern, auch die automatische Speichererweiterung wächst nur; AWS nennt als Ausweg ein Blue/Green Deployment mit kleinerem Speicher oder eine neue Instanz mit Migration.
Aurora I/O-Optimized berechnet keine I/O-Anfragen, dafür höhere Instanz- und Speicherpreise; AWS empfiehlt es ab einem I/O-Anteil von 25 % der Aurora-Ausgaben. Zurück zu Aurora Standard geht es jederzeit, zu I/O-Optimized nur einmal alle 30 Tage. In neueren Aurora-Versionen sinkt der belegte Speicher, wenn Tabellen oder Datenbanken gelöscht werden. Aurora Serverless kann mit einer Mindestkapazität von 0 ACU pausieren; während der Pause fällt keine Instanzgebühr an, Speicher wird weiter berechnet. Die Inaktivitätsdauer bis zur Pause liegt zwischen 300 Sekunden und einem Tag, der Wiederanlauf dauert typischerweise etwa 15 Sekunden, nach mehr als 24 Stunden Pause kann er 30 Sekunden oder länger dauern. Eine gestoppte RDS-Instanz kostet keine Instanzstunden, wohl aber Speicher und Backups, und startet nach sieben Tagen von selbst. Die Backup-Aufbewahrung liegt zwischen 0 und 35 Tagen. Für Testumgebungen erzeugt Aurora Klone nach dem Copy-on-Write-Verfahren, die zusätzlichen Speicher erst bei Änderungen belegen; nach 15 solchen Klonen wird der nächste eine vollständige Kopie.
RDS Extended Support wird ab dem Tag nach dem Ende des Standard-Supports einer Hauptversion berechnet, je vCPU und Stunde, auch für Standbys in Multi-AZ-Bereitstellungen und für Lesereplikate; Rabatte von Reserved Instances gelten dafür nicht. Die Gebühr endet mit dem Upgrade oder dem Löschen der Datenbank. Über den Parameter EngineLifecycleSupport lässt sich die Teilnahme beim Anlegen oder später abschalten; bei einer Instanz jenseits des Stichtags löst das Abschalten das automatische Upgrade aus.
Azure
Azure SQL Database im Serverless-Tarif rechnet Compute sekundengenau ab, mindestens die konfigurierten Mindest-vCores, und während einer Pause nur den Speicher. Die Pause beginnt bei General Purpose frühestens nach 15 Minuten Inaktivität (Standard 60 Minuten), bei Hyperscale, wo die automatische Pause eine Vorschaufunktion ist, nach mindestens 60 Minuten. Microsoft empfiehlt Serverless für einzelne Datenbanken mit unregelmäßiger Nutzung und für mehrere solcher Datenbanken Elastic Pools. Azure Database for PostgreSQL bietet den Burstable-Tarif für Entwicklung und Workloads mit wenigen gleichzeitigen Zugriffen; beim Stoppen endet die Compute-Abrechnung sofort, nach sieben Tagen startet der Server wieder. Die Point-in-Time-Aufbewahrung von Azure SQL Database liegt zwischen 1 und 35 Tagen (Standard 7), Langzeitaufbewahrung reicht bis zehn Jahre. Azure Advisor schlägt bei Datenbanken unter anderem Reservierungen und das Verkleinern inaktiver Cosmos-DB-Container vor.
Google Cloud
Die Cloud-SQL-Empfehlung für überdimensionierte Instanzen wertet CPU und Speicher der letzten 30 Tage bei Primärinstanzen aus, die älter als 30 Tage sind, nicht bei Lesereplikaten und hochverfügbaren Instanzen, und meldet sich erst ab einer geschätzten Monatsersparnis von 10 USD. Eine zweite Empfehlung erkennt inaktive Instanzen. Die Aktivierungsrichtlinie NEVER stoppt eine Instanz und ihre Instanzgebühren, Speicher und IP-Adressen werden weiter berechnet; Lesereplikate unterstützen sie nicht. Automatische Speichererweiterungen sind dauerhaft; verkleinern lässt sich der Speicher nur mit einer eigenen Operation, die Ausfallzeit verursacht und auf Shared-Core-Instanzen nicht verfügbar ist. Wird beim Löschen einer Instanz ein letztes Backup (Final Backup) erstellt, bewahrt Cloud SQL es standardmäßig 30 Tage auf und berechnet es wie andere Backups.
Was es für Ihre Kosten bedeutet
Die Reihenfolge folgt dem Risiko. Zuerst entfällt, was niemand nutzt: inaktive Instanzen, ungenutzte Replikate, alte manuelle Snapshots. Danach kommen Instanzklasse und Speicher, dann das Abrechnungsmodell (Serverless, Pause, I/O-Konfiguration), zuletzt das Commitment auf die verbleibende Basis. Ein Commitment vor dem Rightsizing ist auf die alte Kapazität bemessen. Extended Support verschafft Zeit für das Upgrade, gegen einen Aufschlag zusätzlich zu allen anderen Positionen; das Datum des Standard-Support-Endes gehört in die Planung der Upgrades wie ein Vertragsende. Nicht-produktive Datenbanken sind die erste Wahl für Pausen, Stopps und Klone (Nicht-Produktionskosten steuern). Jeder Hebel zeigt sich in einer eigenen Position der Abrechnungsdaten; belegt ist eine Einsparung erst, wenn genau diese Position sinkt (von der geschätzten zur belegten Einsparung).
Wo es schiefgeht
- Speicher wächst und bleibt. Symptom: Die Speicherposition steigt nach einer Lastspitze und sinkt nie wieder. Ursache: Automatische Erweiterungen sind dauerhaft, und RDS-Speicher lässt sich nicht verkleinern.
- Gestoppte Datenbank läuft wieder. Symptom: Instanzstunden einer gestoppten Testdatenbank tauchen nach einer Woche wieder auf. Ursache: RDS und Azure Database for PostgreSQL starten nach sieben Tagen automatisch.
- Pause ohne Wirkung. Symptom: Eine Aurora-Serverless-Instanz pausiert nie oder wacht immer wieder auf. Ursache: eine Mindestkapazität über 0 ACU, eine offene Client-Verbindung oder logische bzw. Binlog-Replikation; zudem weckt sie jeder Verbindungsversuch, auch mit ungültigen Anmeldedaten.
- Extended Support doppelt. Symptom: Die Extended-Support-Position ist doppelt so hoch wie erwartet. Ursache: Bei Multi-AZ werden Primär- und Standby-Instanz berechnet, Lesereplikate ebenfalls.
- Zurück zu Standard, dann blockiert. Symptom: Ein Aurora-Cluster lässt sich nach einem Test nicht wieder auf I/O-Optimized stellen. Ursache: Der Wechsel zu I/O-Optimized ist nur einmal alle 30 Tage möglich.
- Gelöschte Instanz kostet weiter. Symptom: Nach dem Löschen einer Cloud-SQL-Instanz bleibt eine Backup-Position. Ursache: Beim Löschen wurde ein letztes Backup erstellt, und es wird standardmäßig 30 Tage aufbewahrt und berechnet.
Beispiel
Am 2026-10-16 nannte die Preisseite von Amazon RDS for PostgreSQL für Version 12, deren Standard-Support am 28. Februar 2025 endete, in US East (Ohio) USD 0,100 je vCPU-Stunde für die ersten beiden Jahre Extended Support und USD 0,200 ab dem 1. März 2027. Eine db.r5.large hat laut derselben Seite 2 vCPUs. Als Multi-AZ-Bereitstellung mit einem Standby ergibt das 2 Instanzen × 2 vCPUs × USD 0,100 = USD 0,40 je Stunde, über 720 Stunden USD 288, ab März 2027 das Doppelte. Diese Beträge kommen zu Instanz, Speicher und Backups hinzu.
Quellen
Gelesen am 2026-10-16. AWS Aurora- und RDS-Empfehlungen in Compute Optimizer, Speichertypen für RDS, automatische Speichererweiterung bei RDS, Speicherkonfigurationen von Aurora, automatische Pause von Aurora Serverless, RDS-Instanz vorübergehend stoppen, Backup-Aufbewahrung, Aurora-Klone, RDS Extended Support, Gebühren für Extended Support, Amazon RDS Preise, Amazon RDS for PostgreSQL Preise und Amazon Aurora Preise; Microsoft Serverless-Tarif für Azure SQL Database, automatische Backups in Azure SQL Database, Überblick Azure Database for PostgreSQL, Server stoppen und Kostenempfehlungen von Azure Advisor; Google Cloud Empfehlung für überdimensionierte Cloud-SQL-Instanzen, Empfehlung für inaktive Instanzen, Instanzen starten und stoppen, Instanzeinstellungen, Speicher verkleinern und Backups.