Le problème
La capacité disponible pour les familles d'instances GPU EC2 comme les P5, P4d, G7, G6 et G5 peut être limitée, en particulier lors des pics de demande. Lorsque vous arrêtez une instance, elle repart dans le pool partagé, sans aucune garantie qu'elle soit à nouveau disponible au moment où vous voudrez la relancer.
Une simple maintenance de routine devient alors un pari. Dès que vous arrêtez une instance GPU pour patcher un driver, changer d'AMI, redimensionner le volume racine ou appliquer une mise à jour de l'OS, cette capacité devient accessible à n'importe quel autre client AWS.
Si la demande est forte, vous risquez une erreur InsufficientInstanceCapacity au redémarrage, et votre fenêtre de maintenance de 10 minutes se transforme en heures de tentatives répétées — voire en indisponibilité prolongée, le temps que de la capacité se libère.
Ce que fait concrètement une On-Demand Capacity Reservation
Une EC2 On-Demand Capacity Reservation (ODCR) réserve de la capacité de calcul pour un type d'instance donné, dans une zone de disponibilité précise, aussi longtemps que la réservation reste active. Son intérêt principal : la capacité vous est garantie, qu'une instance soit en cours d'exécution ou non.
C'est exactement ce qui fait des ODCR l'outil adapté à la maintenance. Lorsque vous arrêtez une instance rattachée à une réservation, la capacité réservée reste à votre disposition. AWS la conserve exclusivement pour votre compte. Au redémarrage, AWS garantit que la capacité réservée est bien là.
Quelques caractéristiques importantes
Contrairement à ce que son nom laisse penser, une Capacity Reservation immédiate n'implique aucun engagement à long terme. Elle garantit simplement que la capacité EC2 dont vous avez besoin sera disponible au moment voulu. Si vos plans évoluent ou que vous n'avez plus besoin de cette capacité réservée, vous pouvez annuler la réservation à tout moment. Ni frais d'annulation, ni durée minimale d'engagement.
Le coût d'une Capacity Reservation est identique à celui d'une instance EC2 On-Demand en fonctionnement. Si vous disposez d'un Savings Plans applicable ou de Reserved Instances, le tarif remisé s'applique aussi à la Capacity Reservation. Seule différence : vous continuez à payer la capacité réservée même quand l'instance est arrêtée, jusqu'à l'annulation de la Capacity Reservation ou au redémarrage de l'instance.
Pourquoi c'est décisif pour les opérations de maintenance
Paradoxalement, la maintenance est souvent le moment où vous êtes le plus exposé. Dès que vous arrêtez votre instance, sa capacité repart dans le pool partagé d'AWS. Si un autre client AWS lance une instance équivalente dans la même zone de disponibilité avant votre redémarrage, il peut récupérer la capacité qui hébergeait la vôtre, transformant une fenêtre de maintenance planifiée en indisponibilité imprévue.
Opérations d'arrêt/redémarrage
De nombreuses tâches de maintenance imposent un arrêt/redémarrage complet plutôt qu'un simple reboot :
- Changement d'AMI
- Modification de certains attributs d'instance
Chacune de ces opérations renvoie l'instance dans le pool de capacité partagé.
Maintenance progressive sur une flotte
Lorsque vous patchez une flotte nœud par nœud, vous drainez et arrêtez généralement une instance à la fois. Sans capacité réservée, chaque nœud arrêté risque de ne pas revenir, et vous vous retrouvez avec une flotte durablement plus petite qu'au départ.
Événements matériels planifiés
AWS planifie parfois des interventions de maintenance sur l'hôte sous-jacent (matériel dégradé, retrait d'hôte, etc.). Une Capacity Reservation garantit la capacité de calcul lorsque vous arrêtez puis redémarrez l'instance pour migrer hors de l'hôte concerné.
Comment l'utiliser en pratique
Dans la console EC2, créez une On-Demand Capacity Reservation ouverte correspondant à :
- Type d'instance
- Zone de disponibilité
- Système d'exploitation (Platform)
Dimensionnez la Capacity Reservation pour couvrir le nombre total d'instances du même type (par exemple, g7.xlarge) présentes dans cette zone de disponibilité durant l'opération de maintenance progressive.
Vérifiez que vos instances consomment bien la réservation. Par défaut, les instances EC2 utilisent automatiquement une Capacity Reservation ouverte dès qu'une réservation correspondante est disponible. Assurez-vous que les Capacity Reservations créées sont bel et bien exploitées par vos instances.
Les Capacity Reservations couvrent aussi des cas d'usage plus avancés, comme les Capacity Reservations ciblées pour des workloads spécifiques. Ces scénarios dépassent le cadre de cet article.
Effectuez votre maintenance comme d'habitude :
- Arrêtez l'instance.
- Appliquez les changements nécessaires.
- Redémarrez l'instance.
La capacité restant réservée, l'instance redémarre sans avoir à se battre pour de la capacité GPU disponible.
Une fois la maintenance terminée, annulez la Capacity Reservation si vous n'en avez plus l'usage. Vos instances continueront de fonctionner normalement.
Combien cela a-t-il coûté ?
Pour connaître précisément le montant payé pour la capacité réservée pendant l'arrêt de vos instances, patientez environ 48 heures après la fin de la maintenance. Les données de facturation AWS ne sont pas en temps réel : ces charges peuvent mettre jusqu'à deux jours à apparaître.
Une fois les données de facturation à jour :
- Ouvrez AWS Billing → Bills.
- Recherchez Unused Reservation.
Vous verrez une ligne indiquant :
- Le type d'instance
- Le montant facturé pour la Capacity Reservation pendant qu'elle n'était pas utilisée par une instance en cours d'exécution
Un moyen simple de mesurer le coût de la garantie de capacité durant votre fenêtre de maintenance.
Dans mon cas, la maintenance a duré moins de 30 minutes. Sans Capacity Reservation, j'aurais pu attendre des heures qu'une capacité GPU se libère à nouveau.
En résumé
Les pénuries de capacité font partie du quotidien lorsqu'on exécute des workloads dans un environnement cloud partagé. Heureusement, AWS propose un moyen simple de lever cette incertitude au moment où elle pèse le plus.
Si vous planifiez une maintenance sur des instances GPU — ou sur tout type d'instance EC2 à capacité limitée — une Capacity Reservation temporaire peut faire toute la différence entre une maintenance de routine et des heures d'indisponibilité imprévues.