Aller au contenu

AWS Mis à jour le 2026-09-25

Choisir un type d'instance EC2 en 2026 : les familles décodées (m, c, r, t, g)

Apprenez à choisir un type d'instance EC2 en lisant les lettres de famille m, c, r, t et g et les suffixes qui les suivent. Vous repartirez avec un chemin de décision simple qui commence petit et vous évite de payer pour de la capacité inutilisée.

Ce guide aide les développeurs et les petites équipes à choisir un type d’instance Amazon EC2 (Elastic Compute Cloud, le service de serveurs virtuels d’AWS) sans y aller à l’aveuglette. AWS propose des centaines de types aux noms comme m8g.large ou r7i.2xlarge, et un mauvais choix vous fait payer de la capacité qui dort ou manquer de ressources quand la charge augmente. La réponse courte : partez avec la famille m d’usage général de génération courante sur Graviton, le processeur ARM conçu par AWS (m8g au moment d’écrire ces lignes, m7g largement disponible). Mesurez pendant un bout de temps, puis passez à c pour le travail gourmand en CPU ou à r pour le travail gourmand en mémoire seulement quand les chiffres montrent un déséquilibre. À la fin, vous saurez décoder n’importe quel nom d’instance et reconnaître quand la famille t, à performance extensible, ou la famille g, équipée d’un GPU, vaut la peine.

Ce que vous décidez

Un nom de type comme m7g.large se lit ainsi : famille m, génération 7, g pour Graviton (les processeurs ARM d’AWS), taille large. Vous choisissez trois choses à la fois — le ratio de ressources, le processeur et l’échelle — et ce sont des décisions séparables.

Les familles :

  • m — usage général. Environ 4 Gio de mémoire par vCPU. Le bon défaut pour les applications web, les API, les serveurs applicatifs et tout ce qui n’est pas profilé. Dans le doute, m.
  • c — optimisé calcul. Environ 2 Gio par vCPU, taillé pour le travail intensif en CPU : encodage, fermes de compilation, serveurs de jeu, étages applicatifs à haut débit limités par le CPU avec des ensembles de travail modestes.
  • r — optimisé mémoire. Environ 8 Gio par vCPU : bases de données, caches en mémoire, analytique, JVM à gros tas. (Les familles x et z poussent plus loin pour les cas extrêmes comme SAP HANA.)
  • t — usage général à rafale. Même ratio que m mais une fraction de CPU avec rafales à crédits — pas cher pour les boîtes de dev et les services à faible trafic, mauvais pour la charge soutenue. Le mode de défaillance a son propre article : crédits CPU t3/t4g et les ralentissements surprises.
  • g — GPU. La famille g (g5, g6) pour le graphisme et l’inférence ML; la famille p pour l’entraînement lourd. Pertinent seulement quand la charge roule littéralement sur un GPU.

Au-delà vivent des spécialistes à connaître sans commencer par eux : i (optimisé stockage, NVMe local pour les bases très I/O), les variantes à suffixe d (disque local), hpc, mac, et les extrêmes mémoire x/z.

Les suffixes après le numéro de génération : g = Graviton/ARM (meilleur rapport prix-performance, exige des binaires compatibles ARM), a = AMD (x86 un peu moins cher), i = Intel, d = disque NVMe local attaché, n = bande passante réseau accrue. Ils se combinent : c7gn est optimisé calcul, Graviton, réseau renforcé.

Les générations : plus haut, c’est plus récent et presque toujours un meilleur rapport prix-performance dans la même région. En 2026, la 7e génération est le défaut répandu et la 8e génération Graviton (m8g, c8g, r8g) se déploie région par région; chaque type n’existe pas dans chaque région ou zone, alors vérifiez la disponibilité là où vous déployez réellement. Le catalogue complet est dans la documentation EC2 et les prix se comparent proprement dans le calculateur de prix AWS.

Quoi vérifier en premier

  • Votre vrai ratio CPU-mémoire aujourd’hui. Deux semaines de métriques de serveurs existants battent n’importe quelle théorie : CPU élevé avec mémoire oisive dit c; RSS gonflé avec CPU oisif dit r.
  • Si votre pile roule sur ARM. La plupart des charges Linux (Node, Python, Go, Java, nginx, clients Postgres) roulent nativement sur Graviton maintenant; un binaire x86 égaré ou une image de base de conteneur est le blocage habituel.
  • Charge soutenue ou en pointes. Une moyenne soutenue au-dessus de ~20-30 % de CPU disqualifie la famille t.
  • La disponibilité en région et en zone pour le type exact — les générations les plus récentes arrivent inégalement.
  • Les contraintes de licences. Certains logiciels commerciaux sont licenciés par cœur ou x86 seulement, ce qui peut forcer les suffixes i/a peu importe la préférence.

