Instanzen älterer Generationen

Instanzen älterer Generationen laufen auf Hardware, die der Provider nicht mehr ausbaut, zu einem Preis, der die neuere Generation meist nicht unterbietet: ein m4.large kostet mehr als ein m7i.large derselben Größe, ein D4 v3 ähnlich viel wie ein D4 v5, ein n1-standard-4 ähnlich viel wie ein n2-standard-4, bei weniger Leistung pro Stunde. Die Einsparung entsteht aus beidem, dem niedrigeren oder gleichen Preis und der höheren Leistung, die eine kleinere Größe erlaubt. Die Behebung gehört dem Team, das das Image und die Deployment-Vorlage pflegt, weil ein Generationswechsel dort beginnt, nicht in der Konsole.

Symptom

Die Rechnung nennt die Generation in jeder Position. Bei AWS steht sie im lineItem/UsageType, etwa EUC1-BoxUsage:m4.large, und in product/instanceType; bei Azure nennt MeterSubCategory die Serie, etwa Dv3/DSv3 Series, und MeterName die Größe; in Google Cloud heißt die SKU N1 Predefined Instance Core running in Frankfurt statt N2 Instance Core running. Ein Bestand, in dem diese Positionen einen spürbaren Anteil der Instanzstunden tragen, zahlt für Leistung, die er mit der aktuellen Generation günstiger bekäme. Die Listenpreise je Generation und europäischer Region zeigt der Instanzvergleich; die Familien und ihre Namensregeln erklärt virtuelle Maschinen und Instanzfamilien.

So erkennen Sie es

AWS

AWS führt die Vorgängergenerationen mit ihrer empfohlenen Nachfolge auf einer eigenen Seite (gelesen am 2026-10-21): T1 zu T3, T3a oder T4g, M1 und M3 zu M7i, M7g oder M7a, I2 zu I3, M2, CR1 und R3 zu R4, HS1 zu D2, G2 zu G3, A1 zu C7g; M4, C3, C4 und R4 stehen in der Tabelle ohne ausgesprochene Nachfolge, die Namensregel führt sie zu M7, C7 und R7. Welche Typen AWS als aktuell führt, sagt die API selbst:

aws ec2 describe-instance-types --filters Name=current-generation,Values=false \
  --query 'InstanceTypes[].InstanceType' --output text | tr '\t' '\n' | sort

Der eigene Bestand nach Typ, mit Anzahl:

aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].InstanceType' --output text | tr '\t' '\n' | sort | uniq -c | sort -rn

Compute Optimizer empfiehlt auch bei als "Optimized" eingestuften Instanzen zuweilen einen Typ der neuen Generation und zeigt den Preisunterschied je Option:

aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceArn,currentInstanceType,finding,recommendationOptions[0].instanceType,recommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value]' \
  --output table

In den Abrechnungsdaten ist der Anteil der alten Generation die Summe der BoxUsage-Stunden, deren product/instanceType in der Liste von describe-instance-types steht, gegen alle BoxUsage-Stunden (AWS Cost and Usage Report).

Azure

Microsoft führt die Vorgängerserien in einer eigenen Liste und hat für Dv3, Dsv3, Ev3 und Esv3 den Ruhestand zum 2029-11-15 angekündigt; Reservierungen für diese Serien sind nach dem 2026-07-01 nicht mehr neu zu kaufen oder zu verlängern, und die empfohlenen Ziele sind Dv5, Dsv5, Ddv5, Ddsv5, Dasv5 und Dadsv5 beziehungsweise die E-Serien in v5 (Modernisierungsleitfaden). Der Bestand nach Größe:

az vm list --query "[].hardwareProfile.vmSize" -o tsv | sort | uniq -c | sort -rn

Die Größen, die auf _v2 oder _v3 enden oder keine Versionsnummer tragen, sind die Kandidaten. Azure Advisor empfiehlt in seiner Resize-Empfehlung ausdrücklich auch Größen einer neueren Version, etwa D3v2 zu D2v3, wenn die Last dort günstiger passt:

az advisor recommendation list --category Cost --query "[?contains(shortDescription.problem, 'virtual machine')].{resource:resourceMetadata.resourceId, problem:shortDescription.problem}" -o table

Im Kostenexport ist die Serie an MeterSubCategory ablesbar; die Summe der Quantity je Serie gegen die Gesamtsumme ist der Anteil (Azure-Kostenexporte).

Google Cloud

Google ordnet N1 und die zugehörigen Shared-Core-Typen als erste Generation der Allzweckfamilie ein und E2, N2, N2D, T2A und T2D als zweite (Allzweck-Maschinenfamilie). Der Bestand nach Serie:

gcloud compute instances list --format="value(machineType.basename())" | cut -d- -f1 | sort | uniq -c | sort -rn

Der Recommender für Maschinentypen bewertet acht Tage CPU- und Speichernutzung und empfiehlt einen Standard- oder benutzerdefinierten Typ, der in der Zone verfügbar ist (Maschinentyp-Empfehlungen):

gcloud recommender recommendations list --project=<project-id> --location=<zone> \
  --recommender=google.compute.instance.MachineTypeRecommender --format="table(name.basename(),description,primaryImpact.category)"

Im Abrechnungsexport ist die Generation Teil der sku.description; die Summe der usage.amount auf N1-SKUs gegen alle Instance Core running-SKUs ist der Anteil (Google-Cloud-Abrechnungsexport).

So beheben Sie es

1. Die Zielgröße aus der Nachfolgetabelle des Providers wählen und mit dem Recommender gegenprüfen: oft reicht eine Größe kleiner, weil die neue Generation pro vCPU mehr leistet.
2. Die Voraussetzungen prüfen, die ein Generationswechsel mitbringt: bei AWS der ENA-Netzwerktreiber und der NVMe-Treiber für Nitro-Typen und ein HVM-Image statt PV; bei Azure Accelerated Networking, das die Intel-v5-Serien voraussetzen, und ein unterstütztes Image; bei Google Cloud nichts Vergleichbares, aber ein Blick auf lokale SSDs und GPUs, die nicht jede Serie bietet.
3. Den Typ ändern, bei allen dreien im gestoppten Zustand. AWS: aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --instance-type '{"Value":"m7i.large"}' --dry-run, dann ohne --dry-run. Azure: az vm resize --resource-group <rg> --name <vm> --size Standard_D2s_v5, was die VM freigibt, wenn die Größe auf dem Host nicht verfügbar ist. Google Cloud: gcloud compute instances set-machine-type <vm> --zone=<zone> --machine-type=n2-standard-2 nach gcloud compute instances stop.
4. Die Vorlage ändern: Launch Templates, Scale-Set-Modelle, Instanzvorlagen und die Infrastrukturdefinitionen, aus denen neue Instanzen entstehen, sonst kommt die alte Generation mit dem nächsten Deployment zurück.

Die neue Stundenrate gilt ab dem Start; die Rechnung des Folgemonats zeigt den vollen Effekt.

Risiken und Nebenwirkungen

• Ein Commitment auf die alte Familie bleibt bestehen. Eine Standard Reserved Instance ist an ihre Familie gebunden, eine Convertible lässt sich tauschen, ein Compute Savings Plan deckt jede Familie; eine Azure-Reservierung gilt für ihre Größengruppe und kann nach den Regeln von Microsoft getauscht oder in einen Savings Plan umgewandelt werden; ein ressourcenbasierter Committed Use Discount von Google gilt je Maschinenfamilie und Region, ein ausgabenbasierter nicht (Commitment-Tausch, -Kündigung und -Ablauf).
• Ein Wechsel auf eine andere Architektur ist ein eigener Schritt mit eigener Seite, Umstieg auf ARM-Instanzen; M7g statt M7i ist eine Portierung, nicht ein Resize.
• Lizenzen pro Kern, etwa für Datenbanken, verändern sich mit der vCPU-Zahl der Zielgröße in beide Richtungen.
• Lokaler Instanzspeicher geht beim Wechsel auf einen Typ ohne ihn verloren; Daten darauf müssen vorher auf ein Volume.
• Die Leistung ist erst nach dem Wechsel messbar: eine Größe kleiner spart nur, wenn die Antwortzeiten halten. Ein Vergleich über eine Woche, mit den Metriken aus Rightsizing, gehört zum Schritt.

So weisen Sie die Einsparung nach

Vorher: die Stunden und der Betrag der BoxUsage-, Virtual Machines- und Instance Core running-Positionen je Ressource im letzten vollen Monat, mit lineItem/UnblendedRate beziehungsweise EffectivePrice als Stundensatz. Nachher: dieselbe Ressource im ersten vollen Monat auf dem neuen Typ, mit gleicher oder niedrigerer Stundenzahl und dem neuen Satz; die Differenz ist die Einsparung, und der Anteil der alten Generation an allen Instanzstunden ist die Kennzahl für den Bestand. Der Preisunterschied aus dem Recommender ist die Schätzung, die Zustimmung des Teams macht sie akzeptiert, der Wechsel umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Wo ein Commitment die alte Familie weiter abdeckt, zeigt erst dessen Auslastung, ob die Einsparung echt ist.

Quellen

Gelesen am 2026-10-21. Instanzen der Vorgängergeneration bei AWS, describe-instance-types, Compute Optimizer, EC2-Empfehlungen, Azure, Vorgängerserien, Azure, Modernisierungsleitfaden für Ruhestandsserien, Azure, Umstieg auf die v5-Serien, Azure Advisor, unterausgelastete VMs, Allzweck-Maschinenfamilie in Google Cloud, Maschinentyp-Empfehlungen.