Eine virtuelle Maschine wird als Instanztyp gekauft, dessen Name Familie, Generation, Prozessor und Größe kodiert, und ihr Stundenpreis folgt aus genau diesen Merkmalen plus Region, Betriebssystem und Kaufoption. Compute ist in vielen Cloud-Rechnungen der größte Block, und weil die Preisfaktoren im Namen stecken, entscheidet die Wahl des Typs mehr über die Rechnung als jede spätere Optimierung derselben Maschine.

So funktioniert es

Alle drei Provider verkaufen vordefinierte Größen aus Familien, die ein Verhältnis von vCPU zu Arbeitsspeicher und eine Hardware-Generation festlegen. Der Preis wächst innerhalb einer Familie mit der Größe, bei Google Cloud ausdrücklich pro vCPU und pro GB, und unterscheidet sich zwischen Familien, Generationen, Prozessorarchitekturen und Regionen. Die Namen folgen drei verschiedenen Grammatiken.

AWS

Ein EC2-Instanztyp wie m7g.large liest sich von links: m ist die Familie (General Purpose; c Compute-optimiert, r Memory-optimiert, t Burstable, p und g GPU, i und d Storage), 7 die Generation, die Buchstaben danach die Optionen: g für AWS Graviton (Arm), a für AMD, i für Intel, d für lokale Instance-Store-Volumes, n für mehr Netzwerk- und EBS-Durchsatz, e für zusätzlichen Speicher oder Arbeitsspeicher, z für hohe Taktfrequenz. Nach dem Punkt folgt die Größe, von nano über large und 4xlarge bis metal für Bare Metal; jede Stufe vervielfacht vCPU und Arbeitsspeicher. AWS rechnet in Sekunden ab, mit einem Minimum von 60 Sekunden, für Linux, Windows, RHEL und Ubuntu Pro; SUSE Linux Enterprise Server wird als volle Stunde berechnet. Kaufoptionen sind On-Demand, Spot, Savings Plans und Reserved Instances. Im Cost and Usage Report steht die Instanz als Usage Type nach dem Muster Region, BoxUsage, Typ, in der AWS-Dokumentation etwa USW2-BoxUsage:m2.2xlarge, mit line_item_operation RunInstances; EBS-Volumes, öffentliche IPv4-Adressen und Datentransfer sind eigene Positionen.

Azure

Azure benennt Größen nach dem Muster Familie, Unterfamilie, Zahl der vCPUs, Zusatzmerkmale, Beschleuniger, Version: Standard_D4s_v5 ist die D-Familie (General Purpose; E Memory-optimiert, F Compute-optimiert, N GPU, M sehr viel Arbeitsspeicher, L Storage, B Burstable) mit 4 vCPUs, s für Premium-SSD-Fähigkeit, Version 5. Weitere Kleinbuchstaben: a AMD, p Arm (Microsoft Cobalt oder Ampere Altra), d lokale temporäre Disk, l wenig Arbeitsspeicher, m viel Arbeitsspeicher, i isoliert. Eine Zahl mit Bindestrich wie M8-2ms_v2 ist eine Größe mit eingeschränkten vCPUs: die Hardware der 8-vCPU-Größe, von der 2 vCPUs aktiv sind. Azure rechnet nach vollen Minuten ab, in denen die VM läuft. Der Linux-Preis ist der Compute-Preis plus gegebenenfalls Support des Distributors; beim Windows-Preis zahlt man mit Azure Hybrid Benefit nur Compute, weil die vorhandene Lizenz mitgebracht wird. OS-Disk, Datendisks, öffentliche IPs und Egress werden getrennt berechnet. In den Kostendetails steht die VM unter MeterCategory Virtual Machines mit einem Meter je Größe, Betriebssystem und Region; AdditionalInfo nennt die exakte Größe als ServiceType, und ComputeHR_SW markiert die Position für kostenpflichtige Software.

Google Cloud

