AWS Graviton Migration 2026: EC2 auf ARM

Q: Kann ich Docker-Images für Graviton einfach neu bauen?

Ja, mit docker buildx build --platform linux/amd64,linux/arm64 erzeugen Sie ein Multi-Arch-Manifest, das auf beiden Architekturen läuft. Prüfen Sie dabei alle Base-Images (Alpine, Debian-slim, Distroless unterstützen ARM64 seit Jahren).

Aktualisiert: 1. Juli 2026

Eine AWS Graviton Migration senkt die EC2-Kosten typischerweise um 20–40 %, weil ARM-basierte Graviton3- und Graviton4-Instanzen bei gleicher vCPU-Anzahl bis zu 40 % besseres Preis-Leistungs-Verhältnis liefern als vergleichbare x86-Instanzen (m7i, c7i, r7i). In diesem Praxisleitfaden zeige ich, wie Sie EC2-Workloads systematisch von x86 auf Graviton umstellen, welche Kompatibilitätsprobleme wirklich relevant sind, wie sich Compute Savings Plans mit Graviton kombinieren lassen – und wo ich in Kundenprojekten die größten Fallen gesehen habe.

Graviton4-Instanzen (R8g, M8g, C8g) bieten laut AWS bis zu 40 % besseres Preis-Leistungs-Verhältnis gegenüber x86-Pendants der 7. Generation.
Compute Savings Plans gelten auch für Graviton – ein Wechsel von m7i.xlarge auf m7g.xlarge behält Ihren Commitment-Rabatt.
Kritischer Blocker sind selten das Betriebssystem, sondern native NPM-Module, .NET-Framework (nicht Core) und ältere Oracle-Java-Builds.
Managed Services wie RDS, Aurora, ElastiCache, OpenSearch und Lambda unterstützen Graviton nativ – häufig ist nur ein Instance-Type-Wechsel nötig.
Docker-Images müssen als Multi-Arch-Manifests (linux/amd64 + linux/arm64) gebaut werden, sonst schlägt das Deployment auf ARM-Nodes fehl.
Rechnen Sie mit einer realistischen Migrationsdauer von 2–6 Wochen für einen mittelgroßen Kubernetes-Cluster inklusive Test und schrittweiser Traffic-Umstellung.

Was ist AWS Graviton und warum ist es günstiger?

AWS Graviton ist eine Familie von ARM64-Prozessoren, die AWS selbst auf Basis der Neoverse-Kerne von Arm entwickelt. Der Kostenvorteil kommt aus drei Quellen: Erstens spart AWS Lizenzgebühren, weil kein x86-IP von Intel oder AMD anfällt. Zweitens ist die Kern-Dichte höher – ein Graviton4-Chip packt 96 Kerne auf ein Die, was pro Quadratmillimeter Silizium mehr vCPUs erzeugt. Drittens sind die Kerne single-threaded (kein SMT/Hyperthreading), sodass jede vCPU einem physischen Kern entspricht – das ist ein wichtiger Unterschied, wenn Sie Kubernetes-Workloads mit Karpenter nach CPU-Limits rightsizen.

In der Praxis bedeutet das: Eine c7g.xlarge (Graviton3, 4 vCPU, 8 GB RAM) kostet in eu-central-1 rund 0,1450 USD/Stunde, während die x86-Variante c7i.xlarge bei 0,1904 USD/Stunde liegt. Das sind 23,8 % Ersparnis allein aus dem Listenpreis, bevor irgendein Savings Plan greift. Bei Storage-optimierten Workloads (i8g vs. i7i) und Memory-optimierten (r8g vs. r7i) fällt der Unterschied ähnlich aus. Details zur Instanzfamilie stehen in der offiziellen AWS-Graviton-Übersicht.

Graviton3 vs. Graviton4: Welche Generation lohnt sich?

Graviton4 wurde Ende 2024 mit den R8g-Instanzen allgemein verfügbar und ist seit 2025/2026 in allen Instanzfamilien (M8g, C8g, X8g, I8g) verbreitet. Für neue Deployments würde ich immer Graviton4 nehmen – die Preisdifferenz zu Graviton3 ist marginal, aber die Performance je nach Workload 30 % besser.

