Résumé

  • Le stockage déjà alloué à une instance RDS ne se réduit pas sur cette même instance. Après un nettoyage, la capacité facturée peut donc rester celle du dernier agrandissement.
  • Un déploiement bleu/vert compatible permet de préparer une base plus petite. Le basculement et la conservation éventuelle de l'ancienne base retardent toutefois la disparition de ses coûts.

La fête de départ a deux invités

La nouvelle base de données est en production. Elle est plus petite, elle répond aux applications, et le projet d'économie peut enfin afficher un résultat. Dans le même compte, l'ancienne base continue pourtant d'exister. Elle a perdu son rôle principal, pas nécessairement son utilité, et encore moins son droit à figurer sur la facture.

Ce dénouement est prévu par Amazon RDS. Ses considérations sur les déploiements bleu/vert expliquent que la nouvelle instance de production ne récupère pas l'historique de restauration à un instant donné de l'ancienne. Son propre historique commence à la création de l'environnement vert. La base bleue conserve le sien et ses sauvegardes automatiques jusqu'à sa suppression. La garder en fonctionnement pour couvrir une fenêtre de restauration maintient des frais de calcul et de stockage.

L'économie a donc un calendrier. La taille de la nouvelle base donne une indication sur le régime futur. La durée pendant laquelle l'ancienne reste nécessaire détermine une partie du prix à payer pour y parvenir. Confondre ces deux périodes permet de présenter une économie avant de l'avoir réalisée.

Comment le surplus s'est installé

Le point de départ peut être une décision parfaitement raisonnable : laisser RDS ajouter de l'espace lorsque la base en manque. L'extension automatique réduit le risque de voir une activité buter sur un stockage plein. Elle évite aussi de transformer chaque poussée de données en intervention urgente.

Mais la documentation d'extension automatique donne à cette commodité une direction précise. L'allocation augmente ; elle ne redescend pas automatiquement. Une modification manuelle de la même instance ne permet pas davantage de réduire le stockage déjà alloué. Désactiver l'automatisation laisse en place les agrandissements accomplis.

La tarification de RDS for MySQL porte sur la capacité de stockage provisionnée, avec prise en compte au prorata des changements intervenus pendant le mois. Le volume de données effectivement présent n'est pas cette capacité. Même lorsque le ménage libère réellement de l'espace dans le système de fichiers, le contenant acheté reste de la même taille. L'entreprise peut avoir moins de données à surveiller tout en gardant le même poste de capacité à payer.

Le service a alors fait son travail de protection. Il n'a pas pris en charge le projet de réduction des coûts qui devient intéressant après la disparition du besoin. C'est précisément cette deuxième mission que les organisations oublient volontiers d'attribuer.

Une nouvelle adresse intérieure

Pour les configurations compatibles, AWS propose de créer un environnement vert plus petit puis de le faire devenir la production. L'alternative décrite est une nouvelle instance de moindre capacité, une migration manuelle et un changement des points de connexion. Dans les deux cas, le retour à une taille inférieure passe par une autre instance.

La création du déploiement impose, pour une réduction, une cible supérieure d'au moins 20 % à l'utilisation actuelle. Exemple de calcul, sans client fictif : 500 GiB alloués et utilisés à 50 % donnent 250 GiB occupés ; la formule conduit à un minimum théorique de 300 GiB. La croissance pendant la préparation et les contraintes de la configuration doivent encore trouver leur place dans le choix final.

Réduire le stockage déclenche une mise à niveau de sa configuration. Cette opération sollicite fortement les entrées-sorties et peut prolonger la création. Le chiffre plus modeste choisi dans l'interface n'abrège pas ce travail. Les équipes ont une copie à préparer et à vérifier avant de lui remettre les écritures de production.

Le cas concret est ici une instance RDS for MySQL éligible. La matrice de prise en charge couvre aussi certaines versions de MariaDB et PostgreSQL, mais exclut Db2, SQL Server et Oracle de cette fonction. Le nom commun RDS ne transforme pas les moteurs en configurations interchangeables.

Le bon bouton ne suffit pas à solder l'opération

Lors du basculement, RDS vérifie notamment la santé et le retard de réplication. Le service suspend les nouvelles écritures, coupe les connexions, attend la synchronisation puis réattribue les noms des instances et des points de connexion. La nouvelle production peut ensuite accepter les connexions et les écritures. Promouvoir manuellement l'instance verte en dehors de cette procédure casserait la relation de réplication du déploiement.

Le nom familier revient donc, attaché à une autre ressource. Son identité durable et son passé de restauration restent les siens. Pour une direction financière, ce détail technique explique pourquoi la ligne de coût de l'ancienne base peut survivre à une migration réussie.

La suppression du déploiement bleu/vert ne supprime pas l'environnement bleu. Elle traite l'organisation du déploiement, pas automatiquement toutes ses ressources. Arrêter une instance MySQL conserve également ses frais de stockage. La vérification économique doit donc aller jusqu'aux ressources encore présentes, avec une raison et une durée pour chacune.

Le montant net économisé exige les tarifs réellement applicables, les durées de coexistence, le travail de migration et le besoin de restauration du client. Le mécanisme commercial est, lui, déjà lisible : l'automate agrandit, l'entreprise organise le déménagement. Une baisse d'occupation est le début possible du projet, pas son reçu final.