AWS Graviton Migratie: 40% Besparen (20…

Bijgewerkt: 13 juli 2026

Een AWS Graviton migratie levert doorgaans 20–40% lagere EC2 compute kosten op ten opzichte van vergelijkbare x86 instances, zonder verlies aan prestaties voor de meeste moderne workloads. In dit artikel deel ik hoe ik multi-cloud teams begeleid bij een gecontroleerde overstap van Intel/AMD naar ARM64, welke workloads (.NET, Java, Node.js, Python, containers) direct draaien op Graviton3, Graviton4 en de nieuwe Graviton5, en hoe je de besparing stapelt met Compute Savings Plans en Spot Instances. Inclusief benchmark stappen, Karpenter configuratie en een kant-en-klare Terraform snippet.

Graviton3 en Graviton4 leveren volgens AWS tot 40% betere prijs-prestatie dan vergelijkbare x86 instances (M7g, C7g, R7g, R8g families).
Migratie is voor 80% van moderne stacks een kwestie van architectuur=arm64 toevoegen aan Docker builds en instance types wisselen. ARM-incompatibele afhankelijkheden zijn zeldzaam geworden in 2026.
Lambda functies op arm64 kosten circa 20% minder per GB-seconde en draaien vaak sneller. Dubbel voordeel op je factuur.
Compute Savings Plans stapelen bovenop de Graviton korting: 1 jaar no-upfront + Graviton = 45–55% totaal besparing op steady-state workloads.
In EKS gebruik je Karpenter met een mixed-architecture NodePool om zonder downtime van x86 naar arm64 te schuiven op basis van workload compatibiliteit.
Test altijd op numeriek gevoelige workloads (ML inference, floating point pipelines). Resultaten zijn identiek, maar rounding kan minimaal verschillen tussen architecturen.

Wat is AWS Graviton en waarom bespaart het geld?

AWS Graviton is de familie ARM-processoren die Amazon zelf ontwerpt, gebouwd op Neoverse cores van Arm Holdings. Doordat AWS de silicon zelf produceert (via TSMC) omzeilt het de marge die Intel en AMD op hun serverchips rekenen, en die besparing wordt doorgegeven aan de klant in de vorm van lagere on-demand prijzen. In 2026 is Graviton3 de mainstream keuze (M7g, C7g, R7g). Graviton4 (M8g, C8g, R8g) is beschikbaar in de meeste EU regio's, en Graviton5 begint uit te rollen in us-east-1 en eu-west-1 voor early adopters.

De besparing komt uit drie hoeken tegelijk: (1) een lagere sticker prijs per vCPU-uur ten opzichte van gelijkwaardige M7i of C7i instances, (2) hogere prestaties per watt waardoor je bij right-sizing vaak een kleinere instance kunt kiezen, en (3) stapelbaarheid met bestaande Savings Plans. Voor een gemiddelde SaaS backend met steady-state Node.js of Java containers zie ik in de praktijk 25–35% netto reductie op de EC2 regel van de factuur, zonder architectuur wijzigingen. Voor meer context over right-sizing beslissingen die je vóór de migratie moet maken, zie mijn AWS Compute Optimizer gids. De officiële specificaties per generatie staan op de AWS Graviton productpagina.

Hoeveel goedkoper is Graviton dan x86 in 2026?

De prijsverschillen tussen ARM en x86 zijn concreet. Hier een side-by-side tabel op basis van us-east-1 on-demand tarieven per juli 2026 voor vergelijkbare instance types:

Instance type	vCPU / RAM	Prijs/uur ($)	Besparing vs x86	Typische workload
m7i.large (Intel)	2 / 8 GB	0,1008	referentie	Algemene web/API
m7a.large (AMD)	2 / 8 GB	0,1080	-7% (duurder)	Algemene web/API
m7g.large (Graviton3)	2 / 8 GB	0,0816	19% goedkoper	Algemene web/API
m8g.large (Graviton4)	2 / 8 GB	0,0864	14% goedkoper + ~30% sneller	Algemene web/API
c7i.xlarge	4 / 8 GB	0,1785	referentie	Compute-intensief
c7g.xlarge	4 / 8 GB	0,1445	19% goedkoper	Compute-intensief
r7i.xlarge	4 / 32 GB	0,2646	referentie	Memory-intensief (Redis, JVM)
r7g.xlarge	4 / 32 GB	0,2142	19% goedkoper	Memory-intensief (Redis, JVM)

De on-demand korting alleen al is 19% voor Graviton3. Combineer dat met het feit dat veel workloads circa 15–20% sneller zijn op Graviton (minder cores nodig voor dezelfde throughput) en je zit al gauw op 30% netto. Voor Kubernetes teams die daarnaast Compute Savings Plans gebruiken loopt het totale voordeel op naar 45–55%.

Welke workloads draaien op Graviton (ARM64)?

In 2026 is de vraag "werkt mijn software op ARM?" bijna altijd "ja". Eerlijk gezegd was dit twee jaar geleden nog een echt zorgpunt, maar de compatibiliteit is inmiddels vrijwel volledig. De officiële AWS Graviton Getting Started repo op GitHub houdt een levende compatibiliteitslijst bij. Overzicht van veelgebruikte stacks:

Node.js, Python, Ruby, Go: Alle officiële binaries hebben arm64 releases. Multi-arch Docker images (linux/amd64,linux/arm64) zijn de norm sinds Node 18 en Python 3.11.
Java (JVM): OpenJDK 17, 21 en 25 draaien native op arm64 met dezelfde JIT prestaties als x86. Corretto en Temurin bieden officiële ARM builds.
.NET 8/9: Volledig ondersteund op arm64 Linux. Volgens de AWS prescriptive guidance voor .NET op Graviton zijn besparingen tot 45% mogelijk.
Databases: PostgreSQL, MySQL, MariaDB, Redis, MongoDB, Cassandra hebben allemaal officiële arm64 builds. RDS en Aurora bieden Graviton opties standaard.
Containers en Kubernetes: EKS, ECR, Fargate en Karpenter zijn allemaal arm64 compatible. Sidecars zoals Istio, Envoy en Linkerd hebben multi-arch images.
Observability: Prometheus, Grafana, Loki, OpenTelemetry Collector, Datadog agent en New Relic hebben arm64 releases.

Wat werkt niet op Graviton in 2026: bepaalde legacy Windows Server workloads (Windows on ARM is beperkt), oudere Oracle Database versies (11g, 12c), en propriëtaire ISV software zonder ARM release. Voor .NET Framework (dus niet .NET Core/5+) is er geen ARM ondersteuning; die workloads moeten eerst naar .NET 8 gemigreerd worden.

Stap-voor-stap: migreren naar Graviton zonder downtime

Ik hanteer een vijf-stappen aanpak die ik in het afgelopen jaar bij meerdere multi-cloud teams heb toegepast. De volledige cyclus per service duurt gewoonlijk 2–4 uur en levert direct meetbare besparing.

Stap 1: Compatibiliteit checken

Draai eerst een lokale test met een multi-arch Docker build. Op een moderne Docker Desktop of Colima setup:

# Bouw multi-arch image met buildx
docker buildx create --name multiarch --use
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag ghcr.io/mycompany/api:multi-arch \
  --push .

# Verifieer dat beide varianten aanwezig zijn
docker buildx imagetools inspect ghcr.io/mycompany/api:multi-arch

Stap 2: Benchmark op één Graviton instance

Start een enkele m7g of c7g instance naast je bestaande productie en stuur er 10% van het verkeer naartoe via een Application Load Balancer weighted target group:

# CLI voorbeeld: gewogen target groups
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:eu-west-1:...:listener/... \
  --default-actions Type=forward,ForwardConfig='{
    "TargetGroups":[
      {"TargetGroupArn":"arn:aws:...:targetgroup/x86-tg","Weight":90},
      {"TargetGroupArn":"arn:aws:...:targetgroup/arm-tg","Weight":10}
    ]
  }'

Monitor p50/p95/p99 latency en foutpercentages 24 uur. Als de metrics gelijk of beter zijn, schuif je door naar 50%, en daarna 100%.

Stap 3: CI/CD pijplijn aanpassen

Voeg arm64 buildstappen toe. In GitHub Actions is dit één regel extra:

- uses: docker/build-push-action@v6
  with:
    platforms: linux/amd64,linux/arm64
    push: true
    tags: ghcr.io/mycompany/api:${{ github.sha }}

Stap 4: Terraform / IaC updaten

Wissel instance_type in je Auto Scaling Group of ECS/EKS node group. Belangrijk detail: vergeet niet ook de AMI om te zetten naar de arm64 variant, anders faalt de instance boot met een cryptische error over kernel format. Ik hit deze precies op mijn eerste rollout een jaar geleden, en het kostte een halve middag om het te snappen.

resource "aws_launch_template" "api" {
  name_prefix   = "api-arm-"
  image_id      = data.aws_ami.al2023_arm64.id   # ARM64 AMI!
  instance_type = "m7g.large"                    # was m7i.large

  # De rest blijft identiek
  vpc_security_group_ids = [aws_security_group.api.id]
  iam_instance_profile { name = aws_iam_instance_profile.api.name }
}

data "aws_ami" "al2023_arm64" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["al2023-ami-*-arm64"]
  }
}

Stap 5: Rollout monitoren met CloudWatch

Zet CloudWatch alarms op CPUUtilization, MemoryUtilization en application error rate. Bij een afwijking > 5% ten opzichte van baseline rol je automatisch terug via een weighted target group swap.

Lambda functies overzetten naar arm64

Lambda migratie is het laaghangend fruit van Graviton: één parameter wijziging, geen infrastructuurwerk. AWS Lambda arm64 kost per GB-seconde circa 20% minder dan x86_64 en start vaak 10–15% sneller op (cold start). Voor een functie met 30 miljoen invocaties per maand, 500ms duur en 512MB geheugen scheelt dat concreet ~$25 per maand per functie. Schaal dat naar een grote applicatie met honderden functies en de besparing loopt in tienduizenden per jaar.

In Terraform:

resource "aws_lambda_function" "processor" {
  function_name = "invoice-processor"
  role          = aws_iam_role.lambda.arn
  handler       = "index.handler"
  runtime       = "nodejs22.x"
  architectures = ["arm64"]   # was ["x86_64"]

  filename         = data.archive_file.zip.output_path
  source_code_hash = data.archive_file.zip.output_base64sha256
}

Belangrijkste caveat: als je Lambda layers met native binaries (bijv. sharp voor image processing of bcrypt) publiceert, moeten deze óók voor arm64 gebouwd zijn. Gebruik npm install --arch=arm64 --platform=linux in een arm64 build container (bijv. via docker buildx). Honestly, ik ben hier bij een klant tegenaan gelopen: een sharp-based image resizer viel op zijn gezicht met een Runtime.ImportModuleError in productie. Dat kostte drie kwartier van doorlooptijd voordat we de oorzaak vonden.

EKS clusters migreren met Karpenter

Voor Kubernetes op AWS is Karpenter in 2026 de facto standaard voor node provisioning. Het legacy Cluster Autoscaler wordt door AWS actief gedeprecateerd voor nieuwe clusters. Karpenter kan een gemengde ARM/x86 pool beheren en workloads plaatsen op basis van compatibiliteit. Combineer dit met mijn Kubernetes kostenoptimalisatie gids voor de complete FinOps aanpak.

Hier een voorbeeld NodePool met Graviton3 en x86 fallback:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: mixed-arch
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64", "amd64"]
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m7g", "c7g", "m7i", "c7i"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
  limits:
    cpu: 1000
    memory: 4000Gi

Karpenter kiest automatisch de goedkoopste combinatie die aan de pod scheduling constraints voldoet. Voeg per deployment een nodeSelector of affinity toe voor workloads die specifiek ARM of x86 vereisen:

spec:
  template:
    spec:
      nodeSelector:
        kubernetes.io/arch: arm64   # forceer arm64
      containers:
      - name: api
        image: ghcr.io/mycompany/api:multi-arch

Savings Plans en Spot stapelen op Graviton

De grote fout die ik vaak zie: teams migreren naar Graviton en denken "klaar". In werkelijkheid stapel je pas maximaal voordeel als je drie lagen combineert. Onderstaande tabel toont een gecombineerd besparingsmodel voor een steady-state workload van 100 m7i.large equivalents (20.000 vCPU-uren/maand):

Configuratie	Prijs/maand	Cumulatieve besparing
m7i.large on-demand (baseline)	$7.258	0%
+ 1-jr Compute Savings Plan (no upfront)	$5.078	30%
Wissel naar m7g.large + Savings Plan	$4.113	43%
+ 3-jr Savings Plan (all upfront)	$3.484	52%
+ Karpenter met 40% Spot Graviton	$2.612	64%

Voor batch/CI workloads waar interruptie acceptabel is, kun je naar 70–80% besparing gaan door volledig op Graviton Spot te draaien met de juiste checkpoint logica. De onderbreking rates voor c7g Spot in EU regio's liggen doorgaans onder de 5% per maand, vergelijkbaar met (of beter dan) x86 Spot pools, omdat de vraag naar ARM capaciteit lager is dan het aanbod.

Valkuilen en compatibiliteitsissues

Ondanks de brede ondersteuning zijn er valkuilen die ik iedere migratie zie terugkomen. Zo, laten we ze op een rijtje zetten.

Native afhankelijkheden zonder ARM wheel

Python packages als numpy, pandas en scipy hebben tegenwoordig arm64 wheels. Maar niche packages (bijv. propriëtaire crypto libraries of legacy fintech SDK's) missen soms een linux/arm64 wheel. Los dit op door in je Dockerfile een compile fallback te installeren (build-essential, gfortran), of bespreek met de vendor of ze een arm64 build kunnen leveren.

Docker base images

Als je een FROM node:22-alpine gebruikt, is dat automatisch multi-arch. Custom base images van interne registries zijn echter vaak alleen amd64. Bouw ze opnieuw met buildx voor beide platforms voordat je downstream services migreert.

Numerieke reproduceerbaarheid

Voor machine learning inference of financiële berekeningen: floating point resultaten kunnen minimaal verschillen tussen ARM en x86 door verschillende SIMD instructiesets. Dit is IEEE 754 compliant en meestal irrelevant, maar test snapshot-based unit tests grondig. Je krijgt mogelijk failures op de laatste 2 decimalen.

Monitoring gap tijdens rolling migratie

Als je met weighted target groups migreert, aggregeer je metrics per target group en niet per instance type. Zonder dimensionele CloudWatch metrics op InstanceType zie je niet dat één architectuur ineens slechter presteert. Voeg ec2 InstanceType als custom dimension toe aan je APM tags.

Veelgestelde vragen

Hoeveel bespaar ik precies met AWS Graviton migratie?

Reken op 19–20% korting op de sticker prijs plus 10–15% performance-per-euro voordeel, samen 25–35% netto besparing voor de meeste web/API/database workloads. Combineer met een 1-jaars Compute Savings Plan en je totale besparing loopt op naar 45–55%.

Is Graviton sneller dan Intel Xeon of AMD EPYC?

Voor de meeste web-, API-, JVM- en containerworkloads levert Graviton3 gelijkwaardige of 15–25% betere throughput dan vergelijkbare Intel/AMD instances. Voor specifieke HPC of legacy x86-geoptimaliseerde workloads kan x86 nog steeds sneller zijn, dus altijd zelf benchmarken.

Kan ik Windows Server op Graviton draaien?

Nee, AWS biedt Windows Server niet aan op Graviton instances. Voor Windows workloads blijf je op x86 (M7i, C7i). Wel kun je .NET 8+ Linux containers op Graviton draaien. Voor pure .NET workloads is dat vaak de goedkopere route.

Werken bestaande Docker images op Graviton?

Alleen als de image een linux/arm64 manifest bevat. Bouw je image opnieuw met docker buildx build --platform linux/amd64,linux/arm64 voor multi-architecture support. Officiële images op Docker Hub (nginx, postgres, node, python) zijn al multi-arch.

Verlies ik mijn Reserved Instances of Savings Plans bij migratie?

Compute Savings Plans en flexible Convertible RI's blijven van toepassing, want die dekken alle instance families inclusief Graviton, Fargate en Lambda. EC2 Instance Savings Plans en Standard RI's zijn familie-specifiek, en die verlies je bij een architectuurwissel. Migreer naar Compute Savings Plans voordat je de Graviton rollout start.

Hoe lang duurt een Graviton migratie voor een gemiddelde applicatie?

Voor een moderne cloud-native applicatie (containers + IaC + CI/CD): 1 sprint per service inclusief tests en canary rollout. Grotere organisaties migreren typisch 5–10 services per kwartaal en zijn binnen 12 maanden volledig ARM voor stateless workloads.