Merkmal	Graviton3 (c7g)	Graviton4 (c8g)
vCPUs pro Instanz (max)	64	96
RAM pro Instanz (max, c-Familie)	128 GB	192 GB
Speicherbandbreite	DDR5-4800	DDR5-5600
Netzwerkdurchsatz	bis 200 Gbps	bis 300 Gbps
Preisvorteil vs. x86 (7. Gen)	ca. 20 %	ca. 20–25 %
Performance-Uplift vs. Vorgänger	Baseline	+30 % pro vCPU

Achten Sie darauf, dass Graviton4-Instanzen noch nicht in jeder Region verfügbar sind. Für eu-west-1, eu-central-1 und us-east-1 ist die Verfügbarkeit gut, in kleineren Regionen wie eu-south-2 oder ap-south-2 kann es zu Kapazitätsengpässen kommen – dann ist ein Fallback auf Graviton3 die pragmatische Wahl.

Wie viel spare ich mit einer Graviton Migration wirklich?

Der Listenpreisvorteil von 20 % ist nur der Anfang. In Kundenprojekten sehe ich regelmäßig Gesamteinsparungen zwischen 30 % und 45 %, weil Graviton meist auch ein Rightsizing-Trigger ist. Ein typisches Beispiel aus einem letzten Projekt: Ein Java-Spring-Boot-Cluster lief auf 40× m6i.2xlarge mit 8 vCPU/32 GB. Nach Migration auf m7g.2xlarge lag die CPU-Auslastung 15 % niedriger, weil G3 die JVM-Workload besser verarbeitet. Wir konnten auf m7g.xlarge (4 vCPU/16 GB) rightsizen – 60 Instanzen wurden zu 40 Instanzen der kleineren Klasse.

Die Rechnung: Vorher 40 × 0,4032 USD/h = 16,13 USD/h. Nachher 40 × 0,1610 USD/h = 6,44 USD/h. Das sind rund 60 % Ersparnis oder 84.900 USD pro Jahr in dieser einen Workload. Der Compute Optimizer liefert übrigens seit Anfang 2026 gemischte Empfehlungen – er zeigt Ihnen sowohl den x86-Rightsizing-Kandidaten als auch den Graviton-Umstieg im selben Report. Meine Empfehlung: Filtern Sie Compute-Optimizer-Empfehlungen nach "Migration effort: Low" und beginnen Sie dort. Wer Cost Allocation Tags konsequent nutzt, sieht den ROI pro Team im Cost Explorer innerhalb weniger Tage.

Ist Graviton mit x86 kompatibel?

Nein, Graviton ist ARM64 – x86-Binaries laufen nicht direkt. In der Praxis ist das aber selten ein Blocker, weil moderne Sprachen und Runtimes ARM64 seit Jahren nativ unterstützen. Der Aufwand hängt vom Stack ab:

Interpretiert (Python, Ruby, PHP, Node.js): Läuft in >95 % der Fälle ohne Anpassung. Vorsicht bei nativen Extensions – bcrypt, sharp, node-canvas, tensorflow.
JVM (Java, Kotlin, Scala): Vollständig unterstützt ab OpenJDK 11. Corretto von AWS ist für Graviton optimiert und mein Standard-Build für ARM.
Go: Ein GOARCH=arm64 go build, fertig. Cross-Compile-Story ist die beste im Ökosystem.
Rust: Ähnlich unproblematisch, cargo build --target aarch64-unknown-linux-gnu.
.NET: Ab .NET 6 nativ auf ARM64. .NET Framework (nicht Core) läuft NICHT auf Graviton.
C/C++: Muss neu kompiliert werden. Prüfen Sie SIMD-Code (SSE/AVX) – der muss auf NEON portiert werden.

Der Migrationsprozess in 6 Schritten

So gehe ich in einem typischen Enterprise-Projekt vor:

Inventar & Compute-Optimizer-Report ziehen: Aktivieren Sie den Compute Optimizer für alle Accounts und exportieren Sie die Empfehlungen. Filtern Sie auf "Recommended: Graviton" und "Effort: Low".
Dependency-Scan: Für Container-Workloads laufen Sie docker manifest inspect gegen alle Base-Images und prüfen, ob linux/arm64 im Manifest steht.
Test-Umgebung parallel aufbauen: Duplizieren Sie eine Auto-Scaling-Gruppe mit Graviton-Instanzen, aber ohne Traffic. Deployen Sie Ihre CI-Pipeline dorthin.
Load-Test mit realistischem Traffic: Nutzen Sie Locust oder k6 gegen die ARM-Version. Prüfen Sie p99-Latenz, nicht nur Durchschnitt.
Blue/Green-Cutover: Bei ALB-basierten Services wechseln Sie den Target-Group-Anteil über eine gewichtete Route-53-Policy oder ALB-Listener-Rules in 10-%-Schritten.
Alte Kapazität abbauen: Erst nach 48 Stunden stabiler ARM-Produktion die x86-ASG auf 0 skalieren und Reservations/SPs entsprechend anpassen.

Docker-Images für ARM64 bauen

Für Container-basierte Deployments ist das Bauen von Multi-Arch-Images der wichtigste Schritt. Nutzen Sie docker buildx mit QEMU-Emulation oder – deutlich schneller – einen nativen ARM-Builder in CodeBuild:

# buildspec.yml für CodeBuild mit ARM64-Runner
version: 0.2
phases:
  pre_build:
    commands:
      - aws ecr get-login-password --region eu-central-1 | docker login \
          --username AWS --password-stdin $ECR_REGISTRY
      - docker buildx create --use --name multiarch --driver docker-container
  build:
    commands:
      # Multi-Arch-Build: x86 und ARM64 in einem Manifest
      - docker buildx build \
          --platform linux/amd64,linux/arm64 \
          --tag $ECR_REGISTRY/api:$CODEBUILD_RESOLVED_SOURCE_VERSION \
          --tag $ECR_REGISTRY/api:latest \
          --push \
          .
  post_build:
    commands:
      - docker manifest inspect $ECR_REGISTRY/api:latest

Wichtig: Nutzen Sie in CodeBuild die neuen ARM_LARGE- oder ARM_2XLARGE-Compute-Types (Graviton-basiert) – die Build-Zeit halbiert sich gegenüber QEMU-Emulation auf x86-Runnern. Dokumentation dazu unter AWS CodeBuild Compute Types.

Managed Services: RDS, Lambda, ElastiCache auf Graviton

Der einfachste Weg zu Graviton-Ersparnis ist nicht EC2, sondern Managed Services – hier ist die Migration oft ein einzelnes CLI-Kommando:

# RDS auf Graviton umstellen (Downtime ca. 5-10 Minuten bei Multi-AZ)
aws rds modify-db-instance \
  --db-instance-identifier prod-postgres \
  --db-instance-class db.r7g.2xlarge \
  --apply-immediately

# Lambda-Function auf ARM64 umstellen (kein Downtime)
aws lambda update-function-configuration \
  --function-name my-api \
  --architectures arm64

# ElastiCache Redis auf Graviton
aws elasticache modify-replication-group \
  --replication-group-id prod-redis \
  --cache-node-type cache.r7g.large \
  --apply-immediately

Bei Lambda ist der Wechsel besonders lohnend: Sie sparen 20 % pro GB-Sekunde und haben bei den meisten Workloads (Node.js, Python, Java) messbar schnellere Cold Starts. Achtung nur bei Lambda Layers – wenn Sie native Binaries (z. B. sharp für Bildverarbeitung) einbetten, brauchen Sie den ARM64-Build des Layers. RDS/Aurora unterstützen Graviton für PostgreSQL 13+ und MySQL 8+; für ältere MySQL-Versionen bleibt nur x86.

Graviton mit Compute Savings Plans kombinieren

Das ist der Teil, der mich als Solutions Engineer am meisten begeistert: Compute Savings Plans sind instanzfamilien- und regionsagnostisch. Ihr bestehender Compute Savings Plan über 100 USD/h greift automatisch auf Graviton-Instanzen, sobald Sie migrieren. Sie müssen nichts kündigen, nichts neu committen. Für Details zum Unterschied siehe meinen Vergleich von Savings Plans und Reserved Instances.

