Comprendre les instances T3 burstables AWS : crédits CPU et ralentissements soudains

Vous déployez une application sur une instance T3, tout fonctionne parfaitement pendant quelques minutes, puis le serveur se met à ramper sans raison apparente — pas d'alerte mémoire, pas d'erreur réseau, juste un CPU qui tourne à plein régime sans rien produire. C'est le comportement caractéristique des instances T3 burstables AWS lorsque les crédits CPU sont épuisés, et comprendre ce mécanisme est indispensable avant de dimensionner n'importe quelle charge de travail sur cette famille d'instances.

TL;DR — Crédits CPU T3 en un coup d'œil

ConceptComportement observé
Crédit CPUUnité permettant de dépasser le niveau de base CPU de l'instance
AccumulationCrédits accumulés quand l'utilisation CPU reste sous le niveau de base
ConsommationCrédits dépensés quand l'utilisation CPU dépasse le niveau de base
ÉpuisementCPU plafonné au niveau de base — ralentissement brutal et soudain
Mode illimitéBurst continu possible, mais facturation supplémentaire au-delà de la baseline
Mode standardComportement par défaut sur T3 — CPU plafonné sans crédits disponibles

Comment fonctionnent les instances T3 burstables

Les instances T3 ne sont pas des instances à CPU dédié. Elles reposent sur un modèle de crédit CPU conçu pour les charges de travail dont l'utilisation processeur est intermittente — serveurs web à faible trafic, environnements de développement, microservices légers. L'idée centrale : l'instance accumule des crédits quand elle consomme moins que son niveau de base, et les dépense quand elle dépasse ce seuil.

Chaque type d'instance T3 possède un niveau de base CPU exprimé en pourcentage d'un vCPU. Par exemple, une t3.micro dispose d'un niveau de base de 10 % par vCPU. Tant que l'utilisation reste sous ce seuil, des crédits s'accumulent. Dès qu'elle le dépasse, les crédits sont consommés. Quand le solde atteint zéro en mode standard, le CPU est mécaniquement bridé au niveau de base — c'est le CPU throttling.

Imaginez un compte bancaire avec un plafond de découvert nul : vous pouvez dépenser plus que votre solde habituel tant que vous avez des réserves, mais dès que le compte est vide, chaque transaction au-delà du minimum est refusée instantanément.

AWS a introduit deux modes de fonctionnement pour les instances T3 :

  • Mode standard : comportement par défaut. Quand les crédits sont épuisés, le CPU est plafonné au niveau de base. Aucune facturation supplémentaire.
  • Mode illimité : le burst peut continuer au-delà du solde de crédits, mais AWS facture les vCPU-heures consommées au-delà de la baseline. Ce mode est activable explicitement.

Un détail important souvent ignoré : sur les instances T3, le mode illimité est activé par défaut lors du lancement via la console ou l'API, contrairement aux instances T2 où le mode standard est le défaut. Vérifiez toujours la configuration effective de vos instances avant de supposer un comportement.

graph TD A["Instance T3 démarre
Crédits initiaux chargés"] --> B{"Utilisation CPU vs Baseline"} B -->|"Sous la baseline
Accumulation"| C["CPUCreditBalance augmente"] B -->|"Au-dessus de la baseline
Burst actif"| D["CPUCreditBalance diminue"] C --> B D --> E{"Solde de crédits = 0 ?"} E -->|"Non — crédits disponibles"| B E -->|"Oui"| F{"Mode de crédit ?"} F -->|"Standard"| G["CPU bridé à la baseline
Throttling actif"] F -->|"Illimité"| H["Burst continue
CPUSurplusCreditsCharged facturé"] G --> I["Utilisation redescend
sous la baseline"] H --> I I --> C
  1. Zone verte (accumulation) : l'utilisation CPU reste sous la baseline — les crédits s'accumulent progressivement jusqu'au plafond maximal de l'instance.
  2. Zone orange (burst) : l'utilisation dépasse la baseline — les crédits accumulés sont consommés pour alimenter le surplus de CPU.
  3. Zone rouge (épuisement) : le solde de crédits atteint zéro — en mode standard, le CPU est immédiatement bridé à la baseline. En mode illimité, le burst continue avec facturation.
  4. Récupération : dès que l'utilisation redescend sous la baseline, les crédits recommencent à s'accumuler.

Anatomie d'un crédit CPU T3

Un crédit CPU représente une minute d'utilisation d'un vCPU à 100 %. AWS documente le taux d'accumulation et le plafond de crédits pour chaque taille d'instance. Ces valeurs sont disponibles dans la documentation officielle AWS EC2 — ne les hardcodez jamais dans vos runbooks car elles peuvent évoluer.

Ce qui compte opérationnellement :

  • Le plafond de crédits accumulables est fixe par type d'instance. Une fois le plafond atteint, les nouveaux crédits sont perdus — une instance qui tourne à 0 % CPU pendant des heures ne constitue pas un réservoir infini.
  • Les crédits de lancement (launch credits) existent sur les instances T2 pour permettre un démarrage rapide. Sur T3, ce mécanisme est différent — vérifiez la documentation spécifique à T3 pour le comportement exact au démarrage.
  • Les crédits ne sont pas transférables entre instances et ne survivent pas à un arrêt de l'instance (stop/start).

Diagnostiquer un épuisement de crédits CPU T3

Le symptôme classique : l'application répond normalement, puis devient subitement lente sans aucun changement de trafic apparent. Les logs applicatifs ne montrent rien d'anormal. CloudWatch indique une utilisation CPU à exactement la valeur de la baseline — c'est le signe distinctif du throttling, pas d'une charge naturelle.

La métrique clé à surveiller est CPUCreditBalance dans CloudWatch. Quand elle approche de zéro, le ralentissement est imminent en mode standard.

Étape 1 — Vérifier le solde de crédits CPU en temps réel

Avant de chercher ailleurs, confirmez que l'instance est effectivement en train d'épuiser ses crédits. C'est la seule métrique qui distingue un vrai pic de charge d'un throttling silencieux.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2024-01-15T10:00:00Z \
  --end-time 2024-01-15T11:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

Un solde qui décroît régulièrement vers zéro confirme le diagnostic. Un solde stable à zéro avec un CPU plafonné confirme le throttling actif.

Étape 2 — Vérifier le mode de crédit configuré sur l'instance

Parce que le mode illimité est le défaut sur T3 au lancement, il est fréquent de découvrir des instances en mode illimité qui génèrent des coûts inattendus — ou inversement, des instances en mode standard qui throttlent sans que l'équipe le sache. Les deux cas méritent une vérification explicite.

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-0123456789abcdef0 \
  --region us-east-1

La réponse indique unlimited ou standard dans le champ CpuCredits. Si le résultat ne correspond pas à ce que vous attendez, c'est là que commence le vrai problème.

Étape 3 — Consulter la métrique CPUCreditUsage pour quantifier le burst

Le solde seul ne suffit pas — il faut aussi mesurer le rythme de consommation pour anticiper combien de temps avant épuisement complet. CPUCreditUsage indique les crédits dépensés sur la période.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUCreditUsage \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2024-01-15T10:00:00Z \
  --end-time 2024-01-15T11:00:00Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

Étape 4 — Créer une alarme CloudWatch sur CPUCreditBalance

Surveiller manuellement le solde n'est pas une stratégie opérationnelle. Une alarme sur CPUCreditBalance sous un seuil critique vous donne le temps d'agir avant que le throttling ne frappe les utilisateurs.

aws cloudwatch put-metric-alarm \
  --alarm-name 'T3-CreditBalance-Low' \
  --metric-name CPUCreditBalance \
  --namespace AWS/EC2 \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --region us-east-1
graph LR A["Instance T3"] --> B["CloudWatch Metrics"] B --> C["CPUCreditBalance
Solde disponible"] B --> D["CPUCreditUsage
Crédits consommés"] B --> E["CPUSurplusCreditsCharged
Mode illimité uniquement"] B --> F["CPUUtilization
Plafonné à baseline si throttling"] C --> G["Alarme : seuil bas"] E --> H["Alarme : coût inattendu"] G --> I["Action : redimensionner
ou passer en illimité"] H --> J["Action : passer en standard
ou changer de famille"]
  1. CPUCreditBalance : métrique principale — surveille le solde disponible. Alarme sous le seuil critique.
  2. CPUCreditUsage : mesure le rythme de consommation — permet d'estimer le temps restant avant épuisement.
  3. CPUSurplusCreditsCharged : visible uniquement en mode illimité — indique les crédits consommés au-delà du solde, directement facturés.
  4. CPUUtilization : en mode standard avec solde épuisé, cette métrique se stabilise exactement à la valeur de baseline — signal distinctif du throttling.

Le piège classique : mode illimité et facture surprise

Voici le scénario qui revient régulièrement en production : une équipe lance des instances T3 pour un environnement de staging. Le mode illimité est actif par défaut. Un développeur lance une suite de tests de charge. L'instance burste librement pendant des heures. Fin du mois, la facture EC2 contient une ligne CPUSurplusCredits inattendue.

Le diagnostic initial pointe vers une mauvaise taille d'instance. La vraie cause : personne n'avait vérifié le mode de crédit, et la métrique CPUSurplusCreditsCharged n'était pas surveillée. Le correctif n'est pas forcément de changer de taille — c'est de choisir consciemment entre mode standard (comportement prévisible, coût fixe) et mode illimité (performance garantie, coût variable).

Le mode standard est le bon choix quand la prévisibilité des coûts prime. Le mode illimité est justifié quand la dégradation de performance est inacceptable et que la charge CPU supplémentaire est ponctuelle et mesurée.

Modifier le mode de crédit sur une instance existante

aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications InstanceId=i-0123456789abcdef0,CpuCredits=standard \
  --region us-east-1

Cette modification prend effet immédiatement sans redémarrage de l'instance.

Choisir la bonne approche selon votre charge de travail

graph TD Start["Ma charge de travail T3 pose problème"] --> Q1{"Le CPU dépasse la baseline
de façon soutenue ?"} Q1 -->|"Oui — charge continue"| A1["Changer de famille d'instances
M6i / C6i — CPU dédié"] Q1 -->|"Non — pics ponctuels"| Q2{"La dégradation de perf
est-elle acceptable ?"} Q2 -->|"Oui — staging / dev"| A2["Mode standard
Coût prévisible, throttling possible"] Q2 -->|"Non — production critique"| Q3{"Les pics sont-ils
mesurés et bornés ?"} Q3 -->|"Oui — durée connue"| A3["Mode illimité
Surveiller CPUSurplusCreditsCharged"] Q3 -->|"Non — imprévisible"| A1

La règle pratique : si votre application a besoin de plus de CPU que la baseline de manière soutenue (pas ponctuelle), les instances T3 ne sont pas le bon choix — quelle que soit la configuration de crédits. Passez sur une famille à CPU dédié comme M6i ou C6i. Le mode illimité n'est pas un substitut à un bon dimensionnement.

IAM — Permissions minimales pour diagnostiquer les crédits T3

Les opérations de diagnostic décrites dans cet article nécessitent les permissions suivantes au minimum :

🔽 Afficher la politique IAM minimale 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadEC2CreditSpecs",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstanceCreditSpecifications",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ReadCloudWatchMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:DescribeAlarms"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ModifyCreditMode",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyInstanceCreditSpecification"
      ],
      "Resource": "*"
    }
  ]
}

Note : ec2:DescribeInstanceCreditSpecifications et cloudwatch:GetMetricStatistics ne supportent pas la restriction par ARN de ressource — "Resource": "*" est requis pour ces actions. Vérifiez le Service Authorization Reference AWS pour confirmer le support resource-level de chaque action avant de restreindre davantage.

Comprendre les crédits T3 : récapitulatif et prochaines étapes

Les instances T3 burstables sont un excellent choix économique pour les charges de travail à utilisation CPU intermittente — à condition de comprendre le modèle de crédits et de surveiller activement CPUCreditBalance. Le ralentissement soudain que vous observez n'est pas un bug : c'est le comportement documenté et attendu d'une instance en mode standard avec un solde épuisé.

Les trois actions concrètes à mettre en place immédiatement :

  1. Vérifier le mode de crédit de toutes vos instances T3 en production avec describe-instance-credit-specifications.
  2. Créer des alarmes CloudWatch sur CPUCreditBalance pour chaque instance T3 critique.
  3. Surveiller CPUSurplusCreditsCharged si vous utilisez le mode illimité pour détecter les dérives de coût.

Pour aller plus loin, consultez la documentation officielle AWS sur les instances burstables et la section sur les concepts de crédits et baseline.

Glossaire

TermeDéfinition
Crédit CPUUnité de capacité de burst accumulée par une instance T3 lorsque son utilisation CPU reste sous la baseline.
Baseline CPUNiveau d'utilisation CPU garanti et soutenu pour une instance burstable, exprimé en pourcentage de vCPU.
CPU ThrottlingPlafonnement forcé du CPU à la baseline lorsque le solde de crédits est épuisé en mode standard.
Mode illimitéConfiguration T3 permettant le burst au-delà du solde de crédits, avec facturation des surplus consommés.
CPUSurplusCreditsChargedMétrique CloudWatch indiquant les crédits consommés au-delà du solde en mode illimité — directement facturés.

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