AWS ouvre la réservation de capacité à la demande pour Aurora et RDS, sans engagement

21 octobre 2026. AWS rend disponibles les On-Demand Capacity Reservations pour Amazon Aurora et Amazon RDS. 21 octobre 2026. La capacité peut être réservée immédiatement, sans engagement, ou planifiée 5 à 120 jours à l’avance avec un engagement minimal. 21 octobre 2026. La fonctionnalité est ouverte dans toutes les régions commerciales AWS. Le point qui compte : les opérations de création, restauration, mise à l’échelle et démarrage d’une base peuvent désormais être garanties contre les échecs de type « insufficient capacity ».

Pour un SRE ou un DBRE, c’est la fin d’une angoisse récurrente : lancer une migration ou une bascule en production et voir la création d’instance échouer parce que la zone de disponibilité n’a plus de capacité pour la classe d’instance demandée.

Ce que ça fait, techniquement

Une Capacity Reservation réserve de la capacité de calcul pour des instances Aurora ou RDS dans une ou plusieurs zones de disponibilité d’une région. Vous choisissez la classe d’instance, le moteur — par exemple db.r6g.xlarge sous PostgreSQL ou MySQL —, les AZ et la quantité de capacité réservée par AZ. RDS conserve ensuite cette capacité pour vous, et vous référencez la réservation au moment de créer, restaurer, modifier ou démarrer une instance.

La réservation peut porter sur deux AZ ou plus pour soutenir les déploiements Multi-AZ. C’est le point crucial : une bascule Multi-AZ déplace l’instance vers une autre AZ, et sans capacité réservée dans l’AZ de destination, le failover peut échouer au pire moment.

Le modèle de prix : une assurance, pas un rabais

Le positionnement économique est la partie à comprendre avant de signer. La capacité réservée est facturée au tarif à la demande tant que la réservation est active, que les instances tournent ou non. Les remises de vos Reserved DB Instances ou Database Savings Plans existants s’appliquent automatiquement, mais la réservation elle-même n’ajoute aucune réduction.

Concrètement, deux modes coexistent :

• Immédiate : aucun engagement, annulable à tout moment. Vous payez la capacité dès la création, même si aucune instance ne la consomme.
• Planifiée (5 à 120 jours) : vous réservez à l’avance pour un événement — migration, lancement, pic saisonnier —, avec un engagement minimal de durée.

La nuance est la même que pour les EC2 Capacity Reservations, dont c’est ici le pendant base de données : vous achetez une garantie de disponibilité, pas une économie. Une équipe qui réserve de la capacité « au cas où » et ne l’utilise pas paie deux fois — la réservation, puis les instances.

Quand ça vaut le coût

La fonctionnalité ne se justifie pas partout. Elle cible les opérations où l’échec a un coût direct :

• Migrations : une bascule de base planifiée un week-end ne peut pas se permettre un « insufficient capacity » à 2 h du matin.
• Lancements de produit et pics saisonniers : réserver la classe d’instance visée à l’avance évite de découvrir qu’elle est épuisée le jour J.
• Reprise après sinistre : la capacité réservée dans l’AZ de secours garantit que la restauration aboutit.
• Déploiements haute disponibilité : le Multi-AZ ne protège que si la seconde AZ peut réellement accueillir l’instance.

À l’inverse, une charge stable qui tourne déjà 24/7 a plus intérêt à négocier des Reserved Instances ou un Savings Plan, qui baissent la facture, qu’à réserver de la capacité à la demande. La réservation n’est rentable que là où le risque de capacité est le vrai problème, pas le prix.

Ce que ça change dans l’équilibre des forces

Cette annonce a une portée plus large qu’une simple fonctionnalité. Elle acte que la pénurie de capacité dans certaines régions et classes d’instance — en particulier les instances Graviton et les classes mémoire optimisée prisées des bases de données — est devenue un problème que les clients doivent assurer financièrement, plutôt qu’un incident rare. AWS monétise la rareté : le même mécanisme existe déjà pour EC2, et son extension à RDS et Aurora indique que la demande de capacité de base de données dépasse régulièrement l’offre dans les AZ les plus chargées.

C’est aussi un signal pour le self-hosting : la garantie de capacité est un argument de vente des clouds, mais elle a un coût permanent. Les équipes qui hébergent leurs bases sur du matériel dédié ne paient pas d’« assurance capacité » — elles ont la capacité, point. La contrepartie, c’est qu’elles portent seules le risque de panne et de dimensionnement.

En pratique : la CLI, les quotas et les limites

La création se fait en une commande, via l’AWS CLI ou l’API RDS. Le nom de réservation doit commencer par une minuscule, et l’identifiant généré porte le préfixe dbcr- :

aws rds create-db-capacity-reservation \
  --db-capacity-reservation-name my-reservation \
  --engine postgres \
  --db-instance-class db.r7g.large \
  --availability-zones us-east-1a \
  --capacity-per-availability-zone 3

Pour un déploiement Multi-AZ, listez deux AZ ou plus : la même capacité est réservée dans chacune. Une réservation est ciblée — une instance ne puise dans la réservation que si vous la référencez explicitement, par son nom ou son identifiant.

Deux limites méritent d’être connues avant de compter dessus. D’abord, seules les familles C, M, R, T et X sont éligibles, et les classes M et R doivent être de génération 7 ou plus : db.m7g et db.r7g fonctionnent, db.m6g et db.r6i non. Ensuite, chaque AZ de la réservation doit réserver au moins 32 vCPU — soit, pour une db.r7g.large de 2 vCPU, 16 unités minimum par AZ. Une équipe qui n’a besoin que d’une petite instance de secours se retrouve donc à sur-réserver. La réservation ne couvre que le calcul : pas le stockage, pas les E/S.

À noter aussi : la réservation consomme votre quota d’instances On-Demand — réserver 3 instances sur 3 AZ en consomme 9. Pour une réservation planifiée, l’état passe par assessing puis scheduled avant de devenir active à la date de début ; si AWS ne peut pas livrer la capacité à temps, l’état delayed autorise l’annulation immédiate avec un engagement partiellement levé.

Verdict

Si vous planifiez une migration, un lancement ou une bascule de base critique dans les prochains mois, réservez la capacité dans l’AZ de destination dès maintenant — le mode planifié à 5–120 jours est fait pour ça, et l’échec d’une bascule coûte toujours plus cher que la réservation. Si votre charge est stable et sans événement prévu, n’achetez pas de réservation : négociez des Reserved Instances ou un Savings Plan qui réduisent la facture au lieu de la figer. La règle est simple — réservez quand vous craignez une panne de capacité, négociez quand vous voulez payer moins.

Références

• AWS — Amazon Aurora and Amazon RDS now support On-Demand Capacity Reservations (21 octobre 2026)
• AWS Docs — Amazon RDS On-Demand Capacity Reservations
• AWS Docs — Amazon Aurora On-Demand Capacity Reservations
• changes.watch — AWS: Amazon Aurora and Amazon RDS now support On-Demand Capacity Reservations