Aller au contenu

AWS Mis à jour le 2026-07-04

Erreur InsufficientInstanceCapacity : ce que ça signifie et les vrais contournements

L'erreur InsufficientInstanceCapacity signifie qu'AWS n'a pas de matériel disponible pour ce type d'instance dans cette zone de disponibilité en ce moment. Voici ce qui fonctionne vraiment : autres zones, autres types, et réservations de capacité.

InsufficientInstanceCapacity veut dire exactement ce que ça dit : en ce moment, AWS n’a pas assez de matériel disponible du type d’instance demandé dans la zone de disponibilité précise que vous avez ciblée. Ce n’est pas un problème de quota, pas un problème de facturation, et pas quelque chose qu’un billet de soutien règle en temps réel. Les vrais contournements consistent à être flexible sur l’une des trois variables — la zone, le type d’instance, ou le moment — ou à payer d’avance pour de la capacité garantie avec une réservation de capacité à la demande (ODCR).

Ce qui se passe

Chaque zone de disponibilité a un bassin fini d’hôtes physiques par famille d’instances, et AWS ne survend rien ici : quand le bassin de m7i.2xlarge dans us-east-1a est épuisé, les lancements échouent avec cette erreur jusqu’à ce que de la capacité se libère ou s’ajoute. L’erreur a une portée étroite — le même type peut se lancer sans problème dans us-east-1b au même moment, et une autre taille dans la même zone peut aussi fonctionner.

Deux situations la rendent chronique plutôt que passagère. D’abord, les familles rares : les instances GPU (p4, p5, g6) et les générations les plus récentes sont limitées en approvisionnement à l’échelle de l’industrie, et frapper des erreurs de capacité sur elles est routinier, pas exceptionnel. Ensuite, le piège de l’arrêt/démarrage : tant qu’une instance roule, sa capacité est à vous; dès que vous l’arrêtez, cette place retourne au bassin partagé. Arrêter une grosse instance rare pendant la nuit pour économiser peut vouloir dire être incapable de la redémarrer le matin. Ça mord le plus fort sur les machines GPU et les gros types optimisés mémoire, et ça signifie aussi qu’une opération d’arrêt-redimensionnement peut vous laisser en plan — planifiez ça avant de redimensionner une instance.

Ne confondez pas avec VcpuLimitExceeded ou les autres erreurs de quota — celles-là concernent les limites de votre compte et se règlent par une demande d’augmentation de quota. La capacité concerne l’approvisionnement physique d’AWS, et aucun formulaire ne règle la physique.

Quoi vérifier en premier

  • Lisez le code d’erreur exact. InsufficientInstanceCapacity, c’est l’approvisionnement; InstanceLimitExceeded / VcpuLimitExceeded, c’est votre quota. Problèmes différents, correctifs différents.
  • Avez-vous épinglé une zone de disponibilité? Un lancement qui spécifie us-east-1a ne peut échouer que là. Désépingler est souvent tout le correctif.
  • Est-ce une famille rare? Les types GPU et de dernière génération échouent souvent ainsi. Les types courants plus anciens (m5, c5, r5) le font rarement longtemps.
  • Y a-t-il un groupe Auto Scaling derrière? Consultez l’historique d’activité du groupe — les erreurs de capacité y apparaissent avec le type et la zone exacts qui ont échoué.
  • Est-ce une instance arrêtée qui refuse de démarrer? C’est le problème de la place relâchée, et les contournements diffèrent d’un lancement neuf.

Comment vérifier

Pour un groupe Auto Scaling, le journal d’activité nomme l’échec précisément :

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name prod-web-asg \
  --max-records 10 \
  --query 'Activities[].[StartTime,StatusCode,StatusMessage]'

Pour les lancements manuels, réessayez dans une autre zone en spécifiant seulement le sous-réseau :

# Lister les sous-réseaux et leurs zones dans le VPC
aws ec2 describe-subnets \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'Subnets[].[SubnetId,AvailabilityZone]' --output table

# Tenter le lancement dans le sous-réseau d'une autre zone
aws ec2 run-instances --instance-type m7i.2xlarge \
  --image-id ami-0123456789abcdef0 \
  --subnet-id subnet-0fedcba9876543210 --count 1

