Multi-AZ in Nicht-Produktivumgebungen ist Hochverfügbarkeit, die niemand braucht, zum Preis einer zweiten Instanz: der Standby einer Entwicklungsdatenbank, die zonenredundante Replik eines Testservers, der georedundante Speicher eines Staging-Buckets, die zweite Region eines Prototyps. Die Einsparung entsteht, weil ein Standby bei allen drei Providern als vollwertige Instanz berechnet wird und eine Umgebung ohne Verfügbarkeitszusage ohne ihn auskommt. Die Behebung gehört dem Team, das die Umgebung aus der Produktionsvorlage kopiert hat, weil die Vorlage die Ursache ist.

Symptom

Die Rechnung zeigt in Konten oder Ressourcengruppen mit env=dev oder env=test Positionen, die nur in der Produktion hingehören. Bei AWS sind das lineItem/UsageType EUC1-Multi-AZUsage:db.r6g.large statt InstanceUsage, Aurora-Cluster mit mehreren Instanzen in verschiedenen Zonen, und S3-Replikation mit DataTransfer-Regional-Bytes oder Cross-Region-Positionen. Bei Azure sind es Compute-Meter für Datenbankserver mit aktivierter Hochverfügbarkeit, Speicherkonten mit GRS, RA-GRS oder GZRS im MeterName und zonenredundante Disks, ZRS, wo LRS reichte. In Google Cloud trägt Cloud SQL die SKUs für regionale Instanzen mit doppeltem Preis, und Cloud Storage die SKUs für Dual- und Multi-Region-Buckets. Was Backup und Replikation grundsätzlich kosten, steht in Backup und Disaster Recovery; was Nicht-Produktivumgebungen insgesamt kosten dürfen, in Kosten von Nicht-Produktivumgebungen.

Konten oder Ressourcengruppenmit env=dev oder env=testMulti-AZUsage stattInstanceUsage; Compute-Metermit Hochverfügbarkeit;regionale Cloud SQL mitdoppeltem PreisGRS, RA-GRS, GZRS oder ZRS,wo LRS reichte; Dual- undMulti-Region-Buckets;Cross-Region-ReplikationPositionen, die nur inder Produktion hingehören
Unter einem Tag env=dev oder env=test trägt die Rechnung die Positionen der Produktion: einen Standby als volle Instanz und redundanten Speicher, wo LRS reichte

So erkennen Sie es

Der erste Schritt ist bei allen dreien gleich: die Nicht-Produktivumgebungen über Tag, Konto, Abonnement oder Projekt abgrenzen, wie Zuordnung nach Konto, Abonnement und Projekt es beschreibt, und darin suchen.

AWS

Datenbanken mit Standby und Cluster mit mehreren Instanzen, mit ihrem Umgebungs-Tag:

aws rds describe-db-instances --query 'DBInstances[?MultiAZ==`true`].[DBInstanceIdentifier,DBInstanceClass,Engine,TagList[?Key==`env`].Value|[0]]' --output table
aws rds describe-db-clusters --query 'DBClusters[].[DBClusterIdentifier,Engine,length(DBClusterMembers),MultiAZ]' --output table

Buckets mit Replikationsregeln zeigt aws s3api get-bucket-replication --bucket <bucket> je Bucket, und globale DynamoDB-Tabellen aws dynamodb describe-table --table-name <table> --query 'Table.Replicas'. Multi-AZ-Instanzen werden nach dem Multi-AZ-Preis der Preisliste berechnet, der den Standby enthält, und schreiben jede Transaktion zweimal (RDS-FAQ, gelesen am 2026-10-21); Trusted Advisor und Compute Optimizer haben keine Prüfung, die Multi-AZ nach Umgebung bewertet. In den Abrechnungsdaten ist der Kandidat eine Multi-AZUsage-Position in einem Konto, das account-map oder Cost Categories als Nicht-Produktion führen (AWS Cost and Usage Report).

Azure

Server mit Hochverfügbarkeit und Speicherkonten mit Georedundanz, mit Ressourcengruppe und Tags:

az postgres flexible-server list --query "[?highAvailability.mode!='Disabled'].{name:name, rg:resourceGroup, ha:highAvailability.mode, sku:sku.name, env:tags.env}" -o table
az storage account list --query "[?contains(sku.name,'GRS') || contains(sku.name,'GZRS')].{name:name, rg:resourceGroup, sku:sku.name, env:tags.env}" -o table
az sql db list --server <server> --resource-group <rg> --query "[?zoneRedundant==\`true\` || currentSku.tier=='BusinessCritical'].{name:name, tier:currentSku.tier, zr:zoneRedundant}" -o table

Bei Azure Database for PostgreSQL wird der Standby zum selben Satz wie der primäre Server berechnet, unabhängig davon, ob er in derselben oder einer anderen Zone steht (Zuverlässigkeit in Azure Database for PostgreSQL). Azure Advisor bewertet Hochverfügbarkeit nicht nach Umgebung. Im Kostenexport ist der Kandidat ein Compute-Meter mit doppelter Quantity je Server oder ein GRS-Meter in einer Ressourcengruppe mit Nicht-Produktions-Tag (Azure-Kostenexporte).

Google Cloud

Regionale Cloud-SQL-Instanzen und Buckets in Dual- oder Multi-Region:

gcloud sql instances list --filter="settings.availabilityType=REGIONAL" --format="table(name,settings.tier,settings.availabilityType,region,settings.userLabels.env)"
gcloud storage buckets list --format="table(name,location,locationType,labels.env)"

Eine Cloud-SQL-Instanz mit Hochverfügbarkeit kostet doppelt so viel wie eine eigenständige Instanz, einschließlich CPU, RAM und Speicher (Hochverfügbarkeit in Cloud SQL). Der Recommender für ungenutzte Instanzen findet die Instanz, nicht ihre Verfügbarkeitsstufe. Im Abrechnungsexport ist der Kandidat ein resource.name mit Regional-SKUs oder ein Bucket mit Multi-Region- oder Dual-Region-SKUs in einem Projekt mit Nicht-Produktions-Label (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Je Umgebung festlegen, was sie braucht: eine Entwicklungsumgebung keine Hochverfügbarkeit, eine Staging-Umgebung dieselbe Architektur wie die Produktion nur für den Zeitraum eines Tests, eine Umgebung mit vertraglicher Verfügbarkeit die der Produktion. Die Entscheidung gehört in die Kostenrichtlinie.
  2. Den Standby abschalten, als Online-Änderung mit kurzer Unterbrechung: AWS aws rds modify-db-instance --db-instance-identifier <instance> --no-multi-az --apply-immediately; Azure az postgres flexible-server update --resource-group <rg> --name <server> --high-availability Disabled; Google Cloud gcloud sql instances patch <instance> --availability-type=ZONAL. Aurora-Cluster verlieren ihre Leserinstanzen mit aws rds delete-db-instance je Instanz, der Writer bleibt.
  3. Die Redundanz des Speichers senken: az storage account update --name <account> --resource-group <rg> --sku Standard_LRS für ein Konto ohne Archivdaten; eine S3-Replikationsregel mit aws s3api delete-bucket-replication --bucket <bucket>; ein Bucket in Google Cloud wechselt die Region nicht, er wird durch einen regionalen ersetzt.
  4. Die Vorlage korrigieren: Terraform-Module, Bicep-Dateien und Deployment-Manager-Vorlagen bekommen eine Variable je Umgebung, die Hochverfügbarkeit, Redundanz und Replikation nur in der Produktion einschaltet; Kostenprüfung von Infrastrukturcode beschreibt, wo das im Review steht.

Keiner dieser Aufrufe hat ein Dry-Run; die Liste und die Freigabe ersetzen es. Der Standby fällt mit der Änderung aus der Rechnung, die Speicherredundanz mit der Umstellung des Kontos.

EntwicklungStagingvertraglicheVerfügbarkeitWas brauchtdie Umgebung?Keine HochverfügbarkeitDie Architektur der Produktionfür den Zeitraum eines TestsDie der ProduktionDen Standby abschalten: eineOnline-Änderung mitkurzer UnterbrechungDie Redundanz des Speicherssenken: LRS, keineReplikationsregel, einregionaler BucketDie Vorlage korrigieren: eineVariable je Umgebung schaltetHochverfügbarkeit nur in derProduktion einDer Standby fällt mit derÄnderung aus der Rechnung,die Redundanz mit derUmstellung des Kontos
Die Entscheidung je Umgebung kommt zuerst, dann gehen Standby und Redundanz, und die Variable in der Vorlage hält sie aus der Nicht-Produktion heraus

Risiken und Nebenwirkungen

  • Eine Staging-Umgebung ohne Hochverfügbarkeit testet den Failover nicht; wer ihn testen muss, schaltet sie für den Test ein und danach aus, oder plant den Test in der Produktion im Wartungsfenster.
  • Der Wechsel auf Single-AZ oder zonal ist eine Unterbrechung: bei RDS eine kurze, bei Cloud SQL ein Neustart, bei Azure die Entfernung des Standby ohne Failover. Ein laufender Testlauf bricht ab.
  • Eine Senkung der Speicherredundanz von GRS auf LRS löscht die zweite Kopie; Daten, die als einziges Backup im Speicherkonto liegen, brauchen vorher eine andere Sicherung.
  • Georedundante Backups sind bei Datenbanken eine eigene Einstellung; eine Umgebung, deren Backups aus Compliance-Gründen in einer zweiten Region liegen müssen, behält sie, auch ohne Standby.
  • Reservierungen auf die Datenbankklasse decken auch den Standby; ein abgeschalteter Standby lässt Reservierungsstunden frei, die eine andere Instanz füllen muss (Commitment-Abdeckung und -Auslastung).

So weisen Sie die Einsparung nach

Vorher: je Nicht-Produktionsumgebung die Multi-AZUsage-Positionen, die Compute-Meter mit Standby, die GRS-Meter und die Regional-SKUs im letzten vollen Monat. Nachher: dieselben Umgebungen im ersten vollen Monat nach der Umstellung, mit InstanceUsage statt Multi-AZUsage, einfacher Quantity, LRS-Metern und zonalen SKUs; die Differenz ist die Einsparung, und der Anteil der Nicht-Produktion an den Hochverfügbarkeitskosten ist die Kennzahl für den Bestand. Die Differenz aus der Preisliste ist die Schätzung, die Freigabe des Teams macht sie akzeptiert, die Umstellung umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert.

Quellen

Gelesen am 2026-10-21. Multi-AZ-DB-Instanzen in Amazon RDS, Amazon RDS, FAQ, Zuverlässigkeit in Azure Database for PostgreSQL, az postgres flexible-server, Azure Storage, Redundanz, Hochverfügbarkeit in Cloud SQL, gcloud sql instances patch.