ARM-Cloud-Instanzen sind die Graviton-, Cobalt- und Axion-Typen der drei Provider: dieselbe Größe wie ein x86-Typ zu einem niedrigeren Stundensatz, bei AWS nach eigener Angabe bis zu 20 Prozent günstiger als vergleichbare x86-Instanzen und bei Lambda mit 20 Prozent niedrigeren Dauergebühren. Die Einsparung entsteht aus dem Satz je vCPU und, wo die Leistung pro Kern höher ist, aus einer kleineren Größe. Die Behebung gehört dem Team, das Images baut und Deployments pflegt, weil ein Architekturwechsel in der Build-Pipeline beginnt und nicht in der Konsole endet.

Symptom

Die Rechnung trägt die Architektur im Typnamen. Bei AWS unterscheidet lineItem/UsageType EUC1-BoxUsage:m6i.large von EUC1-BoxUsage:m7g.large, product/physicalProcessor nennt den Prozessor, und Lambda rechnet Lambda-GB-Second gegen Lambda-GB-Second-ARM ab; RDS-, ElastiCache- und OpenSearch-Klassen mit g im Namen, etwa db.m7g.large oder cache.m7g.large, sind die ARM-Varianten. Bei Azure stehen die Cobalt-Größen als D4ps v6, D4pls v6 oder E4ps v6 im MeterName, die x86-Größen als D4s v5 oder D4s v6. In Google Cloud heißen die SKUs C4A Instance Core running in Frankfurt oder T2A Instance Core running gegenüber N2 Instance Core running. Ein Bestand, in dem fast alle Compute-Stunden auf x86-Typen laufen, obwohl die Workloads auf Linux und in Containern leben, zahlt den Aufschlag ohne Grund. Die Familien erklärt virtuelle Maschinen und Instanzfamilien.

Der Typname trägtdie Architekturx86-Positionen: m6i,Lambda-GB-Second,D4s v5, N2ARM-Positionen: m7g,Lambda-GB-Second-ARM,D4ps v6, C4A und T2AFast alle Compute-Stundenauf x86, obwohl dieWorkloads auf Linux undin Containern lebenZahlt den Aufschlagohne Grund
Die Architektur steht im Typnamen, und Compute-Stunden fast nur auf x86 für Linux- und Container-Workloads sind das Symptom

So erkennen Sie es

AWS

Die Architektur je Instanz steht in describe-instances:

aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,Architecture,PlatformDetails]' --output table

Welche Typen in der Region ARM bieten, listet aws ec2 describe-instance-types --filters Name=processor-info.supported-architecture,Values=arm64 --query 'InstanceTypes[].InstanceType'. Compute Optimizer rechnet die Empfehlungen auf Wunsch nur mit Graviton-Typen und zeigt den Preisunterschied und den Migrationsaufwand je Instanz, den er aus dem erkannten Workload ableitet, etwa niedrig für EMR und hoch für Software ohne ARM-Version:

aws compute-optimizer get-ec2-instance-recommendations --recommendation-preferences cpuVendorArchitectures=AWS_ARM64 \
  --query 'instanceRecommendations[].[currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].migrationEffort,recommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value]' --output table

Die Funktionen, Datenbanken und Caches auf x86:

aws lambda list-functions --query 'Functions[?Architectures[0]!=`arm64`].[FunctionName,Runtime,PackageType,MemorySize]' --output table
aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,DBInstanceClass,Engine,EngineVersion]' --output table
aws elasticache describe-cache-clusters --query 'CacheClusters[].[CacheClusterId,CacheNodeType,Engine]' --output table

In den Abrechnungsdaten ist der x86-Anteil die Summe der BoxUsage-Stunden ohne g an der Familienposition des Typs gegen alle BoxUsage-Stunden, und bei Lambda das Verhältnis der beiden GB-Sekunden-Nutzungsarten (AWS Cost and Usage Report).

Azure

Die Cobalt-100-Serien Dpsv6, Dplsv6 und Epsv6 sind seit Oktober 2024 allgemein verfügbar; Microsoft nennt bis zu 50 Prozent besseres Preis-Leistungs-Verhältnis gegenüber der eigenen vorherigen ARM-Generation, nicht gegenüber x86 (Ankündigung). Der Bestand nach Größe, mit den ARM-Größen am p in der Familienkennung:

az vm list --query "[].{name:name, size:hardwareProfile.vmSize, os:storageProfile.osDisk.osType}" -o table
az vm list-skus --location germanywestcentral --resource-type virtualMachines \
  --query "[?contains(name,'ps_v6') || contains(name,'pls_v6') || contains(name,'pds_v6')].name" -o tsv

AKS-Knotenpools zeigen ihre Größe mit az aks nodepool list --cluster-name <cluster> --resource-group <rg> --query "[].{name:name, size:vmSize, os:osType}" -o table. Azure Advisor hat keine Empfehlung für den Architekturwechsel; die Resize-Empfehlung bleibt in der Architektur der VM. Im Kostenexport ist der Anteil die Summe der Quantity je MeterName mit p in der Größe gegen alle Virtual Machines-Zeilen (Azure-Kostenexporte).

Google Cloud

C4A läuft auf Googles Axion-Prozessor, T2A auf Ampere Altra; Google nennt für Axion bis zu 50 Prozent mehr Leistung und bis zu 60 Prozent bessere Energieeffizienz als vergleichbare x86-Instanzen der aktuellen Generation, ohne eine Preisangabe (Ankündigung). Die x86-Instanzen im Bestand:

gcloud compute instances list --filter="NOT machineType ~ '/(c4a|t2a)-'" \
  --format="table(name,zone.basename(),machineType.basename(),status)"

GKE-Knotenpools: gcloud container node-pools list --cluster=<cluster> --location=<location> --format="table(name,config.machineType,config.imageType)". Der Maschinentyp-Recommender empfiehlt innerhalb der Architektur; einen Recommender für den Wechsel gibt es nicht. Im Abrechnungsexport ist der Anteil die Summe der usage.amount auf Instance Core running-SKUs ohne C4A oder T2A im Namen (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Die Kompatibilität je Workload prüfen, mit einer Checkliste, die AWS für Lambda vorgibt und die für alle gilt: jede Abhängigkeit hat eine arm64-Version; Container-Images sind Multi-Architektur-Images (docker buildx build --platform linux/amd64,linux/arm64); Layer, Erweiterungen, Agenten für Monitoring und Sicherheit und lizenzierte Software laufen auf ARM; das Image oder die AMI ist eine arm64-Variante; die CI baut und testet beide Architekturen (Lambda-Architekturen).
  2. In dieser Reihenfolge migrieren: zuerst zustandslose Dienste hinter einem Load Balancer, mit einem gemischten Pool und einem Vergleich der Antwortzeiten; dann Funktionen, bei Lambda mit aws lambda update-function-configuration --function-name <fn> --architectures arm64, versioniert und über einen Alias mit Gewichtung ausgerollt; dann verwaltete Dienste, bei denen der Wechsel ein Klassenwechsel mit Neustart ist: aws rds modify-db-instance --db-instance-identifier <id> --db-instance-class db.m7g.large --apply-immediately, aws elasticache modify-replication-group --replication-group-id <id> --cache-node-type cache.m7g.large --apply-immediately, für OpenSearch aws opensearch update-domain-config mit einem Graviton-Instanztyp; dann Kubernetes-Pools, als zusätzlicher ARM-Pool mit Taint, Toleration und Multi-Architektur-Images, bevor der x86-Pool schrumpft; zuletzt zustandsbehaftete Server, die neu gebaut werden.
  3. Bei Azure und Google Cloud ist die VM selbst nicht umzustellen: ein x86-Image läuft nicht auf einer Cobalt- oder Axion-Größe, also entsteht eine neue VM aus einem arm64-Image und ersetzt die alte, wie beim Wechsel der Generation.
  4. Die Vorlagen ändern: Launch Templates, Scale Sets, Instanzvorlagen, Knotenpool-Definitionen, damit die nächste Umgebung auf ARM entsteht.

Der neue Satz gilt ab dem Start des neuen Typs; keine der drei CLIs bietet für diese Änderungen ein Dry-Run, deshalb gehört die Liste aus dem ersten Schritt vor jeden Aufruf.

ja: Lambda, RDS,ElastiCache, OpenSearchnein: eine VM bei Azureoder Google CloudCheckliste je Workload:arm64-Versionen, Multi-Architektur-Images, Agentenund LizenzenIn Reihenfolge migrieren:zustandslose Dienste,Funktionen, verwalteteDienste, Kubernetes-Pools,zuletzt zustandsbehafteteServerUmstellbaran Ort und Stelle?Architektur oder Klassewechseln, mit NeustartEine neue VM aus einemarm64-Image ersetzt die alteDie Vorlagen ändern, damitdie nächste Umgebungauf ARM entsteht
Erst die Kompatibilität, dann die Migration von zustandslos nach zustandsbehaftet, und nur AWS-Ressourcen wechseln an Ort und Stelle

Risiken und Nebenwirkungen

  • Eine Abhängigkeit ohne arm64-Build stoppt die Migration an dieser Stelle; typisch sind native Erweiterungen, alte Treiber und proprietäre Agenten. Der Test im gemischten Pool findet sie, bevor der x86-Pool weg ist.
  • Die Leistung je Kern unterscheidet sich je Workload in beide Richtungen; die Größe der ARM-Instanz wird gemessen, nicht übernommen.
  • Ein Commitment auf x86 bleibt bestehen: ein EC2 Instance Savings Plan und eine Standard Reserved Instance gelten für ihre Familie, ein Compute Savings Plan deckt Graviton mit ab; Azure-Reservierungen gelten je Größengruppe; ressourcenbasierte Committed Use Discounts bei Google je Maschinenfamilie (Wahl zwischen Commitment-Typen).
  • Lizenzen von Drittanbietern sind zuweilen auf x86 beschränkt oder je Kern bepreist; der Wechsel ändert die Kernzahl.
  • Windows-Workloads fallen weg: Dpsv6 unterstützt Windows-Client-VMs, die Server- und Datenbankwelt auf ARM ist bei allen drei Providern Linux.

So weisen Sie die Einsparung nach

Vorher: je Ressource die Stunden und der Betrag der x86-Position, BoxUsage:m6i.large, D4s v5, N2 Instance Core running, im letzten vollen Monat, bei Lambda die GB-Sekunden auf Lambda-GB-Second. Nachher: dieselbe Ressource oder ihr Ersatz auf der ARM-Position im ersten vollen Monat, mit gleicher Arbeit, gemessen an Anfragen oder Jobs, und niedrigerem Betrag; der x86-Anteil an allen Compute-Stunden ist die Kennzahl für den Bestand. Die Preisdifferenz aus Compute Optimizer oder aus dem Instanzvergleich 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. Bleibt ein x86-Commitment zurück, zeigt dessen Auslastung, ob die Einsparung echt ist.

Quellen

Gelesen am 2026-10-21. AWS Graviton, Lambda-Befehlssatzarchitektur, Lambda-Funktionen auf Graviton2, AWS-Blog vom 2021-09-29, Compute Optimizer, EC2-Empfehlungen, get-ec2-instance-recommendations, describe-instance-types, Azure Cobalt 100 VMs allgemein verfügbar, Dpsv6-Serie, Google Axion, Allzweck-Maschinenfamilie.