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
Section intitulée « 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
Section intitulée « 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. 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 |
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
Section intitulée « 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.
m7i.xlarge se lit en trois morceaux : m pour la famille généraliste,
7i pour la génération et le fondeur, 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).
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).
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.
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.
ARM ou x86 : lequel choisir en 2026 ?
Section intitulée « 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 |
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
Section intitulée « 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
amd64ne 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 produirelinux/amd64etlinux/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.
Dimensionner sans surdimensionner
Section intitulée « 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 :
-
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.
-
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 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.
-
Décider sur la ressource qui sature en premier
C'est presque toujours la mémoire, 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.
-
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.