Summary

  • À l'état scheduled, AWS a accepté une réservation future RDS : aucun frais ne s'applique encore, mais l'annulation est fermée. Une fois la capacité active, l'engagement doit arriver à son terme pour permettre une annulation ordinaire.
  • Les réservations futures imposent au moins 14 jours et 32 vCPU dans chaque zone de disponibilité ; la famille X exige 12 semaines. Un exemple minimal sur deux zones en db.r7g.large représente 32 places de capacité de base de données.

Trente-deux places pour un rendez-vous qui peut bouger

Un lancement peut changer de date pendant une réunion. Une réservation de capacité acceptée par AWS conserve ses propres échéances. Depuis l'annonce du 21 octobre, Aurora et RDS permettent de réserver du calcul adapté aux créations, restaurations, démarrages et changements de puissance d'instances, dans les régions commerciales d'AWS.

La protection a un intérêt évident pour un événement dont l'ouverture dépend d'une capacité précise. Le choix financier commence lorsque le fournisseur accepte une date future. Le guide des états appelle cet état scheduled et indique qu'aucun frais ne s'applique encore. Le guide d'annulation ferme pourtant la sortie à ce stade.

Le tableau de facturation peut ainsi rester calme après une décision devenue contraignante. Pour les achats, le prochain indicateur utile est l'état de la réservation. Pour l'équipe commerciale, c'est la date de lancement. Ces deux calendriers doivent se rencontrer avant l'acceptation.

Le plancher porte sur chaque zone

Une réservation immédiatement active peut être annulée selon les besoins, sans durée d'engagement. Une réservation future se programme de cinq à 120 jours à l'avance et impose au moins 14 jours ; pour la famille X, le minimum atteint 12 semaines. Le seuil de 32 vCPU s'applique à chaque zone de disponibilité choisie.

Le guide donne db.r7g.large comme unité de deux vCPU. Prenons un exemple construit au minimum sur deux zones : il faut 16 unités par zone, donc 32 places de capacité au total, avec un engagement d'au moins 14 jours. Le calcul compte des unités réservées dans deux zones ; l'empreinte comprend aussi les places nécessaires au côté de secours d'un déploiement Multi-AZ.

Une demande formulée comme « garder de la place pour la migration » contient donc une quantité et une durée que son responsable doit financer. Un événement court peut justifier cette protection plus longue. Il faut que son budget en porte la décision au moment de choisir le créneau.

L'état du fournisseur commande l'annulation

Pendant l'évaluation, à l'état assessing, le client peut retirer sa demande. Une fois scheduled, la réservation reste en place jusqu'au démarrage ; après activation, l'annulation attend la fin de l'engagement. Le guide prévoit une sortie immédiate à l'état delayed lorsque AWS n'a pas livré la capacité à la date demandée. Cette exception suit le retard du fournisseur. Le report du projet par le client ne suffit pas à produire cet état.

La personne capable de déplacer une campagne doit donc voir le début, la fin d'engagement et l'état de la réservation associée. Une date déplacée dans le plan projet ne libère aucune capacité à elle seule. L'autorisation d'acheter ce créneau mérite le même propriétaire économique que la décision de le déplacer.

Arrêter l'instance conserve la place

Le guide de facturation fait démarrer les frais lorsque la capacité est provisionnée dans le compte. Une unité active inutilisée est facturée au tarif On-Demand équivalent. Lorsqu'une instance correspondante l'occupe, le client paie l'instance et aucune ligne de réservation supplémentaire pour cette unité.

Arrêter la base transforme sa capacité en réservation inutilisée, dont le coût se poursuit. L'annulation admissible ou la date de fin met un terme aux frais de réservation. Le stockage, les entrées-sorties et les autres ressources suivent leur facturation habituelle. Les remises applicables peuvent venir des Reserved DB Instances ou des Database Savings Plans.

L'arrêt technique et la libération du créneau sont donc deux actions avec des propriétaires et des conditions propres. La première peut être achevée alors que l'engagement d'achat continue.

Le créneau acheté doit aussi servir

Les règles de placement exigent de cibler explicitement le nom ou l'identifiant de la réservation. Moteur, classe d'instance, modèle de licence concerné et zone doivent correspondre, avec de la capacité disponible. Pour Multi-AZ, les zones du primaire et du secours doivent toutes deux disposer de place. Le budget se transforme en protection lorsque le déploiement utilise effectivement ce qui a été réservé.

La libération a elle aussi une valeur opérationnelle à comparer. Selon l'API d'annulation, une instance existante continue de tourner sans modification après annulation. La capacité réservée est libérée ; un déplacement ultérieur de matériel peut alors rencontrer une insuffisance de capacité. Le choix porte aussi sur la prochaine opération, au-delà du lancement initial.

Les historiques et frais des réservations clients ne sont pas disponibles ; ils permettraient de mesurer le coût réel des engagements restés vides. La règle publique suffit à placer la décision : AWS fournit un accès anticipé à une capacité déterminée, le client finance le risque de déplacer son propre événement. La signature compte avant scheduled. Le premier débit arrive après une partie du choix.

Sources