Instance EC2 t3/t4g soudainement lente : les crédits CPU et la surprise des instances à rafale

Quand une instance t3 ou t4g qui roulait bien depuis des semaines se met soudainement à ramper — requêtes en file, charge moyenne qui grimpe, CPU plafonné à un niveau étrangement bas — le coupable habituel est un solde de crédits CPU épuisé. Les instances à rafale gagnent des crédits à taux fixe et les dépensent dès que le CPU dépasse une petite ligne de base; une charge soutenue vide le réservoir, et en mode standard l’instance est alors bridée à sa ligne de base, peu importe la pression de la charge. En mode unlimited, pas de ralentissement — vous récoltez plutôt des frais de crédits excédentaires sur la facture. Dans les deux cas, le graphique qui explique tout, c’est CPUCreditBalance.

Ce qui se passe

La famille t (t3, t3a, t4g) vous vend une fraction de CPU avec le droit de faire des rafales. Chaque taille a une ligne de base — un pourcentage d’un vCPU complet utilisable en continu (environ 10 % par vCPU sur une t3.micro, croissant avec la taille) — et gagne des crédits CPU à un taux horaire constant. Un crédit égale une vCPU-minute à 100 %. Roulez sous la ligne de base et les crédits s’accumulent, jusqu’à un plafond d’environ 24 heures de gains; roulez au-dessus et les crédits brûlent.

Ce qui arrive à zéro dépend du mode de crédits :

Mode standard : l’hyperviseur plafonne l’instance à sa ligne de base. De l’intérieur, la boîte semble brisée — top montre un CPU modeste pendant que tout est lent, parce que l’OS ne voit pas le bridage externe. Le temps volé (%st dans top) monte souvent. C’est le « ralentissement surprise ».
Mode unlimited (le défaut pour t3/t3a/t4g au lancement, sauf si votre compte ou votre modèle le remplace) : l’instance continue ses rafales sur des crédits excédentaires. Si l’utilisation moyenne reste au-dessus de la ligne de base sur 24 heures glissantes, l’excédent est facturé par vCPU-heure. La performance reste bonne; la surprise déménage sur la facture. Une t3 qui déborde en permanence en mode unlimited peut finir par coûter plus cher que l’instance de famille m que vous évitiez d’acheter.

Les deux comportements fonctionnent comme prévu. La famille t est tarifée pour des charges en pointes, surtout inactives — boîtes de dev, sites à faible trafic, exécuteurs cron. Un service à charge constante sur une instance t, c’est une instance m mal tarifée avec des étapes en trop.

Quoi vérifier en premier

La tendance de CPUCreditBalance sur deux semaines. Une dent de scie qui récupère est saine; un déclin lent vers zéro explique le ralentissement et dit à peu près quand ça a commencé.
Le mode de crédits. Standard ou unlimited décide si vous déboguez de la latence ou une facture.
Ce qui a changé quand le drainage a commencé — un déploiement, une marche de trafic, un processus emballé, un cryptomineur. L’épuisement des crédits est un symptôme; quelque chose s’est mis à manger du CPU.
Le temps volé dans l’invité. Un %st soutenu sur une instance t à solde zéro, c’est le bridage rendu visible.
Si la charge a jamais été une charge en rafale. Si le CPU moyen vit au-dessus de la ligne de base chaque jour, c’est la famille d’instance qui est mauvaise, pas le réglage.

Comment vérifier

Tirez les métriques de crédits (périodes de 5 minutes; ce sont des métriques d’instance standard, aucun agent requis) :

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-06-27T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Average

Faites pareil pour CPUCreditUsage, CPUSurplusCreditBalance et CPUSurplusCreditsCharged — la dernière est le signal direct « le mode unlimited vous facture ». Dans la console, EC2 > Instances > (instance) > Monitoring trace les quatre à côté de CPUUtilization, la façon la plus rapide de voir l’utilisation s’aplatir exactement à la ligne de base quand le solde touche zéro.

Vérifiez le mode de crédits :

aws ec2 describe-instance-credit-specifications \
  --instance-ids i-0123456789abcdef0

Dans l’invité, top ou mpstat 5 montrant un %st croissant avec peu de CPU utilisable corrobore le bridage externe. Le tableau complet des crédits par taille vit dans la documentation EC2.

Le correctif

Stabilisez d’abord si la production souffre : basculez l’instance en mode unlimited — effet immédiat, sans redémarrage :
```
aws ec2 modify-instance-credit-specification \
  --instance-credit-specifications 'InstanceId=i-0123456789abcdef0,CpuCredits=unlimited'
```
Ça échange le bridage contre des frais excédentaires mesurés; c’est un garrot, pas le traitement.
Trouvez et corrigez ce qui mange les crédits. Profilez la boîte : un worker emballé, une boucle d’expédition de journaux, une requête sans index refoulée vers l’étage applicatif. Si le drainage a commencé avec un déploiement, le déploiement est votre suspect.
Redimensionnez si la charge est réelle et constante. Une utilisation soutenue au-dessus de la ligne de base signifie que la charge a dépassé l’économie des instances à rafale — passez à m7g/m6i (usage général) ou c7g/c6i (calcul intensif). Les recommandations de redimensionnement de Compute Optimizer signalent généralement exactement ce patron.
Montez dans la famille t si la charge reste en pointes mais plus grosse — une taille t supérieure gagne des crédits plus vite et a une ligne de base plus haute, souvent moins cher que de laisser courir les frais excédentaires du mode unlimited.
Décidez le mode de crédits délibérément par environnement. Standard pour les boîtes de dev où le bridage est un signal inoffensif; unlimited pour les instances t de production où vous acceptez des rafales mesurées — avec une alarme de facturation en face.

Quand c’est le mauvais choix

Ne fuyez pas la famille t par réflexe après un incident de crédits. Pour des charges vraiment en pointes, une t4g est radicalement moins chère qu’une instance m toujours allumée, et la tarification Graviton des t4g en fait un des meilleurs rapports qualité-prix qu’AWS vende. À l’inverse, ne « réglez » pas l’épuisement de crédits en scriptant des cycles d’arrêt/démarrage ou en jonglant avec les instances — les crédits de lancement des vieilles t2 étaient le vieux truc, et les t3/t4g reçoivent des crédits de lancement limités précisément pour arrêter ce jeu. Corrigez la charge ou changez de famille.

Erreurs fréquentes

Lire CPUUtilization tout seul et conclure « le CPU est juste à 20 %, ça doit être le réseau » — 20 % est peut-être le plafond de la ligne de base.
Ne pas savoir quel mode de crédits est en vigueur, de sorte que le bridage se débogue comme un bogue applicatif, ou les frais excédentaires comme une erreur de facturation.
Étalonner sur une instance t fraîche avec un solde de crédits plein et dimensionner la production à partir de ces chiffres.
Rouler des bases de données ou des workers de files sur des instances t parce qu’elles dorment en staging — les profils de charge de production diffèrent, et l’étage de données est celui qui casse le plus laidement sous bridage.

Prévention

Une alarme CloudWatch sur CPUCreditBalance sous environ 20 % du maximum de la taille, branchée dans le même chemin d’alerte que votre base d’alarmes CloudWatch.
Une alarme sur CPUSurplusCreditsCharged au-dessus de zéro pour les instances censées être en standard que quelqu’un a basculées en unlimited puis oubliées.
Une revue trimestrielle du CPU moyen de chaque instance t : tout ce qui vit au-dessus de la ligne de base reçoit un changement de famille, pas un plus gros réservoir.
Documentez la décision du mode de crédits dans le modèle de lancement pour qu’elle survive au remplacement d’instance.

Les instances à rafale sont un contrat : surtout inactives, occasionnellement rapides. Tenez votre bout et c’est le calcul le moins cher sur AWS; brisez-le et vous êtes bridé ou facturé, selon le mode choisi. 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.