Premium Network Tier Kosten sind das bekannteste Beispiel für eine Voreinstellung, die zahlt, ohne gefragt zu werden: Google Cloud leitet externen Verkehr standardmäßig über die Premium-Stufe, Azure legt Speicherkonten über die CLI standardmäßig georedundant an und OS-Disks auf Premium SSD, Datenbanken entstehen aus Vorlagen mit Business Critical oder Enterprise Plus, und Funktions-Apps mit einem Premium-Plan, weil der Assistent es vorschlug. Die Einsparung entsteht, weil die Standardstufe für die meisten Nicht-Produktionsumgebungen und viele Produktionsdienste reicht, und weil die Voreinstellung an einer Stelle geändert wird, der Vorlage, und danach für jede neue Ressource gilt. Die Behebung gehört dem Team, das die Infrastrukturvorlagen pflegt.

Symptom

Die Rechnung zeigt Premium-Positionen in Umgebungen, die keine Anforderung dafür haben. Bei AWS gibt es keine Netzwerkstufe, aber dieselbe Mechanik in Vorlagen: der Produktionsassistent von RDS wählt Multi-AZ und Provisioned IOPS, CloudFront nutzt standardmäßig alle Edge-Standorte, und io2 statt gp3 steht in manchem Modul; die Positionen heißen Multi-AZUsage, VolumeP-IOPS und DataTransfer-Out je Preisklasse. Bei Azure stehen GRS, RA-GRS und GZRS in den Speichermetern, Premium SSD Managed Disks bei OS-Disks von Testservern, Business Critical in MeterSubCategory von SQL-Datenbanken und Elastic Premium bei Funktions-Plänen. In Google Cloud trägt Networking die SKU Premium Tier Internet Egress statt Standard Tier, und Cloud SQL die SKUs der Edition Enterprise Plus. Welche Architekturentscheidungen Kosten vermeiden, steht in Architekturentscheidungen und Kosten; diese Seite behandelt die Entscheidungen, die niemand getroffen hat.

Eine Voreinstellung wähltdie Stufe: der Produktions-assistent, ein Modul, derStandard des ProvidersNiemand trifftdie EntscheidungPremium-Positionen:Multi-AZUsage, VolumeP-IOPS,GRS und GZRS, Premium SSD,Business Critical, ElasticPremium, Premium TierInternet Egress,Enterprise PlusIn einer Umgebung ohneAnforderung dafür
Ein Assistent, ein Modul oder die Voreinstellung des Providers wählt die Premium-Stufe, darum landen die Premium-Positionen in Umgebungen, die sie nie brauchten

So erkennen Sie es

AWS

Die Ressourcen, bei denen eine Vorlage die teurere Option gewählt hat:

aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,StorageType,Iops,DBInstanceClass]' --output table
aws cloudfront list-distributions --query 'DistributionList.Items[].[Id,PriceClass,Comment]' --output table
aws ec2 describe-volumes --filters Name=volume-type,Values=io1,io2 --query 'Volumes[].[VolumeId,VolumeType,Size,Iops,Attachments[0].InstanceId]' --output table

PriceClass_All bei CloudFront, io2 ohne Latenzanforderung und Multi-AZ in einem Konto mit Nicht-Produktions-Tag sind die Kandidaten; die Einzelheiten stehen in Hochverfügbarkeit in Nicht-Produktivumgebungen und überprovisionierten IOPS und Durchsatz. Trusted Advisor und Compute Optimizer finden die Voreinstellung nicht, nur ihre Folgen. In den Abrechnungsdaten ist der Kandidat eine Premium-Position in einem Konto, das als Nicht-Produktion geführt wird (AWS Cost and Usage Report).

Azure

Speicherkonten, Disks, Datenbanken und Pläne nach Stufe:

az storage account list --query "[?sku.name!='Standard_LRS' && sku.name!='Standard_ZRS'].{name:name, rg:resourceGroup, sku:sku.name, env:tags.env}" -o table
az disk list --query "[?sku.name=='Premium_LRS' && osType!=null].{name:name, rg:resourceGroup, gb:diskSizeGb, vm:managedBy}" -o table
az sql db list --server <server> --resource-group <rg> --query "[?currentSku.tier=='BusinessCritical' || currentSku.tier=='Premium'].{name:name, tier:currentSku.tier, sku:currentSku.name}" -o table
az functionapp plan list --query "[?sku.tier=='ElasticPremium'].{name:name, rg:resourceGroup, sku:sku.name}" -o table

az storage account create legt ein Konto ohne --sku als Standard_RAGRS an, also lesbar georedundant, und az vm create nimmt den Disk-Typ aus --storage-sku (gelesen am 2026-10-21, az storage account create, az vm create); ein Modul ohne diese Parameter erbt die Voreinstellung. Azure Advisor empfiehlt den Wechsel auf Premium nur in eine Richtung, bei hohem Transaktionsanteil, und bewertet Georedundanz nicht. Im Kostenexport ist der Kandidat ein GRS-, Premium- oder Business Critical-Meter in einer Ressourcengruppe mit Nicht-Produktions-Tag (Azure-Kostenexporte).

Google Cloud

Die Netzwerkstufe des Projekts und seiner Adressen, und die Edition der Datenbanken:

gcloud compute project-info describe --format="value(defaultNetworkTier)"
gcloud compute addresses list --format="table(name,region.basename(),address,networkTier,users.list())"
gcloud sql instances list --format="table(name,databaseVersion,settings.edition,settings.tier,settings.availabilityType)"