Compute Engine ordnet Maschinentypen in Familien (General Purpose, Compute-, Memory-, Storage-, Netzwerk- und Accelerator-optimiert) und Serien, die Generation und Prozessor festlegen: N4 und C4 auf Intel, N4D und C4D auf AMD, C4A und N4A auf Googles Arm-Prozessor Axion, Tau T2A auf Ampere Altra, E2 als günstige Serie für Alltagslasten. Der Name n2-standard-4 liest sich Serie, Typ, vCPUs: standard steht für etwa 4 GB pro vCPU, highcpu für etwa 2, highmem für etwa 8, und -lssd oder -metal hängen lokale SSDs beziehungsweise Bare Metal an. Für die N- und E-Serien gibt es Custom Machine Types, etwa n2-custom-4-8192, mit einem Aufschlag von 5 Prozent auf den vordefinierten On-Demand-Preis. Google berechnet vCPU und Arbeitsspeicher als getrennte Ressourcen pro Sekunde, mit einem Minimum von einer Minute; Spot-Preise, Committed Use Discounts und Sustained Use Discounts für die dafür genannten Serien senken den Preis. Lizenzpflichtige Images folgen demselben Sekundenmodell und werden zusätzlich berechnet. Im Abrechnungsexport erscheint keine „Maschine“, sondern je eine Position für vCPU-Stunden und für GB-Stunden mit sku.description und location.zone.

Was es für Ihre Kosten bedeutet

Den Stundenpreis bestimmen Größe (vCPU und Arbeitsspeicher), Familie und Generation, Prozessorarchitektur (Arm-Typen sind bei allen drei Providern eine eigene Preisliste), Zusatzoptionen wie lokale Disks oder GPUs, das Betriebssystem mit seiner Lizenz, die Region und die Kaufoption. Die Region allein kann denselben Typ spürbar verteuern; die aktuellen Listenpreise je Region vergleicht der Instanzpreis-Explorer.

Die Instanz ist nie die ganze Rechnung: Disks, Snapshots, öffentliche IP-Adressen und Datentransfer laufen als eigene Positionen, bei AWS und Azure mit eigenen Usage Types und Metern, bei Google als eigene SKUs; welche Grenzen der Transfer kostet, beschreibt die Seite zu Datentransfer und Egress. Ein Kostenbericht nach Instanztyp zeigt deshalb nur den Compute-Anteil, und ein Vergleich zwischen Providern muss die Nebenpositionen mitnehmen.

Für Rightsizing zählt, dass die Preisfaktoren getrennt sind: Ein Wechsel der Generation bei gleicher Größe, ein Wechsel auf Arm bei gleicher Generation oder eine Größe kleiner in derselben Familie sind drei verschiedene Hebel mit drei verschiedenen Risiken, und die Abrechnungsdaten zeigen jeden davon als eigene Änderung des Usage Type, Meters oder der SKU.

Wo es schiefgeht

  • Größen nur nach vCPU verglichen. Symptom: Die „gleich große“ Maschine beim anderen Provider ist teurer oder langsamer. Ursache: Eine vCPU ist je nach Serie ein ganzer physischer Kern oder ein Hardware-Thread, und Arbeitsspeicher, Netzwerkdurchsatz und lokale Disks stecken in den Buchstaben, nicht in der Zahl.
  • Lizenz in einem Preis, im anderen nicht. Symptom: Ein Windows- oder SQL-Server-Vergleich fällt einseitig aus. Ursache: Der eine Preis enthält die Lizenz, der andere setzt Azure Hybrid Benefit oder eine mitgebrachte Lizenz voraus, und bei AWS wird SUSE pro Stunde statt pro Sekunde berechnet.
  • Vorgeneration teurer als die aktuelle. Symptom: Die Flotte läuft auf m5, v3 oder N1, obwohl die Nachfolger in derselben Region pro Stunde günstiger gelistet sind. Ursache: Die Provider listen jede Generation mit eigenem Preis, und niemand liest die Preisliste nach dem ersten Start noch einmal.
  • Größe für die Spitze gewählt. Symptom: Hohe Kosten bei niedriger durchschnittlicher Auslastung. Ursache: Die Größe wurde für die Lastspitze eines Tages gewählt, obwohl die Provider Burstable-Familien, Autoscaling und Sekundenabrechnung genau für diesen Fall anbieten.
  • Region aus Gewohnheit. Symptom: Derselbe Typ kostet in der gewohnten Region mehr als in der Nachbarregion. Ursache: Die Region wurde beim ersten Projekt gewählt und seither nie gegen Preisliste, Latenz und Datenresidenz geprüft.

Quellen

Gelesen am 2026-10-15. Namenskonventionen für EC2-Instanztypen, Amazon EC2 On-Demand-Preise, CUR 2.0: Line-Item-Spalten, Namenskonventionen für Azure-VM-Größen, Größen virtueller Maschinen in Azure, Azure Virtual Machines Linux Preise, Azure VM Usage verstehen, Compute Engine: Maschinenfamilien und Serien, Compute Engine VM Instance Pricing, Struktur des Standard-Exports.