EBS gp2 vs gp3 : lequel choisir pour vos volumes SSD General Purpose ?

Quand on provisionne un volume EBS pour une instance EC2 en production, on tombe inévitablement sur ce choix : gp2 ou gp3 ? La différence n'est pas cosmétique. Le modèle de performance de gp2 crée des contraintes opérationnelles réelles — des équipes ont surdimensionné leurs volumes uniquement pour obtenir les IOPS dont elles avaient besoin, sans jamais utiliser la capacité de stockage supplémentaire. Ce guide clarifie les deux modèles et vous aide à choisir.

TL;DR — gp2 vs gp3 en un coup d'œil

Critère gp2 gp3
IOPS de base 3 IOPS/Go (min 100, max 16 000) 3 000 IOPS incluses, indépendantes de la taille
IOPS provisionnées indépendamment Non Oui, jusqu'à 16 000 IOPS
Débit de base 128–250 Mo/s (lié à la taille) 125 Mo/s inclus, jusqu'à 1 000 Mo/s provisionnables
Mécanisme burst Bucket de crédits I/O Aucun — performance stable et prévisible
Coût relatif Référence Généralement moins cher à performance équivalente
Cas d'usage recommandé Volumes existants non migrés Tout nouveau volume General Purpose

Comment fonctionnent gp2 et gp3 — le modèle de performance

Avant de choisir, il faut comprendre pourquoi les deux types se comportent différemment sous charge. La distinction fondamentale est dans le couplage entre taille et performance.

Le modèle gp2 : performance couplée à la taille

Avec gp2, les IOPS de base sont calculées à raison de 3 IOPS par Go provisionné, avec un plancher à 100 IOPS et un plafond à 16 000 IOPS (atteint à 5 334 Go). Si votre application a besoin de 6 000 IOPS mais ne consomme que 200 Go de données, vous devez provisionner environ 2 000 Go uniquement pour débloquer les IOPS — la capacité supplémentaire est du gaspillage pur.

Le mécanisme de burst de gp2 repose sur un bucket de crédits I/O. Les volumes inférieurs à 1 To accumulent des crédits quand ils opèrent en dessous de leur baseline, et peuvent les dépenser pour atteindre jusqu'à 3 000 IOPS temporairement. Ce système crée une performance non déterministe : un volume qui a épuisé ses crédits retombe brutalement à sa baseline, ce qui se traduit par des latences imprévisibles difficiles à diagnostiquer.

Le modèle gp3 : performance découplée de la taille

gp3 rompt ce couplage. Chaque volume gp3 inclut 3 000 IOPS et 125 Mo/s de débit quelle que soit sa taille — même pour un volume de 1 Go. Au-delà de cette baseline, vous pouvez provisionner indépendamment jusqu'à 16 000 IOPS et jusqu'à 1 000 Mo/s de débit, sans modifier la capacité de stockage. Il n'y a pas de bucket de crédits : la performance est stable et prévisible.

graph LR subgraph gp2["gp2 — Performance couplée"] G2S["Taille du volume (Go)"] -->|"3 IOPS/Go"| G2I["IOPS disponibles"] G2I -->|"Burst possible"| G2B["Bucket de crédits (épuisable)"] G2B -->|"Crédits épuisés"| G2D["Retour à la baseline (latence imprévisible)"] end subgraph gp3["gp3 — Performance découplée"] G3S["Taille du volume (Go)"] G3I["IOPS provisionnées (indépendantes)"] G3T["Débit provisionné (indépendant)"] G3P["Performance stable et prévisible"] G3S --> G3P G3I --> G3P G3T --> G3P end
  1. gp2 — couplage taille/IOPS : augmenter les IOPS impose d'augmenter la taille du volume, même si l'espace n'est pas nécessaire.
  2. gp3 — découplage : taille, IOPS et débit sont trois dimensions indépendantes. On ajuste chacune séparément selon le besoin réel.
  3. Burst gp2 : la performance peut dépasser la baseline temporairement, mais s'effondre une fois les crédits épuisés — comportement invisible jusqu'à ce qu'il frappe en production.
  4. gp3 stable : pas de burst, pas de crédit — la performance provisionnée est la performance réelle, en permanence.

Pourquoi gp3 est généralement moins cher à performance équivalente

Le coût d'un volume EBS se compose du stockage (par Go-mois) et, pour gp3, des IOPS et du débit provisionnés au-delà de la baseline incluse. Pour gp2, vous payez uniquement le stockage — mais comme les IOPS sont couplées à la taille, vous payez souvent pour du stockage que vous n'utilisez pas.

Prenons un cas concret : une base de données qui a besoin de 6 000 IOPS mais seulement 200 Go de données.

  • gp2 : vous devez provisionner ~2 000 Go pour atteindre 6 000 IOPS. Vous payez 1 800 Go de stockage inutile.
  • gp3 : vous provisionnez 200 Go + 3 000 IOPS supplémentaires (au-delà des 3 000 incluses). Vous payez exactement ce dont vous avez besoin.

Dans la majorité des scénarios où les IOPS requises dépassent ce que la taille réelle du volume fournirait naturellement en gp2, gp3 est moins cher. La seule exception est un volume très grand avec des besoins en IOPS modestes — dans ce cas, les IOPS gp2 incluses dans la taille peuvent suffire sans surcoût.

Penser gp2 comme un forfait tout-inclus où le prix du stockage finance aussi les IOPS. gp3, c'est la facturation à la carte : vous payez séparément chaque ressource que vous consommez réellement.

Identifier les volumes gp2 candidats à la migration

Avant de migrer, il faut savoir quels volumes gp2 existent dans votre compte et évaluer si leur profil de performance justifie le passage à gp3. Les volumes qui ont régulièrement épuisé leurs crédits burst sont les candidats prioritaires — ce sont eux qui causent des latences imprévisibles.

Lister tous les volumes gp2 d'une région

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{ID:VolumeId,SizeGB:Size,IOPS:Iops,State:State}' \
  --output table \
  --region us-east-1

Vérifier la consommation de crédits burst sur CloudWatch

La métrique BurstBalance indique le pourcentage de crédits I/O restants pour un volume gp2. Un volume qui descend régulièrement sous 20 % est sous pression et candidat prioritaire à la migration.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-08T00:00:00Z \
  --period 3600 \
  --statistics Minimum \
  --region us-east-1

Un Minimum proche de zéro sur une semaine indique que le volume a opéré à sa baseline ou en dessous — la performance burst n'était plus disponible pendant ces périodes.

Migrer un volume gp2 vers gp3 — sans interruption de service

La migration d'un volume EBS de gp2 vers gp3 se fait via Elastic Volumes, sans détacher le volume ni redémarrer l'instance. AWS modifie le volume en arrière-plan pendant qu'il reste attaché et opérationnel.

Étape 1 — Modifier le type du volume

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --region us-east-1

Cette commande déclenche la modification. Le volume passe en état modifying. Pendant cette phase, les performances peuvent être légèrement dégradées — planifiez cette opération en dehors des pics de charge.

Étape 2 — Surveiller la progression

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[*].{VolumeId:VolumeId,State:ModificationState,Progress:Progress}' \
  --output table \
  --region us-east-1

Attendez que ModificationState passe à completed avant de modifier les IOPS ou le débit.

Étape 3 — Ajuster les IOPS et le débit si nécessaire

Par défaut, après migration vers gp3, le volume hérite de 3 000 IOPS et 125 Mo/s. Si votre charge nécessite davantage, provisionnez explicitement :

aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 250 \
  --region us-east-1
graph TD A["Lister volumes gp2 aws ec2 describe-volumes"] --> B["Analyser BurstBalance CloudWatch"] B --> C{"BurstBalance régulièrement bas ?"} C -->|"Oui — prioritaire"| D["Modifier vers gp3 aws ec2 modify-volume"] C -->|"Non — stable"| E["Calculer coût comparatif gp2 vs gp3"] E --> D D --> F["État : modifying Surveiller la progression"] F --> G["État : completed gp3 actif — 3000 IOPS incluses"] G --> H{"Baseline gp3 suffisante ?"} H -->|"Non"| I["Provisionner IOPS/débit --iops --throughput"] H -->|"Oui"| J["Migration terminée"]
  1. Describe volumes : identifier les volumes gp2 existants et leur taille.
  2. Analyser BurstBalance : repérer les volumes sous pression I/O.
  3. Modifier vers gp3 : déclencher la migration sans interruption via Elastic Volumes.
  4. État 'modifying' : AWS optimise le volume en arrière-plan — surveiller la progression.
  5. État 'completed' : migration terminée, volume opérationnel en gp3 avec 3 000 IOPS/125 Mo/s inclus.
  6. Ajuster IOPS/débit : si la baseline gp3 ne suffit pas, provisionner indépendamment selon le besoin réel.

Le cas où gp2 peut encore avoir du sens

Il serait inexact de dire que gp3 est systématiquement supérieur dans tous les cas. Pour un volume de grande taille avec des besoins en IOPS modestes — par exemple 10 To de données d'archive avec 2 000 IOPS requises — gp2 fournit naturellement 16 000 IOPS (plafond) incluses dans le prix du stockage. Migrer vers gp3 sans provisionner d'IOPS supplémentaires donnerait 3 000 IOPS incluses, ce qui est suffisant, mais le coût du stockage seul peut être comparable.

En pratique, la migration vers gp3 reste avantageuse dans la grande majorité des cas. Mais pour les volumes très volumineux avec des workloads I/O légères, vérifiez le calcul de coût avant de migrer en masse.

Expérience terrain : le diagnostic qui prend du temps

Un scénario classique : une application web signale des latences élevées de manière intermittente, uniquement en heures de pointe. Les logs applicatifs ne montrent rien d'anormal. Les métriques CPU et mémoire de l'instance sont normales. L'équipe passe du temps à investiguer le code, les requêtes SQL, la configuration réseau.

La vraie cause : le volume EBS gp2 de 500 Go hébergeant la base de données avait une baseline de 1 500 IOPS. En dehors des pics, le volume accumulait des crédits. Pendant les pics, il les épuisait en quelques minutes et retombait à 1 500 IOPS — insuffisant pour la charge. La métrique BurstBalance sur CloudWatch montrait clairement des chutes à zéro exactement pendant les fenêtres de latence.

La correction : migration vers gp3 avec 4 000 IOPS provisionnées. Coût mensuel inférieur au volume gp2 original, latences stables. Le diagnostic aurait dû commencer par BurstBalance — c'est la première métrique à vérifier sur tout volume gp2 qui présente des latences intermittentes.

IAM — permissions nécessaires pour modifier les volumes EBS

Les opérations ec2:ModifyVolume et ec2:DescribeVolumesModifications requièrent des permissions explicites. Voici une politique minimale pour un rôle dédié à la gestion des volumes :

🔽 Afficher la politique IAM minimale 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEBSVolumes",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifyEBSVolumes",
      "Effect": "Allow",
      "Action": "ec2:ModifyVolume",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*"
    },
    {
      "Sid": "CloudWatchEBSMetrics",
      "Effect": "Allow",
      "Action": "cloudwatch:GetMetricStatistics",
      "Resource": "*"
    }
  ]
}

Note : ec2:DescribeVolumes et ec2:DescribeVolumesModifications ne supportent pas les restrictions au niveau de la ressource individuelle — Resource: "*" est requis pour ces actions. Vérifiez la Service Authorization Reference EC2 pour confirmer le support resource-level de chaque action.

Choisir entre gp2 et gp3 : arbre de décision

graph TD START["Besoin d'un volume General Purpose SSD"] --> NEW{"Nouveau volume ou existant ?"} NEW -->|"Nouveau"| GP3["Choisir gp3 (défaut recommandé)"] NEW -->|"Existant gp2"| BURST{"BurstBalance régulièrement épuisé ?"} BURST -->|"Oui"| MIGRATE["Migrer vers gp3 avec IOPS provisionnées"] BURST -->|"Non"| CALC{"IOPS requises > baseline naturelle gp2 ?"} CALC -->|"Oui"| MIGRATE CALC -->|"Non"| COMPARE["Comparer les coûts avant de migrer"] COMPARE --> MIGRATE GP3 --> IOPS{"Besoin > 16 000 IOPS ou > 1 000 Mo/s ?"} IOPS -->|"Oui"| IO2["Considérer io1/io2 (Provisioned IOPS SSD)"] IOPS -->|"Non"| DONE["gp3 configuré"]
  1. Nouveau volume : gp3 est le choix par défaut — performance de base supérieure, coût généralement inférieur.
  2. Volume existant gp2 avec BurstBalance épuisé : migrer vers gp3 avec IOPS provisionnées adaptées à la charge réelle.
  3. Volume existant gp2 stable : calculer le coût comparatif avant de migrer — la migration reste généralement avantageuse mais vérifiez pour les très grands volumes à faible I/O.
  4. Besoin d'IOPS > 16 000 : ni gp2 ni gp3 ne conviennent — considérez io1 ou io2.

Conclusion — Choisir gp3 pour tout nouveau volume EBS General Purpose

La réponse à la question initiale est claire : gp3 est le seul type qui permet de scaler les IOPS indépendamment de la taille de stockage. gp2 couple les deux de manière rigide, ce qui force le surdimensionnement du stockage pour atteindre les IOPS requises. gp3 est également moins cher dans la majorité des cas d'usage courants.

Pour tout nouveau volume General Purpose, gp3 est le choix par défaut. Pour les volumes gp2 existants, commencez par analyser la métrique BurstBalance — les volumes qui l'épuisent régulièrement sont vos candidats prioritaires à la migration.

Consultez la documentation officielle AWS sur les types de volumes EBS pour les valeurs de performance et de tarification actuelles — les prix varient par région et sont mis à jour régulièrement.

Glossaire

Terme Définition
IOPS Input/Output Operations Per Second — mesure du nombre d'opérations de lecture/écriture par seconde qu'un volume peut traiter.
Burst Balance Réserve de crédits I/O accumulés par un volume gp2 opérant sous sa baseline, utilisables pour dépasser temporairement cette baseline.
Elastic Volumes Fonctionnalité EBS permettant de modifier le type, la taille, les IOPS et le débit d'un volume sans le détacher ni interrompre l'instance.
Débit (Throughput) Volume de données transférées par seconde entre l'instance et le volume EBS, exprimé en Mo/s.
General Purpose SSD Famille de volumes EBS (gp2, gp3) conçus pour les workloads à usage général — équilibre entre performance et coût, adaptés à la majorité des cas d'usage.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite