Aller au contenu

AWS Mis à jour le 2026-07-04

Optimisation des coûts RDS : les leviers qui ne mettent pas la base de données à risque

Optimiser les coûts AWS RDS sans mettre les données en danger : migration du stockage vers gp3, redimensionnement prudent, instances réservées, hygiène des instantanés et arrêt des bases non productives.

La base de données est la seule partie de la pile où une expérience de coûts peut devenir un incident de données. Le travail de coûts RDS doit donc commencer par les leviers sans risque pour les données : migrer le stockage gp2 vers gp3, acheter des instances réservées sur les charges qui ont prouvé leur stabilité, supprimer les instantanés manuels orphelins et arrêter les bases non productives hors des heures de travail. La réduction de classe d’instance et les coupes d’IOPS provisionnées viennent après — avec des mesures, pas des impressions. Dans cet ordre, la plupart des factures RDS descendent visiblement sans un seul changement risqué sur le chemin de production.

Ce qui se passe

Une facture RDS a quatre lignes principales qui répondent à des leviers différents. Les heures d’instance — la classe que vous roulez, fois deux si Multi-AZ, fois chaque réplique. Le stockage et les IOPS — les Go alloués (pas utilisés : RDS facture ce que vous avez alloué, et on ne peut pas rétrécir le stockage alloué sans une migration par sauvegarde-restauration) plus les IOPS provisionnées si vous en avez acheté. Les sauvegardes et instantanés — le stockage de sauvegarde automatique au-delà de la franchise de votre fenêtre de rétention, et chaque instantané manuel pour toujours jusqu’à ce que quelqu’un le supprime. Le transfert de données — surtout la réplication inter-AZ et les répliques inter-régions.

Les leviers sûrs attaquent ces lignes sans toucher à la durabilité : la conversion gp2 vers gp3 est un changement de type de stockage en ligne, même durabilité et, à la plupart des tailles, coût au Go plus bas; les instances réservées RDS sont une pure construction de facturation sans empreinte technique; la suppression d’instantanés ne touche que des copies dont vous avez vérifié la rétention; arrêter une instance de dev la nuit ne change rien aux données. Les leviers risqués sont ceux qui changent la capacité : classe plus petite, moins de répliques, abandon du Multi-AZ. Parfois justifiés, mais ce sont des décisions de performance et de disponibilité déguisées en décisions de coûts.

Quoi vérifier d’abord

  • Le type de stockage par instance. Tout volume gp2 est candidat au gp3 à performance de base égale ou meilleure. Voyez RDS > Databases > (instance) > Configuration.
  • La couverture en instances réservées. Des bases de production stables facturées sur demande depuis plus d’un an : le surcoût RDS le plus fréquent.
  • Le nombre et l’âge des instantanés manuels. Les sauvegardes automatiques expirent; les instantanés manuels, jamais.
  • Les instances non productives qui roulent 24/7. Les bases de dev et de recette dorment 128 des 168 heures de la semaine.
  • Les IOPS provisionnées contre les IOPS consommées. Des volumes io1/io2 achetés pour un test de charge il y a trois ans facturent encore.

Comment vérifier

# Inventaire : classe, moteur, type de stockage, Multi-AZ
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,DBInstanceClass,Engine,StorageType,AllocatedStorage,MultiAZ]' \
  --output table

# Instantanés manuels, du plus vieux au plus récent
aws rds describe-db-snapshots --snapshot-type manual \
  --query 'sort_by(DBSnapshots,&SnapshotCreateTime)[].[DBSnapshotIdentifier,DBInstanceIdentifier,SnapshotCreateTime,AllocatedStorage]' \
  --output table

# Cette base est-elle vraiment utilisée? Connexions sur 30 jours
aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=staging-db \
  --start-time 2026-06-04T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Maximum

# Consommation réelle d'IOPS contre ce qui est provisionné
aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name WriteIOPS \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db \
  --start-time 2026-06-27T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Maximum

Console : RDS > Databases > (instance) > Monitoring pour les graphiques d’utilisation; Performance Insights (le palier de rétention de sept jours est gratuit) pour savoir si la pression CPU est réelle. Le comportement des modifications de stockage varie selon le moteur et le type de stockage — vérifiez votre cas dans la documentation RDS avant de planifier quoi que ce soit.

Le plan d’exécution

  1. Convertissez gp2 en gp3. Modification en ligne, pas d’indisponibilité pour le changement de stockage lui-même, et la base gp3 (3 000 IOPS, 125 Mo/s) bat les petits volumes gp2 dont les IOPS suivaient la taille. Vérifiez la performance pour les volumes de plus de ~1 To, où les IOPS gp2 pouvaient dépasser la base gp3 — provisionnez la différence explicitement au besoin.
  2. Supprimez les instantanés manuels vérifiés obsolètes. Tout ce qui vient d’instances démantelées, de points de contrôle pré-migration dépassés ou de moments « avant la mise à niveau » des années passées. Gardez ce que votre politique de rétention exige vraiment — la stratégie est détaillée dans l’article PITR et stratégie d’instantanés.
  3. Achetez des instances réservées RDS sur ce qui est prouvé stable. Un an, sans paiement initial, sur les instances de production qui roulent la même classe depuis six mois ou plus. Flexibles en taille dans la même famille et le même moteur : un passage ultérieur de db.r6g.xlarge à db.r6g.2xlarge reste couvert proportionnellement.
  4. Arrêtez le non-productif hors des heures. Une instance RDS arrêtée cesse de facturer les heures d’instance (le stockage facture encore) — mais AWS la redémarre automatiquement après sept jours, donc l’automatisation doit ré-arrêter, pas arrêter une fois. EventBridge Scheduler plus une petite Lambda font l’affaire.
  5. Redimensionnez les IOPS provisionnées avant la classe d’instance. Si les IOPS consommées plafonnent à une fraction de l’io1/io2 provisionné, passer à gp3 avec des IOPS supplémentaires explicites est souvent moins cher et sans risque de données.
  6. Réduisez la classe d’instance en dernier, avec des preuves. p95 CPU sous ~30 %, aucune pression mémoire (surveillez FreeableMemory et le swap), et Performance Insights qui montre de la marge. En Multi-AZ, la modification bascule au lieu d’arrêter brutalement — brève interruption, donc planifiez. Une taille à la fois.
  7. Questionnez les répliques, ne les coupez pas par réflexe. Une réplique de lecture que personne n’interroge est du coût pur; une qui absorbe les rapports protège la production. Vérifiez ses ReadIOPS et ses connexions avant de décider. Si vous pesez un changement au niveau du moteur, la comparaison Aurora vs RDS couvre les cas où le modèle de coûts lui-même change.

Quand c’est le mauvais choix

Ne retirez jamais le Multi-AZ de la production pour économiser — c’est vendre votre basculement, et le premier événement d’AZ non planifié en donnera le vrai prix. Ne rétrécissez pas le stockage alloué en espérant un remboursement : le stockage RDS ne fait que croître, et une réduction exige une migration complète par sauvegarde-restauration. Et sautez complètement les coupes de classe d’instance sur les bases à portée d’un événement de trafic (lancement, campagne, pointe saisonnière) — une base qui tombe coûte plus qu’une année de l’économie.

Erreurs courantes

  • Arrêter une RDS de dev une fois et croire qu’elle reste arrêtée — le redémarrage automatique de sept jours relance la facturation en silence.
  • Supprimer un instantané manuel qui était la seule copie d’un système démantelé qu’un auditeur demandera plus tard.
  • Réduire la classe sur la base du CPU moyen pendant que FreeableMemory était déjà près de zéro.
  • Acheter des RI de trois ans sur une version de moteur que l’équipe planifie activement de quitter.

Garder le contrôle

  • Étiquetez chaque instance RDS avec environnement et responsable; alertez sur toute instance non productive qui roule à 3 h du matin.
  • Revoyez les instantanés manuels chaque trimestre avec une décision garder/supprimer explicite par instantané.
  • Suivez la couverture et l’utilisation des RI RDS séparément d’EC2 — ce sont des programmes d’achat différents.
  • Surveillez la croissance de FreeStorageSpace pour planifier les augmentations de stockage délibérément au lieu de surallouer d’avance.
  • Rechassez les restants de gp2 après chaque restauration ou nouvel environnement — les vieilles habitudes les recréent.

Le motif à travers tout ça : les leviers côté facturation d’abord, les leviers côté capacité seulement avec des mesures. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.