RDS : 7 leviers d'optimisation de coûts que personne n'active

RDS est souvent la deuxième ou troisième ligne de facture AWS d’une PME, juste derrière EC2. Contrairement à EC2, elle est aussi la ligne la moins auditée : les équipes provisionnent une instance au lancement du produit, activent Multi-AZ « par prudence », et n’y retouchent plus pendant deux ans. Résultat en mission Distribuée : sur une trentaine d’audits RDS menés ces 18 derniers mois, la facture baisse en moyenne de 25 à 40 % après ajustement — sans dégrader la disponibilité.

Deux de ces leviers ont en plus une échéance AWS ferme en 2026. Les ignorer ne coûte pas juste de l’argent, ça expose à une bascule forcée.

Pourquoi RDS coûte plus cher qu’il ne devrait

Trois raisons reviennent systématiquement en audit :

1. Le storage n’a jamais été révisé. RDS ne redimensionne jamais le stockage à la baisse — une instance provisionnée à 500 Go un jour de pic reste à 500 Go pour toujours, même si l’usage réel retombe à 200 Go.
2. Les instances Reserved n’ont jamais été achetées, alors que RDS tourne en continu sur la quasi-totalité des bases de production — c’est exactement le profil d’usage où le engagement tarifaire est rentable dès le 3ᵉ ou 4ᵉ mois.
3. Personne ne remet en question le Multi-AZ et les read replicas une fois activés au lancement, même quand le trafic de lecture réel ne justifie plus la dépense.

Voici les 7 leviers, classés par ordre de priorité pratique.

1. Migrer le stockage magnétique vers gp3 avant le 30 avril 2026

AWS a officiellement annoncé la dépréciation du stockage magnétique (standard) sur RDS. Le calendrier est précis : après le 29 avril 2026, AWS commence la migration forcée des volumes magnétiques restants vers gp3 ; à partir du 1er juin 2026, gp3 devient le type par défaut à la restauration de snapshot ; à partir du 1er juillet 2026, il ne sera plus possible de restaurer un snapshot en stockage magnétique.

Si vous avez encore des instances en stockage magnétique (souvent des bases historiques jamais migrées depuis leur création), c’est le levier le plus urgent — pas seulement pour l’économie, mais parce que la bascule forcée par AWS se fera sans que vous en choisissiez le moment.

L’économie elle-même est réelle : gp3 facture un tarif de base qui inclut 3 000 IOPS et 125 Mo/s de débit sans surcoût, alors que le magnétique et l’io1/io2 facturent séparément chaque IOPS provisionné. Pour une base qui n’a jamais eu besoin de plus de 3 000 IOPS — la majorité des bases de PME — gp3 est structurellement moins cher, migration ou pas.

aws rds describe-db-instances \
  --query "DBInstances[?StorageType=='standard'].[DBInstanceIdentifier,AllocatedStorage,StorageType]" \
  --output table

La migration se fait sans downtime via modify-db-instance --storage-type gp3 (une opération de modification de stockage standard, appliquée en ligne).

2. Plafonner le storage autoscaling

Le storage autoscaling RDS est activé par défaut sur la plupart des instances récentes, et c’est une bonne chose — jusqu’à ce qu’on découvre sa règle la plus importante : il ne redescend jamais. L’augmentation se déclenche quand l’espace libre passe sous 10 % pendant au moins 5 minutes, par paliers de 10 % de la taille actuelle, 5 Go, ou la croissance projetée sur 7 heures (le plus grand des trois) — mais rien ne réduit le volume ensuite, même si l’usage retombe.

Concrètement, un pic ponctuel (import de données, job batch mal calibré, migration de schéma) peut faire grimper une instance de 100 Go à 300 Go en quelques heures, et ces 300 Go resteront facturés indéfiniment même si l’usage réel redescend à 120 Go.

Le correctif est simple et se fait en Terraform :

resource "aws_db_instance" "main" {
  # ...
  allocated_storage     = 100
  max_allocated_storage = 250   # plafond dur — jamais au-delà sans validation manuelle
}

Sans max_allocated_storage défini, l’autoscaling n’a pas de limite haute. Complétez avec une alarme CloudWatch sur FreeStorageSpace à 20 % pour être notifié avant le déclenchement automatique plutôt que de le découvrir sur la facture du mois suivant.

3. Arbitrer entre Reserved Instances et Database Savings Plans

C’est le levier au ROI le plus direct sur une base qui tourne en continu — la majorité des bases de production. Deux mécanismes coexistent et ne se comportent pas pareil :

• RDS Reserved Instances : jusqu’à 69 % de réduction sur 3 ans, mais l’engagement est figé sur une famille d’instance, un moteur et une région précis. Si vous changez de génération d’instance ou de moteur avant l’échéance, le RI est perdu.
• Database Savings Plans : jusqu’à 35 % de réduction, avec plus de flexibilité (couvre plusieurs familles), mais uniquement en engagement 1 an sans paiement initial (No Upfront), et réservé aux instances de génération 7 et plus (db.r7g, db.m7g).

La règle qui ressort de nos audits : pour une base stable depuis plus d’un an, sans projet de changement de moteur ou de famille d’instance à l’horizon, le RI standard reste supérieur de 6 à 9 points de pourcentage. Pour une base encore en évolution d’architecture (migration de moteur prévue, montée en charge non stabilisée), le Database Savings Plan absorbe le changement sans perte d’engagement.

aws rds describe-reserved-db-instances-offerings \
  --db-instance-class db.r7g.xlarge \
  --duration 1y \
  --product-description postgresql \
  --query 'ReservedDBInstancesOfferings[].[FixedPrice,UsagePrice,OfferingType]' \
  --output table

Auditez d’abord la stabilité réelle de l’instance sur les 90 derniers jours (CloudTrail + historique de modification) avant d’engager 1 ou 3 ans.

4. Right-sizer vers Graviton (r7g / m7g)

Sur les moteurs open source (PostgreSQL, MySQL, MariaDB), Graviton2 a apporté jusqu’à 52 % d’amélioration prix/performance par rapport aux instances Intel équivalentes, et Graviton3 ajoute encore 27 % par rapport à Graviton2. C’est l’un des rares changements qui combine un gain de coût direct et un gain de performance — pas un compromis.

La contrainte pratique : la bascule impose un redémarrage de l’instance (ou un failover pour une configuration Multi-AZ), donc elle se planifie en fenêtre de maintenance, pas en pleine journée de production. Vérifiez aussi la compatibilité moteur — les moteurs propriétaires (Oracle, SQL Server) ne tournent pas sur Graviton et suivent un autre levier (voir ci-dessous).

Pour SQL Server et Oracle, AWS a introduit Optimize CPU sur les nouvelles familles d’instances (m7i, r7i, m8i, r8i) : cette fonctionnalité permet de configurer le nombre de vCPU exposés à l’OS indépendamment de la mémoire allouée, ce qui réduit directement les coûts de licence Windows/SQL Server calculés au vCPU — AWS annonce jusqu’à 55 % de réduction de prix sur les nouvelles générations d’instances pour RDS SQL Server. Si vous payez du license-included sur RDS, c’est un levier à vérifier avant tout right-sizing classique.

5. Auditer Performance Insights avant le 30 juin 2026

Deuxième échéance ferme de l’année : AWS a annoncé la fin de vie de la console Performance Insights classique et de sa tarification actuelle au 30 juin 2026, au profit de CloudWatch Database Insights. Le mode Standard reprend la même tarification que Performance Insights aujourd’hui pour la rétention étendue (1 à 24 mois) — donc pas de mauvaise surprise si vous ne touchez à rien.

Le piège est ailleurs : le mode Advanced de Database Insights facture environ 9,125 $/vCPU/mois, soit près de 3,8 fois plus cher que l’ancien palier payant de Performance Insights pour une rétention de 15 mois sur une instance à 2 vCPU. Si votre organisation migre par défaut vers Advanced sans vérifier ce qui est réellement nécessaire, c’est une ligne de facture qui peut quadrupler sans qu’aucune valeur supplémentaire ne soit consommée.

Avant l’échéance : inventoriez les instances avec rétention étendue activée, vérifiez qui consulte réellement ces données (beaucoup sont activées « au cas où » et jamais consultées), et ne migrez vers Advanced que pour les bases où le diagnostic de performance avancé (requêtes cross-instance, corrélation multi-métrique) est un besoin documenté — pas un réflexe.

6. Auditer Multi-AZ et read replicas réellement utilisés

Multi-AZ double le coût de calcul de l’instance (une instance standby synchronisée en continu). C’est justifié pour une base de production avec un SLA de disponibilité réel — ça ne l’est pas pour un environnement de staging ou une base secondaire à faible criticité, où on le retrouve pourtant activé « par défaut » dans une majorité d’audits.

Même logique pour les read replicas : chaque replica est une instance facturée à plein tarif. La question à se poser systématiquement — trafic de lecture réellement dirigé vers le replica (vérifiable via DatabaseConnections et les métriques applicatives), pas juste « on pourrait en avoir besoin un jour ».

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=<replica-id> \
  --start-time $(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 86400 --statistics Average

Un replica avec une moyenne de connexions proche de zéro sur 30 jours est un candidat direct à la suppression.

7. Nettoyer la rétention de snapshots et les copies cross-région

Les snapshots RDS au-delà du volume de stockage alloué à l’instance source sont facturés au Go-mois, indéfiniment, tant qu’ils existent. Sans politique de rétention explicite, ils s’accumulent — c’est particulièrement vrai pour les snapshots manuels créés avant une migration ou un test, jamais nettoyés ensuite.

Les copies cross-région (souvent mises en place pour un plan de reprise d’activité) doublent le coût de stockage du snapshot copié, dans une région généralement plus chère (us-east-1 est la référence tarifaire la moins chère ; eu-west-3 et les régions européennes sont typiquement plus onéreuses). Vérifiez que chaque copie cross-région répond à un besoin de PRA documenté, pas à une case cochée par défaut dans un runbook générique.

AWS Backup permet de définir un cycle de vie automatique (transition + expiration) sur les snapshots — c’est le mécanisme à activer plutôt qu’un nettoyage manuel périodique, qui finit toujours par être oublié.

Combien ça représente en pratique

Sur un audit type PME (10-20 instances RDS, facture mensuelle de l’ordre de 4 000 à 8 000 €), l’empilement des 7 leviers — storage gp3, plafond d’autoscaling, RI/Database SP, right-sizing Graviton, nettoyage Performance Insights, audit Multi-AZ/replicas, nettoyage snapshots — ramène typiquement 25 à 40 % d’économie récurrente, sans dégrader la disponibilité ni la performance. Les deux premiers leviers (storage magnétique, Performance Insights) ont une échéance AWS ferme en 2026 : ils doivent être traités avant les autres, indépendamment du ROI, pour éviter une bascule forcée hors de votre contrôle.

Conclusion

RDS n’est pas une ligne de facture qu’on peut ignorer une fois l’instance lancée. Contrairement à EC2, où le right-sizing est devenu un réflexe FinOps courant, RDS reste sous-audité — largement parce que toucher à une base de données fait peur, à raison. La bonne nouvelle : la majorité de ces 7 leviers ne touchent ni au moteur ni aux données, seulement à la configuration autour (storage, engagement tarifaire, observabilité, topologie de réplication).

Si votre facture RDS n’a pas été auditée depuis plus d’un an, ou si vous avez encore des instances en stockage magnétique, parlons de votre architecture — un audit RDS type prend 3 à 5 jours et identifie l’essentiel de ces 25-40 % avant toute mise en œuvre.