Graviton : migrer ses workloads ARM sans casse

Graviton n’est plus une option expérimentale. Quatre générations de puces plus tard, AWS pousse activement ses clients vers l’ARM — et les chiffres justifient l’effort de migration. Le problème n’est pas de savoir si Graviton fait économiser de l’argent (c’est acquis), mais de savoir où ça casse en pratique, et comment migrer sans y laisser une nuit blanche.

Cet article décrit la méthode que nous appliquons en mission Distribuée : évaluer, chiffrer, migrer par étapes, sans surprise en production.

Pourquoi Graviton, et pourquoi maintenant

Graviton3 et Graviton4 tournent 10 à 19 % moins cher à l’heure que leurs équivalents Intel/AMD, à performance égale ou supérieure. Graviton4, disponible en instances EC2 depuis septembre 2024, apporte jusqu’à 30 % de performance en plus par rapport à Graviton3, pour un rapport prix/performance amélioré de 40 %. Sur des cas réels documentés, les écarts vont de 20 à 47 % de coût compute en moins — Pinterest a par exemple annoncé 47 % de réduction sur une charge de travail clé après migration.

Concrètement, sur des instances comparables en on-demand (hors remise régionale) :

Soit environ 19 % d’écart, avant même de compter le gain de performance qui permet souvent de redimensionner à la baisse. Sur Lambda, l’écart est officiel et fixe : les fonctions arm64 facturent 20 % de moins à la durée d’exécution que x86_64 (0,0000133334 $/Go-s contre 0,0000166667 $/Go-s), à quoi s’ajoute jusqu’à 34 % de meilleur rapport prix/performance selon AWS. Sur RDS, Graviton2 a apporté jusqu’à 52 % d’amélioration prix/performance sur les moteurs open source par rapport aux instances Intel équivalentes, et Graviton3 ajoute encore 27 % par rapport à Graviton2 sur les mêmes bases de données.

Ces chiffres sont vendeurs. Ils ne disent rien du travail réel : la bascule d’architecture CPU touche tout ce qui compile du code natif.

Ce qu’on gagne vraiment, service par service

• EC2 : le gain immédiat est le tarif horaire (10-19 %). Le gain secondaire, souvent plus gros, vient du right-sizing rendu possible par le meilleur rapport perf/vCPU — beaucoup d’équipes migrent un m7i.xlarge vers un m7g.large sans perte de capacité.
• Lambda : gain fixe et sans risque de calcul, 20 % sur la durée. C’est le service où la migration Graviton a le meilleur ratio effort/gain, car il n’y a ni instance à redimensionner ni cluster à orchestrer.
• RDS / Aurora : gains les plus élevés en cumulé (jusqu’à 52 % vs x86 sur Graviton2, +27 % avec Graviton3), mais la bascule impose un redémarrage de l’instance (ou un failover pour Multi-AZ) — à planifier en fenêtre de maintenance.
• EKS / ECS : gains identiques à EC2 côté compute, mais la complexité se déplace vers les images de conteneurs et les DaemonSets (voir plus bas).

Méthode d’évaluation avant de migrer

Ne migrez jamais à l’aveugle. La séquence que nous suivons :

1. Inventaire des dépendances natives. Toute librairie avec extension C (Python numpy, pandas, cryptography compilées, modules Node.js natifs, binaires Go/Rust déjà cross-compilés) doit être vérifiée pour la disponibilité d’un wheel/paquet arm64. Certaines librairies de niche (ex. Fiona pour la géospatiale) n’ont historiquement pas de build ARM — mieux vaut le savoir avant de migrer que pendant l’incident.
2. AWS Compute Optimizer. Il identifie déjà les instances éligibles à une bascule Graviton avec l’économie estimée :

aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].recommendationOptions[?instanceType && contains(instanceType, `g.`)].[instanceType,savingsOpportunity.savingsOpportunityPercentage]' \
  --output table

3. Benchmark applicatif réel, pas seulement synthétique. Un test de charge (k6, Locust) sur un environnement de staging basculé en Graviton donne la vraie mesure — la théorie CPU ne remplace pas un profil de latence P99.
4. Vérification Windows / AVX-512. Windows Server ne tourne pas sur Graviton (architecture ARM uniquement). Tout ce qui dépend d’instructions x86 spécifiques (AVX-512, notamment certains workloads de calcul scientifique ou de chiffrement optimisé) reste sur x86.

Les pièges qui cassent une migration Graviton

C’est la partie que les articles marketing AWS omettent.

Le build multi-architecture Docker est le piège n°1. Contrairement à Go, Python et .NET ne savent pas cross-compiler nativement. Construire des images multi-arch avec QEMU sous Buildx sans cache dédié peut multiplier le temps de build par 5. La solution qui tient dans la durée : des runners CI natifs ARM (GitHub Actions propose des runners arm64 hébergés, CodeBuild aussi), pas de l’émulation QEMU en continu.

Chaque sidecar compte, sur Kubernetes. Un seul DaemonSet, agent de monitoring ou scanner de sécurité qui n’existe qu’en image x86 empêche purement et simplement le scheduling des pods sur les nœuds Graviton. Avant de créer un node group arm64, auditez tous les DaemonSets du cluster, pas seulement l’application.

Les Savings Plans et RI existants ne se transfèrent pas automatiquement. Un Compute Savings Plan couvre n’importe quelle famille d’instance, mais un Reserved Instance EC2 est lié à une famille et une architecture précises. Si vous avez des RI x86 en cours, la migration Graviton laisse ces RI sous-utilisés jusqu’à leur expiration — à factoriser dans le calcul de ROI.

Windows et AVX-512 : pas de contournement. Ne perdez pas de temps à chercher une solution de portage — ces charges restent sur x86 par construction.

Migrer sans casse : le pattern de bascule

Le principe est identique à toute migration d’infrastructure à risque : canary, mesure, généralisation.

Sur EC2/ASG : utilisez une Mixed Instances Policy pour introduire une fraction Graviton dans un Auto Scaling Group existant, à côté des instances x86, avant la bascule complète.

resource "aws_autoscaling_group" "app" {
  # ...
  mixed_instances_policy {
    instances_distribution {
      on_demand_percentage_above_base_capacity = 100
    }
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.app.id
      }
      override {
        instance_type = "m7i.large"
      }
      override {
        instance_type = "m7g.large"
      }
    }
  }
}

Sur EKS : créez un node group arm64 séparé avec un taint dédié, déployez une fraction du déploiement dessus via nodeSelector/tolerations, mesurez 7 jours, puis augmentez progressivement la proportion de réplicas.

Sur Lambda : le changement est le plus simple du lot — bascule de l’architecture dans la configuration de la fonction, republication, test en staging, puis déploiement en prod. Aucune raison de ne pas le faire pour toute fonction sans dépendance native non résolue.

Dans tous les cas, la règle reste la même que pour toute optimisation FinOps : une seule variable à la fois, mesure sur 7 jours minimum avant de généraliser, rollback documenté (retour à la version de launch template ou de node group précédente).

Le résultat empilé

Sur une facture compute de 10 000 €/mois répartie entre EC2, Lambda et RDS, un passage Graviton bien exécuté — sans changement de comportement applicatif — ramène typiquement 15 à 25 % d’économie immédiate, avant même le right-sizing rendu possible par le gain de performance.

Conclusion

Graviton n’est pas un pari : c’est une migration d’architecture CPU avec un ROI documenté et mesurable. Le risque n’est pas dans le principe, il est dans l’exécution — dépendances natives non vérifiées, pipelines CI mal préparés, DaemonSets oubliés. La méthode qui fonctionne est celle qu’on applique à toute migration d’infrastructure : cartographier avant de bouger, migrer par canary, mesurer avant de généraliser.

Si vous avez plus de 20 instances EC2 ou un cluster EKS/ECS de taille significative encore 100 % x86, il y a très probablement 15 à 25 % d’économie compute qui dort dans votre compte. Démarrons une évaluation Graviton.