Premium ist die Voreinstellung der Netzwerkstufe, Standard ist günstiger und für Ressourcen mit regionalen externen Adressen verfügbar, nicht für globale Load Balancer, Cloud VPN und Cloud CDN (Netzwerkdienststufen). Bei Cloud SQL bringt Enterprise Plus Datencache, 99,99 Prozent Verfügbarkeitszusage und kürzere Wartungsunterbrechungen, und ist für MySQL 8.4 und 9.7 die Voreinstellung (Cloud-SQL-Editionen). Einen Recommender für die Stufe gibt es nicht. Im Abrechnungsexport ist der Kandidat eine Premium Tier-Egress-SKU oder eine Enterprise-Plus-SKU in einem Projekt mit Nicht-Produktions-Label (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Je Stufe festlegen, wann sie richtig ist: Premium-Netzwerk für Dienste mit Nutzern auf mehreren Kontinenten, Georedundanz für Daten mit einer Wiederherstellungsanforderung über Regionen, Business Critical und Enterprise Plus für Datenbanken mit Latenz- oder Verfügbarkeitszusage, Premium-Funktionspläne für Funktionen mit VNet-Anbindung oder ohne Kaltstarttoleranz. Alles andere bekommt die Standardstufe, und die Regel steht in der Kostenrichtlinie.
  2. Die Voreinstellung ändern, wo der Provider sie hat: gcloud compute project-info update --default-network-tier=STANDARD für ein Projekt ohne globale Load Balancer, und für neue Ressourcen --network-tier=STANDARD; bei Azure --sku Standard_LRS und --storage-sku StandardSSD_LRS als Parameter in jedem Modul, das Speicher oder VMs anlegt.
  3. Bestehende Ressourcen umstellen: az storage account update --name <account> --resource-group <rg> --sku Standard_LRS, az disk update --sku StandardSSD_LRS bei freigegebener VM, az sql db update --server <server> --resource-group <rg> --name <db> --edition GeneralPurpose --family Gen5 --capacity 2, az functionapp plan auf einen Consumption- oder Flex-Plan durch Neuanlage; bei Google Cloud eine neue regionale Adresse mit --network-tier=STANDARD und gcloud sql instances patch <instance> --edition=ENTERPRISE. Ohne Dry-Run; die Liste und ein Test der Latenz ersetzen es.
  4. Die Vorlage prüfen lassen: ein Schritt im Review von Infrastrukturcode, der jede Premium-Stufe gegen die Regel aus Schritt 1 hält, mit Werkzeugen wie Infracost, die den Preis einer Änderung in den Pull Request schreiben (Kostenprüfung von Infrastrukturcode).

Die Umstellung einer Ressource wirkt ab der Änderung; die Vorlage wirkt bei jeder neuen Ressource.

janeinJe Stufe, wann sie richtigist: Nutzer auf mehrerenKontinenten, Wieder-herstellung über Regionen,Latenz- oder Verfügbarkeits-zusage, VNet-Anbindung oderkeine KaltstarttoleranzErfüllt die Umgebungdie Regel?Die Premium-Stufe bleibtDie Standardstufe, nachder KostenrichtlinieDie Voreinstellung ändern,wo der Provider sie hat: dieNetzwerkstufe des Projekts,SKU-Parameter in jedem ModulBestehende Ressourcenumstellen: ohne Dry-Run, dieListe und ein Test derLatenz ersetzen esDie Vorlage prüfen lassen:ein Review-Schritt hält jedePremium-Stufe gegen dieRegel, der Preis einerÄnderung im Pull Request
Erst steht die Regel je Stufe, Voreinstellung und bestehende Ressourcen folgen ihr, und das Review hält jede neue Premium-Stufe dagegen

Risiken und Nebenwirkungen

  • Die Standard-Netzwerkstufe leitet Verkehr früher ins öffentliche Internet; Latenz und Routing ändern sich, und Nutzer außerhalb der Region merken es zuerst. Ein Vergleich der Antwortzeiten gehört vor die Umstellung.
  • Georedundanz abzuschalten löscht die zweite Kopie; ein Konto, das das einzige Backup hält, braucht vorher ein anderes.
  • Ein Editionswechsel bei Datenbanken ist ein Neustart mit Wartungsfenster, und Funktionen wie Datencache oder Zonenredundanz fallen weg; die Verfügbarkeitszusage sinkt mit.
  • Ein Funktionsplan ändert sich nicht in place; die App zieht in einen neuen Plan um, mit neuer Skalierung und neuen Kaltstarts.
  • Die Standardstufe ist nicht immer billiger: eine Standard-HDD mit vielen Transaktionen kostet mehr als eine Standard SSD, und CloudFront in einer niedrigeren Preisklasse zahlt für Nutzer außerhalb der Klasse den Umweg.

So weisen Sie die Einsparung nach

Vorher: je Ressource die Premium-Position im letzten vollen Monat, Premium Tier Internet Egress, GRS-Meter, Premium SSD-Meter, Business Critical-vCores, Elastic Premium-Stunden, Enterprise-Plus-SKUs, mit der Umgebung aus Tag oder Konto. Nachher: dieselbe Ressource im ersten vollen Monat nach der Umstellung mit der Standardposition, und die Zahl neuer Ressourcen mit Premium-Stufe ohne Begründung, die nach der Vorlagenänderung null bleiben muss. 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. Der Anteil der Premium-Positionen in Nicht-Produktionsumgebungen ist die Kennzahl für das Kostenreview.

Quellen

Gelesen am 2026-10-21. Google Cloud, Netzwerkdienststufen, Cloud-SQL-Editionen, gcloud compute project-info, az storage account, az vm, Azure Advisor, Kostenempfehlungen, aws cloudfront list-distributions.