Choisir et dimensionner une machine cloud

Trois décisions prises au moment de créer une machine vous suivront pendant des mois : le type, l'architecture du processeur et la taille. Cette leçon explique ce que vous achetez réellement derrière un nom comme c7g.xlarge, pourquoi une machine à processeur ARM coûte environ 19 % de moins à gabarit égal, et comment dimensionner à partir de mesures plutôt que par précaution.

Ce que vous allez apprendre

• Décoder un nom de type d'instance et savoir ce qu'il promet.
• Comparer ARM et x86 sur le prix réel et sur la compatibilité de votre pile.
• Dimensionner à partir de mesures, plutôt que par précaution.
• Reconnaître la ressource qui sature en premier, qui n'est presque jamais celle qu'on croit.

Ce que vous achetez vraiment

Une instance est le plus souvent une capacité virtualisée sur une infrastructure mutualisée, et non une machine à vous. La nuance explique la plupart des surprises de performance : vos ressources sont garanties dans une certaine mesure, et le voisinage existe.

Le plus souvent, car des offres dédiées existent chez tous les grands fournisseurs : hôte dédié, instance dédiée, et jusqu'au serveur physique sans hyperviseur (le logiciel qui partage un serveur entre plusieurs machines virtuelles). Elles coûtent plus cher et servent des besoins précis, souvent de conformité ou de licence.

Concrètement, vous réservez trois choses qui se facturent séparément.

Ce que vous réservez	Facturé	Continue après extinction
Le calcul (processeur et mémoire)	à la seconde ou à l'heure	non
Le disque attaché	au gigaoctet et par mois	oui, tant qu'il existe
L'adresse publique réservée	à l'heure, souvent même inutilisée	oui

Glissez pour voir

Cette troisième colonne est la source de la mauvaise surprise la plus courante. On éteint les machines de test le vendredi, on croit avoir arrêté la dépense, et le lundi la facture a continué de courir sur les disques et les adresses. Éteindre suspend le calcul ; le reste continue tant que ces ressources existent.

Elles se traitent d'ailleurs séparément : un volume se détache et se supprime sans toucher à la machine, une adresse réservée se libère de la même façon. C'est ce découplage qui permet le ménage décrit dans gouvernance et coûts.

Lire un type d'instance

Les noms varient d'un fournisseur à l'autre, et la plupart encodent les mêmes informations : une famille, une génération, une taille. Une fois le principe compris, la plupart des grilles tarifaires deviennent lisibles, même si la convention exacte se vérifie toujours dans la documentation du fournisseur.

AWS

m7i.xlarge se lit en trois morceaux : m pour la famille généraliste, 7i pour la génération et le fabricant du processeur (ici Intel), xlarge pour la taille. Les familles courantes sont t (économique, à crédits), m (généraliste), c (calcul), r (mémoire), i (stockage rapide), g et p (accélérateurs graphiques).

Azure

Standard_D4s_v5 : D pour la famille généraliste, 4 pour le nombre de cœurs, s pour le stockage premium, v5 pour la génération. Les familles suivent la même logique : B (économique, à crédits), D (généraliste), F (calcul), E (mémoire), N (accélérateurs).

Google Cloud

n2-standard-4 : n2 pour la génération, standard pour le profil, 4 pour le nombre de processeurs virtuels. Les profils sont highcpu, standard et highmem, ce qui rend le rapport mémoire par cœur explicite dans le nom, là où les autres fournisseurs le laissent deviner.

OUTSCALE

Le format est le plus explicite de tous : tinav6.c4r8p2 annonce la génération v6, 4 cœurs, 8 Go de mémoire et le flag de performance p2. Vous composez la machine plutôt que de choisir dans un catalogue, ce qui est traité en détail dans Instances TINA et sizing.

Le rapport mémoire par cœur est le vrai critère de choix. Les ordres de grandeur courants tournent autour de 2 Go par cœur sur une famille calcul, 4 Go sur une généraliste, 8 Go ou plus sur une famille mémoire, avec des écarts d'un fournisseur à l'autre qu'il faut vérifier sur la grille du jour. Choisir la mauvaise famille revient à payer des cœurs pour obtenir de la mémoire, ou l'inverse.

Les instances à crédits, et le mur du troisième jour

Les familles économiques (t chez AWS, B chez Azure) fonctionnent avec des crédits de processeur : la machine accumule des crédits quand elle est peu sollicitée et les dépense quand elle travaille. Tant qu'il reste des crédits, les performances sont normales.

Une fois les crédits épuisés, la machine est bridée, parfois à une fraction de sa puissance affichée. Le symptôme est déroutant : tout va bien pendant deux jours, puis l'application devient lente sans qu'aucune métrique de charge n'explique pourquoi.