Die Migrations-Reihenfolge, die ich empfehle: Erst auf Graviton umstellen, dann rightsizen (weil Graviton in vielen Workloads weniger vCPUs braucht), dann Savings Plan neu berechnen. Wenn Sie umgekehrt vorgehen, committen Sie sich auf zu viel Kapazität. Nutzen Sie den AWS Cost Explorer mit dem "Savings Plans Utilization"-Report, um die tatsächliche Auslastung nach Migration zu prüfen – 95 % Utilization ist das Ziel, alles darunter ist Over-Commitment.

Monitoring und Rollback-Strategie nach dem Cutover

Auch die technisch sauberste Graviton-Migration braucht eine belastbare Beobachtungsphase. In den ersten 72 Stunden nach dem Cutover würde ich vier Dashboards parallel im Blick behalten: CloudWatch für CPU/Memory/Netzwerk, Application-Level-Metriken (p50/p95/p99-Latenz pro Endpoint), Container-Insights bei EKS-basierten Deployments und – oft vergessen – die Fehlerraten der Downstream-Dienste. In einem Projekt mit einem großen deutschen Automobilkunden hatten wir alle CloudWatch-Metriken im grünen Bereich, aber die integrierten Zahlungsdienstleister lieferten 4 % mehr HTTP 500 zurück. Ursache war ein TLS-Handshake-Timeout, weil eine alte BoringSSL-Version im ARM-Build eine andere Cipher-Reihenfolge nutzte.

Für den Rollback empfehle ich, die alte x86-Auto-Scaling-Gruppe für mindestens 7 Tage auf desired-capacity=0, aber max-size=Baseline zu belassen. So können Sie im Zweifel innerhalb von 3–4 Minuten wieder komplett auf x86 hochziehen. Auf Kubernetes-Seite arbeite ich mit einem nodeSelector: kubernetes.io/arch: arm64 und einem entsprechenden Deployment-Label – Reverts sind dann ein einfacher Patch auf den Selector. Automatisieren Sie den Rollback-Trigger mit CloudWatch-Alarms auf p99-Latenz und HTTP-5xx-Rate, die eine Lambda-Funktion aufrufen. Nach einer Woche stabiler Produktion terminieren Sie die x86-Kapazität und passen den Savings Plan an – erst dann ist die Migration wirklich abgeschlossen.

Häufig gestellte Fragen

Wie viel Prozent spare ich mit einer Graviton Migration?

Realistisch 20–40 % gegenüber x86-Instanzen der gleichen Generation, in Kombination mit Rightsizing oft 50 %+. Der reine Listenpreisvorteil liegt bei rund 20–25 %, zusätzliche Ersparnis kommt aus höherer Performance pro vCPU.

Ist AWS Graviton mit x86-Software kompatibel?

Nein, Graviton nutzt die ARM64-Architektur, x86-Binaries laufen nicht nativ. Interpretierte Sprachen (Python, Node.js, PHP) und moderne JIT-Runtimes (Java, .NET Core, Go) sind aber ohne Anpassung kompatibel – nur native Bibliotheken müssen neu gebaut werden.

Welche EC2-Instanzen unterstützen Graviton?

Alle Instanzfamilien mit dem Suffix "g": M6g/M7g/M8g (General Purpose), C6g/C7g/C8g (Compute), R6g/R7g/R8g (Memory), X8g (High-Memory), I4g/I8g (Storage), T4g (Burstable). Insgesamt über 150 Instanztypen in 30+ Regionen.

Kann ich Docker-Images für Graviton einfach neu bauen?

Ja, mit docker buildx build --platform linux/amd64,linux/arm64 erzeugen Sie ein Multi-Arch-Manifest, das auf beiden Architekturen läuft. Prüfen Sie dabei alle Base-Images (Alpine, Debian-slim, Distroless unterstützen ARM64 seit Jahren).

Lohnt sich Graviton für Lambda-Funktionen?

In fast allen Fällen ja: 20 % günstigerer Preis pro GB-Sekunde und messbar bessere Performance bei Node.js, Python und Java. Ausnahme sind Lambdas mit nativen Binaries in Layern – hier muss der ARM64-Build des Layers vorhanden sein.