Si vous utilisez du Spot ou des flottes mixtes, les scores de placement Spot (EC2 > Spot Requests > Placement score) évaluent quelles régions et zones ont présentement la meilleure capacité pour un ensemble de types — un signal utile même pour la planification à la demande. Les réservations de capacité vivent sous EC2 > Capacity Reservations, et la mécanique est documentée à https://docs.aws.amazon.com/ec2/.

La procédure

  1. Réessayez dans une autre zone de disponibilité. Le geste le plus efficace. La capacité est limitée à la zone, alors déplacer le lancement vers un sous-réseau voisin règle la majorité des échecs ponctuels. Pour un groupe Auto Scaling, assurez-vous qu’il couvre au moins deux ou trois sous-réseaux de zones différentes pour qu’il le fasse tout seul.
  2. Assouplissez le type d’instance. Une taille plus haut ou plus bas dans la même famille (m7i.xlarge au lieu de m7i.2xlarge), la génération précédente (m6i), ou un équivalent dans une famille voisine (c7i, r7i selon la forme de la charge). Les groupes Auto Scaling et EC2 Fleet prennent en charge les types mixtes et la sélection par attributs précisément pour que ça se fasse automatiquement — le patron est couvert dans politiques d’instances mixtes.
  3. Si c’est une instance arrêtée qui ne démarre plus, réessayez en boucle — et arrêtez de l’arrêter. Des tentatives aux quelques minutes récupèrent habituellement la capacité rare en quelques minutes à quelques heures, mais il n’y a aucune garantie de délai. Si la charge compte, laissez-la rouler ou protégez-la avec une réservation (étape suivante).
  4. Achetez une réservation de capacité à la demande pour la capacité sur laquelle vous ne pouvez pas gager. Une ODCR garantit la combinaison type/zone et peut être créée et annulée en tout temps. Mécanique de coût honnête : vous payez le tarif à la demande pour la capacité réservée, qu’une instance y roule ou non — c’est une assurance au prix du calcul. Jumelez-la avec des Savings Plans ou des RI régionales pour le volet rabais; la réservation elle-même concerne la disponibilité, pas le prix.
  5. Pour les charges d’entraînement GPU, utilisez les Capacity Blocks for ML. Ils permettent de réserver la capacité GPU rare pour une fenêtre future définie au lieu de se battre avec le bassin à la demande le matin où votre entraînement commence.
  6. Si un environnement complet doit exister sur demande (relève, gros lancements), parlez à AWS d’avance. Les équipes de compte et le soutien AWS peuvent conseiller sur la planification de capacité pour les gros événements — mais seulement à l’avance, pas en plein incident.

Quand c’est la mauvaise approche

N’architecturez pas autour d’une seule zone « parce que c’est là qu’était la capacité aujourd’hui » — vous échangez une erreur de lancement passagère contre un risque de disponibilité permanent. Et ne couvrez pas le compte de réservations de capacité par peur : les ODCR inutilisées facturent en continu, et réserver de la capacité sans exigence nommable, c’est payer pour de l’anxiété. Réservez ce qui a un dossier d’affaires; restez flexible partout ailleurs.

Erreurs courantes

  • Ouvrir un billet de soutien et attendre, alors qu’une autre zone aurait lancé trente secondes plus tard.
  • Épingler les groupes Auto Scaling ou les modèles de lancement à une seule zone et un seul type, ne laissant à AWS aucune marge pour vous placer.
  • Arrêter les instances GPU rares chaque nuit pour économiser, puis perdre la place de capacité et la journée de travail du lendemain.
  • Confondre les erreurs de capacité avec les erreurs de quota vCPU et demander une augmentation de quota qui ne change rien.

Prévention

  • Étendez chaque groupe Auto Scaling sur au moins deux zones, et configurez plusieurs types d’instance acceptables ou la sélection par attributs.
  • Gardez les modèles de lancement agnostiques à la zone; laissez la liste de sous-réseaux piloter le placement.
  • Réservez de la capacité (ODCR) pour le petit ensemble d’instances où un lancement raté a un vrai coût d’affaires — machines avec état, inférence GPU, cibles de relève.
  • Surveillez les scores de placement Spot ou les métriques d’échec de lancement pour détecter tôt qu’une famille se raréfie dans votre région.
  • Préférez les familles courantes de génération actuelle pour les charges de base; la rareté se concentre dans les types les plus récents et les plus spécialisés.

Les erreurs de capacité récompensent la flexibilité et punissent l’épinglage — les comptes qui ne les remarquent jamais sont ceux qui ont donné à EC2 plus d’une façon de dire oui. 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.