AWS ajoute à EC2 Capacity Manager des vérifications de prise en charge en temps réel et des métriques de satisfaction de capacité, incluses dans AWS Unified Operations : les scores sont indicatifs, pas des engagements, et les chiffres du blog viennent d’une société fictive

Le 4 novembre 2026, AWS a publié dans « What’s New » une annonce disant qu’Amazon EC2 Capacity Manager gagne deux capacités : des vérifications de prise en charge en temps réel et des métriques de satisfaction de la capacité. Une vérification note chaque combinaison de type d’instance et de zone de disponibilité selon sa capacité à satisfaire une demande, sans lancer ni réserver d’instances, avec un score High, Medium ou Low pour chaque option et un score global. Les métriques montrent la capacité réellement livrée, par organisation AWS, compte, Région et charge de travail étiquetée, avec une ventilation par type d’instance et zone. AWS indique que les deux sont incluses dans AWS Unified Operations, le plan de support AWS pour les grandes entreprises qui exécutent des charges critiques, et disponibles dans toutes les Régions commerciales. Ce n’est donc pas une fonction par défaut pour tous les utilisateurs d’EC2.

Le blog AWS Compute publié le même jour donne le détail d’utilisation, mais il suit une société fictive appelée AnyCompany : tous les chiffres précis qu’il contient sont des exemples, pas des mesures de vrais clients. Pour s’en servir, on active Capacity Manager au niveau de l’organisation, depuis le compte de gestion ou un administrateur délégué, ou pour un seul compte, et le compte doit être couvert par AWS Unified Operations. Pour voir les métriques par charge de travail, on peut activer une étiquette comme clé surveillée. La capacité se mesure en vCPU.

La satisfaction comprend quatre métriques au niveau de la demande : vCPU demandés, vCPU livrés, taux de satisfaction de la demande (livré divisé par demandé, pondéré par les vCPU) et nombre moyen de combinaisons type d’instance × zone que chaque demande peut utiliser, une valeur supérieure à 1 indiquant de la souplesse. Le blog précise que les nouvelles tentatives en cinq minutes pour la même configuration comptent une fois, et que les métriques mesurent les lancements réels, pas l’exactitude d’une vérification. Dans l’exemple, la charge search-index a demandé 51 712 vCPU et en a reçu 45 632, soit 88,2 %, avec en moyenne 21 combinaisons utilisables. La charge batch-etl ne pouvait utiliser qu’une combinaison et obtenait 72,8 %. Les taux par combinaison sont généralement plus bas que le taux de la demande, car celui-ci inclut le bénéfice de la diversification. Dans l’exemple, 28 combinaisons font en moyenne 46,6 % seules alors que la demande atteint 88,2 % : l’écart est ce qu’apporte la souplesse. Les trois combinaisons de use1-az5 ont livré 26 880 vCPU, plus de la moitié du total, mais seulement 68,6 à 82,8 % chacune : c’est la zone où ajouter des options ou réserver de la capacité.

Les vérifications relèvent de la planification. On indique le type de marché (à la demande ou Spot), la quantité, les zones et les types d’instance à examiner, ou des plages de vCPU et de mémoire laissant le service choisir les types. La vérification renvoie High, Medium ou Low pour chaque combinaison et un score global ; une vérification peut inclure jusqu’à 10 zones, éventuellement de plusieurs Régions, et jusqu’à 100 combinaisons. L’exemple vérifie 100 instances de cinq types sur trois zones. Le score global est High. r5.16xlarge est High dans les trois zones, r7a.16xlarge n’est High que dans use1-az6, r6a.16xlarge est Medium partout, le nouveau candidat r7i.16xlarge est Medium dans deux zones, et les six autres combinaisons, dont toutes celles de r6i.16xlarge, sont Low. High signifie que la combinaison dispose de plus qu’il n’en faut, Medium qu’elle couvre la demande de justesse, Low qu’elle dispose de moins que demandé.

Le blog énonce deux limites. D’abord, les scores sont indicatifs, pas des engagements : pour être sûr de la capacité au lancement, il faut des réservations de capacité ou des réservations à date future. Ensuite, la vérification se fait à la planification, pas à chaque lancement, car l’appel va vers la Région où Capacity Manager est activé et des appels par lancement ajouteraient une dépendance inter-Régions et épuiseraient le quota horaire. L’exemple révèle aussi un écart facile à manquer : r5.16xlarge est High dans use1-az5 à l’instant de la vérification, alors qu’historiquement il n’y a livré que 82,8 %. La vérification est un jugement sur le présent, le taux de satisfaction un fait sur le passé, et aucun ne remplace l’autre.

Côté configuration, le blog suggère d’ajouter les combinaisons validées à une politique d’instances mixtes d’Auto Scaling, à un parc EC2 Fleet ou à Karpenter, de sorte que la souplesse soit réglée une fois et profite à tous les lancements suivants, puis de confirmer avec le nombre moyen de combinaisons. Pour une capacité de base qui exige une certitude, il propose une réservation de capacité à la demande dimensionnée sur cette base, car elle est facturée qu’elle serve ou non. Sa routine : examiner chaque semaine les taux de satisfaction, ouvrir le détail des charges sous l’objectif et intégrer une vérification de prise en charge à la gestion des changements.

Il faut garder à l’esprit qu’il s’agit d’une annonce et d’un tutoriel d’AWS lui-même. Les chiffres de l’exemple ne représentent pas de vrais clients, les sources ne donnent aucun lien statistique entre scores et réussite réelle des lancements, et l’accès dépend d’abord de la couverture du compte par AWS Unified Operations.