Ungenutzte RDS Instanzen, Azure-SQL-Datenbanken ohne Logins und Cloud-SQL-Instanzen ohne Verbindungen rechnen Instanzstunden ab, während niemand eine Abfrage stellt: die Datenbank der Testumgebung nach dem Release, die Replik eines abgeschalteten Dienstes, das Schema eines Prototyps. Die Einsparung entsteht, weil eine gestoppte, pausierte oder auf Serverless umgestellte Datenbank nur noch Speicher berechnet, und weil die Provider das Stoppen mit eigenen Fristen und Automatismen unterstützen. Die Behebung gehört dem Team, dem die Anwendung gehört, die die Datenbank einmal gebraucht hat.

Symptom

Die Rechnung zeigt Datenbankstunden ohne Verbindungen. Bei AWS sind das Positionen mit lineItem/UsageType EUC1-InstanceUsage:db.m6g.large oder EUC1-Multi-AZUsage:db.m6g.large unter AmazonRDS, mit 720 oder 744 Stunden je lineItem/ResourceId, während die Metrik DatabaseConnections bei null steht. Bei Azure sind es MeterCategory SQL Database mit vCore-Metern je Datenbank, oder Azure Database for PostgreSQL mit Compute-Metern je Server, bei flachen connection_successful- und cpu_percent-Metriken. In Google Cloud trägt Cloud SQL die SKUs für vCPU- und RAM-Stunden je resource.name, mit database/network/connections bei null. Was eine Datenbank grundsätzlich berechnet, steht in verwalteten Datenbanken; die Hebel bei laufenden Datenbanken in Datenbankoptimierung.

Eine Datenbank, dieniemand abfragtInstanzstunden, 720 oder 744je Ressource und Monat:InstanceUsage, vCore- odervCPU- und RAM-MeterVerbindungsmetrik bei null:DatabaseConnections,connection_successful,database/network/connectionsDie Rechnung: Datenbank-stunden ohne Verbindungen
Die Position Instanzstunden zählt jede Stunde des Monats je Datenbank, während die Verbindungsmetrik daneben bei null bleibt

So erkennen Sie es

AWS

Die Instanzen mit Klasse, Engine und Status:

aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,DBInstanceClass,Engine,DBInstanceStatus,MultiAZ,ReadReplicaSourceDBInstanceIdentifier]' --output table

Die Verbindungen einer Instanz über zwei Wochen, als Tagesmaximum:

aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=<instance> --statistics Maximum \
  --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z --period 86400

Zwei Prüfungen von AWS (gelesen am 2026-10-21): Trusted Advisor meldet unter "Amazon RDS idle DB instances" eine aktive Instanz ohne Verbindung in den letzten sieben Tagen; Compute Optimizer stuft eine RDS-Instanz als ungenutzt ein, wenn sie keine Replik ist und über den Betrachtungszeitraum keine Verbindungen, geringe CPU und geringe Lese- und Schreibaktivität hatte, und empfiehlt Stoppen für bis zu sieben Tage, Snapshot und Löschen, oder bei Aurora den Wechsel auf db.serverless:

aws compute-optimizer get-idle-recommendations --filters name=ResourceType,values=RDSDBInstance

In den Abrechnungsdaten ist der Kandidat eine InstanceUsage-Position mit vollen Stunden, neben der keine RDS:StorageIOUsage-Position nennenswert wächst (AWS Cost and Usage Report).

Azure

Die Datenbanken und Server mit ihrer Compute-Konfiguration:

az sql db list --server <server> --resource-group <rg> \
  --query "[?name!='master'].{name:name, tier:currentSku.tier, sku:currentSku.name, capacity:currentSku.capacity, status:status, autoPause:autoPauseDelay}" -o table
az postgres flexible-server list --query "[].{name:name, rg:resourceGroup, sku:sku.name, tier:sku.tier, state:state}" -o table

Die Metrik connection_successful einer Datenbank über zwei Wochen:

az monitor metrics list --resource <database-resource-id> --metric connection_successful \
  --aggregation Total --interval P1D --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z

Azure Advisor hat keine Empfehlung zu ungenutzten SQL- oder PostgreSQL-Instanzen; für Cosmos DB meldet er Container ohne Aktivität über 30 Tage und für Data Explorer laufende Cluster ohne Nutzeraktivität. Im Kostenexport ist der Kandidat eine ResourceId unter SQL Database oder Azure Database for PostgreSQL mit voller Compute-Quantity (Azure-Kostenexporte).

Google Cloud

Die Instanzen mit Typ, Version und Verfügbarkeit:

gcloud sql instances list --format="table(name,databaseVersion,settings.tier,settings.availabilityType,state,region)"

Der Recommender für ungenutzte Cloud-SQL-Instanzen bewertet primäre Instanzen, die älter als 30 Tage sind, über die letzten 30 Tage und meldet eine Instanz, deren Aktivität unter seiner Schwelle liegt, mit dem Maximum der CPU-Auslastung als Beleg:

gcloud recommender recommendations list --project=<project-id> --location=<region> \
  --recommender=google.cloudsql.instance.IdleRecommender --format="table(name.basename(),description,stateInfo.state)"

Im Abrechnungsexport ist der Kandidat ein resource.name unter Cloud SQL mit vollen vCPU- und RAM-Stunden (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Den Verantwortlichen fragen und eine Frist setzen; eine Datenbank, die nur zu bestimmten Zeiten gebraucht wird, bekommt einen Zeitplan statt einer Löschung (Zeitpläne und Auto-Scaling).
  2. Stoppen, wo der Provider es erlaubt. AWS: aws rds stop-db-instance --db-instance-identifier <instance> stoppt eine Instanz für höchstens sieben Tage am Stück, danach startet RDS sie selbst, damit Wartung nicht ausfällt; gestoppt werden Speicher, Provisioned IOPS, Backup-Speicher und eine öffentliche IPv4-Adresse weiter berechnet, nicht aber Instanzstunden; eine Instanz mit Lesereplik und eine SQL-Server-Instanz in Multi-AZ lassen sich nicht stoppen (RDS-Instanz stoppen). Azure: az postgres flexible-server stop --resource-group <rg> --name <server> stoppt die Compute-Ebene, und Microsoft startet den Server nach sieben Tagen ohne manuellen Start automatisch (Server stoppen). Google Cloud: gcloud sql instances patch <instance> --activation-policy=NEVER stoppt die Instanz ohne Frist; Speicher wird weiter berechnet.
  3. Pausieren lassen, wo die Datenbank unregelmäßig gebraucht wird. Azure SQL Database im Serverless-Tarif pausiert nach der eingestellten Verzögerung, mindestens 15 Minuten im General-Purpose-Tarif, standardmäßig 60, und berechnet pausiert nur Speicher (Serverless-Tarif): az sql db update --server <server> --resource-group <rg> --name <db> --compute-model Serverless --auto-pause-delay 60. Aurora Serverless v2 pausiert mit einer Mindestkapazität von 0 ACUs nach einer Leerlaufzeit von 300 bis 86.400 Sekunden, standardmäßig 300, und berechnet pausiert keine Instanzkapazität (Automatisches Pausieren): aws rds modify-db-cluster --db-cluster-identifier <cluster> --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=8,SecondsUntilAutoPause=600.
  4. Löschen nach Frist, mit Snapshot: aws rds delete-db-instance --db-instance-identifier <instance> --final-db-snapshot-identifier <snapshot>, az sql db delete nach einem Export oder einer Kopie, gcloud sql instances delete <instance> nach gcloud sql backups create. Keiner dieser Aufrufe hat ein Dry-Run; die Liste aus der Erkennung und die Freigabe ersetzen es.

Der Stop wirkt sofort auf die Instanzstunden; der Tagesexport zeigt es am Folgetag.

janeinjaneinDen Verantwortlichen fragenund eine Frist setzenNur zu bestimmtenZeiten gebraucht?Ein Zeitplan statteiner LöschungStoppen, wo der Provider eserlaubt: Instanzstundenenden; AWS und Azure startennach sieben Tagen wiederUnregelmäßiggebraucht?Pausieren lassen imServerless-Tarif: pausiertnur SpeicherLöschen nach Frist, mitSnapshot; die Liste unddie Freigabe ersetzendas Dry-Run
Verantwortlicher und Frist kommen zuerst, der Stop ist der umkehrbare Schritt mit seiner Haltefrist, und das Löschen mit Snapshot folgt der Frist

Risiken und Nebenwirkungen

  • Keine Verbindungen heißt nicht keine Daten: die Datenbank hält vielleicht Daten mit Aufbewahrungspflicht. Der Snapshot vor dem Löschen und dessen eigene Frist gehören in alte Snapshots und Maschinen-Images.
  • Der Start einer gestoppten Instanz dauert Minuten bis Stunden, mit Wiederherstellung; eine Datenbank, die täglich gebraucht wird, braucht einen Zeitplan, der sie vor dem Arbeitsbeginn startet.
  • Pausieren hat Kaltstarts: der erste Login nach der Pause wartet, und Funktionen wie Replikation, Geo-Replikation oder lang laufende Jobs verhindern die Pause; bei Aurora verhindert logische Replikation das Pausieren.
  • Eine Reserved Instance oder eine Reservierung für die Datenbankklasse läuft weiter, ob die Instanz läuft oder nicht; die Einsparung ist dann die Differenz, die eine andere Instanz unter die Reservierung bringt (reservierte Kapazität für verwaltete Dienste).
  • Das Stoppen entfernt bei RDS ausstehende Wartung, und ein gestoppter Azure-Server wird für Wartung kurz gestartet; beides ist kein Fehler, aber ein Grund, nach dem Start Versionen und Parameter zu prüfen.

So weisen Sie die Einsparung nach

Vorher: je Instanz die InstanceUsage-, vCore- oder vCPU-Stunden und ihr Betrag im letzten vollen Monat, daneben die Verbindungsmetrik. Nachher: dieselbe Instanz im ersten vollen Monat nach dem Stop, der Pause oder dem Löschen; die Stunden müssen auf null fallen oder, bei Serverless, auf die Stunden mit Last, und die Speicher- und Backup-Positionen bleiben als zweite Liste. Der Betrag des Recommenders ist die Schätzung, die Zustimmung des Teams macht ihn akzeptiert, der Stop umgesetzt, und die Rechnung des Folgemonats belegt ihn nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Zahl der Datenbanken ohne Verbindungen in den letzten 14 Tagen ist die Kennzahl, die danach im Kostenreview steht.

Quellen

Gelesen am 2026-10-21. RDS-Instanz vorübergehend stoppen, Aurora Serverless v2, automatisches Pausieren, Trusted Advisor, Kostenoptimierungsprüfungen, Compute Optimizer, Leerlaufressourcen, Azure SQL Database, Serverless-Tarif, Azure Database for PostgreSQL, Server stoppen, Azure Advisor, Kostenempfehlungen, Cloud SQL, Recommender für ungenutzte Instanzen, Recommender-Übersicht.