Comment vérifier

Listez ce qu’une région offre réellement pour une famille :

aws ec2 describe-instance-types \
  --filters "Name=instance-type,Values=m8g.*,m7g.*" \
  --query 'InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB]' \
  --output table

Vérifiez quels types une zone peut lancer maintenant :

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters "Name=instance-type,Values=m8g.large" \
  --query 'InstanceTypeOfferings[].Location'

Pour les preuves sur votre parc actuel, EC2 > Instances > Monitoring donne le CPU; la mémoire exige l’agent CloudWatch. AWS Compute Optimizer lit les deux et rend des verdicts de sur/sous-provisionnement — le flux de travail est couvert dans le redimensionnement avec Compute Optimizer.

L’approche

  1. Par défaut, la génération courante de m sur Graviton pour tout ce qui est neuf et non profilé : m8g où c’est disponible, m7g sinon. Repli sur m7i/m7a seulement quand le x86 est réellement requis.
  2. Dimensionnez pour le p95, pas pour la pointe des pointes. Prenez la taille qui couvre la charge quotidienne normale et laissez un groupe Auto Scaling absorber les pointes avec plus d’instances plutôt qu’une seule géante — l’horizontal bat le vertical pour les étages sans état.
  3. Mesurez deux semaines, puis rajustez le ratio. CPU constamment au-dessus de 70 % avec mémoire sous 40 % : passez à c. Mémoire au-dessus de 70 % avec CPU au ralenti : passez à r. Les deux au ralenti : réduisez la taille ou passez à t.
  4. Utilisez t délibérément, pas par accident — dev, staging, cron, outils internes, sites vraiment tranquilles. Tout ce qui a un SLA et du trafic constant mérite une famille à performance fixe.
  5. Testez Graviton avec une instance canari derrière le même répartiteur avant de migrer un parc; une construction de conteneur multi-architecture rend l’échange réversible en minutes.
  6. Seulement une fois le type stabilisé, achetez le rabais. Les Savings Plans et les instances réservées verrouillent la décision de famille, alors engagez-vous après la mesure, pas avant — les compromis vivent dans RI vs Savings Plans vs Spot.

Quand c’est le mauvais choix

Si votre charge tient dans Lambda, Fargate ou un service géré, le meilleur type d’instance est aucun — n’héritez pas d’un parc à gérer parce que choisir une instance semblait l’étape naturelle. Sautez les familles spécialistes tant qu’une mesure ne les exige pas : acheter des boîtes NVMe de famille i pour une base qui fait 200 IOPS, ou de la famille r pour une JVM dont le tas n’a simplement jamais été réglé, c’est dépenser sur un diagnostic que personne n’a posé. Et ne courez pas après chaque nouvelle génération la semaine de son lancement sur tout un parc; migrez de façon opportuniste au fil des remplacements d’instances.

Erreurs fréquentes

  • Dimensionner par peur : prendre du 4xlarge « pour être sûr » et rouler à 6 % d’utilisation pendant deux ans. Le surprovisionnement est le plus gros coût EC2 silencieux dans la plupart des comptes.
  • Traiter la famille t comme « le m pas cher » et y mettre de la charge de production constante — le bridage de crédits ou les frais excédentaires arrivent en quelques semaines.
  • Ignorer Graviton pour des raisons de compatibilité vérifiées la dernière fois en 2021. L’écosystème a bougé; la plupart des piles courantes sont propres sur ARM maintenant.
  • Laisser une instance réservée achetée pour l’ancien type dicter l’architecture des années plus tard. La queue du rabais ne devrait pas remuer le chien de la charge.

Garder le contrôle

  • Activez Compute Optimizer sur tout le compte; revoyez ses constats chaque trimestre et agissez sur les cinq premiers.
  • Mettez les choix de types dans les modèles de lancement et l’IaC pour que les changements soient des diffs révisés, pas de la dérive en console.
  • Refaites la vérification de ratio après les gros changements applicatifs — une couche de cache ou une mise à niveau d’exécution peut faire basculer une charge c en charge m.
  • Suivez le prix-performance par service, pas par instance : les requêtes servies par dollar est la métrique qui tranche les débats de familles.

Le décodeur est simple : la lettre de famille pour le ratio, la génération pour le prix-performance, le suffixe pour le processeur, la taille pour l’échelle — et ce sont les mesures, pas l’instinct, qui vous font bouger entre eux. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.