Ces familles conviennent aux charges vraiment intermittentes, comme un serveur de développement. Pour une charge soutenue, elles coûtent moins cher et rendent moins, ce qui n'est pas une bonne affaire.

ARM ou x86 : lequel choisir en 2026 ?

À gabarit égal, une machine à processeur ARM coûte environ 19 % de moins que son équivalent x86 chez le même fournisseur. C'est l'arbitrage de dimensionnement le plus rentable du moment, et il ne demande souvent aucune modification de code.

Le tableau ci-dessous compare des instances de même génération et de même gabarit, 4 vCPU et même famille d'usage, sur la grille publique d'AWS pour la région de Paris, relevée le 10 septembre 2026.

Instance	Processeur	Prix horaire	Par mois (730 h)
c7g.xlarge	ARM (Graviton3)	0,1717 USD	125,34 USD
c7i.xlarge	x86 (Intel Xeon)	0,2121 USD	154,83 USD
m7g.xlarge	ARM (Graviton3)	0,1904 USD	138,99 USD
m7i.xlarge	x86 (Intel Xeon)	0,2352 USD	171,70 USD

Glissez pour voir

L'écart de tarif n'est d'ailleurs que la moitié de l'histoire : à génération comparable, ces processeurs offrent souvent un meilleur rapport performance/watt, ce qui améliore aussi le coût par requête servie.

Ce qui empêche encore de basculer

La question n'est plus le prix, c'est la compatibilité de votre pile. Trois points à vérifier avant de migrer, dans cet ordre :

• Les images de conteneurs. Une image construite pour amd64 ne démarre pas sur ARM. La parade est le manifeste multi-architecture, qui embarque les deux variantes sous un même nom : votre chaîne de construction doit produire linux/amd64 et linux/arm64.
• Les dépendances binaires. Un langage interprété ou compilé à la volée passe généralement sans effort. Ce qui coince, ce sont les extensions natives compilées, les pilotes propriétaires et les agents fournis en binaire par un éditeur qui ne publie que du x86.
• Les licences logicielles. Certains éditeurs facturent différemment, ou ne supportent tout simplement pas l'architecture.

Comment tester sans y passer la semaine

Prenez la charge la moins couplée de votre système, typiquement un travailleur asynchrone ou un service sans état, et faites-la tourner en parallèle sur les deux architectures pendant une semaine. Vous obtenez une réponse mesurée sur votre code plutôt qu'une extrapolation, et l'échec éventuel n'a aucune conséquence de production.

Si votre chaîne de construction produit déjà des images multi-architecture, le coût de l'essai est proche de zéro.

Dimensionner sans surdimensionner

Le surdimensionnement par précaution est le premier gisement d'économies de n'importe quelle facture cloud, et il vient d'un réflexe compréhensible : on provisionne comme au temps du matériel, où se tromper coûtait un bon de commande et six semaines.

Dans le cloud, changer de taille prend un redémarrage. La bonne méthode inverse donc l'ancienne :

1. Partir petit, volontairement

   Prenez la taille en dessous de votre intuition. Si elle suffit, vous avez économisé la moitié du coût de calcul, tous les mois.

2. Mesurer sur une durée qui a du sens

   Une semaine complète au minimum, pour attraper le lundi matin et le batch du week-end. Regardez le 95e centile (la valeur sous laquelle se situent 95 % des mesures) plutôt que la moyenne : la moyenne masque les pointes, le maximum est trompeur car un pic d'une seconde ne justifie pas de doubler la machine à l'année.

3. Décider sur la ressource qui sature en premier

   C'est souvent la mémoire, plus rarement le processeur. Une machine dont le processeur plafonne à 30 % et la mémoire à 90 % ne demande pas une taille au-dessus : elle demande une famille mémoire.

4. Refaire l'exercice tous les trimestres

   Les usages dérivent. Un redimensionnement trimestriel est l'action de maîtrise des coûts la plus rentable, parce qu'elle ne dégrade rien.

Un repère pour déclencher l'examen, et non un seuil universel : une machine dont le processeur reste sous 30 % au 95e centile pendant une semaine mérite d'être regardée de près. Ce n'est pas une règle, c'est le point de départ d'un test : descendez d'un cran, mesurez à nouveau, et gardez la taille qui tient la charge réelle.

À retenir

• Un nom de type se lit en trois parties : la famille, la génération et la taille.
• ARM coûte moins cher à gabarit égal, à condition que votre pile soit compatible ; l'essai coûte presque rien.
• Partez petit et mesurez une semaine au 95e centile avant de décider.
• La ressource qui sature en premier est souvent la mémoire, d'où le choix d'une famille mémoire plutôt que d'une taille au-dessus.
• Refaites l'exercice chaque trimestre : les usages dérivent.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →