Alors que de nombreuses entreprises s'attardent sur des versions anciennes de bases de données hébergées sur Amazon RDS, la facture liée au service de support étendu (Extended Support) d'AWS continue de grimper. Lancé initialement en 2024 pour MySQL 5.7 et PostgreSQL 11, ce programme impose une surtaxe horaire par vCPU, qui s'applique non seulement à l'instance primaire, mais aussi à chaque réplica en lecture et à chaque instance de standby Multi-AZ. Une configuration courante — un primary 16 vCPU, un réplica de même taille et un standby Multi-AZ — peut ainsi générer une surtaxe mensuelle d'environ 3 500 dollars au tarif des années 1 et 2, et jusqu'à 7 000 dollars en année 3.
Le mécanisme de la surtaxe
Pour les instances provisionnées de RDS MySQL et PostgreSQL, la surtaxe est de 0,10 dollar par vCPU et par heure durant les deux premières années de support étendu, puis double à 0,20 dollar en troisième année. Pour Aurora Serverless v2, le tarif est de 0,085 dollar par unité de capacité Aurora (ACU) par heure les deux premières années, et de 0,17 dollar ensuite (dans les régions us-east-1 et us-east-2, avec des variations selon les zones). Cette surtaxe s'ajoute au coût normal de l'instance et apparaît dans le rapport "Cost and Usage Report" sous un libellé spécifique, par exemple Region-ExtendedSupport:Yr1-Yr2:PostgreSQL12.
Les versions concernées évoluent dans le temps. MySQL 5.7 et PostgreSQL 11 sont passés en tarification de troisième année depuis le 1er mars 2026, ce qui a doublé la surtaxe pour ces clusters. PostgreSQL 12 est entré en première année de support étendu en mars 2025 et se trouve donc encore dans la tranche tarifaire des années 1 et 2. PostgreSQL 13 a rejoint le programme le 1er mars 2026, ce qui signifie que les utilisateurs de cette version subissent désormais la surtaxe depuis deux mois, sans que toutes les équipes en aient encore pris conscience. Au terme de trois années de support étendu, AWS force la mise à niveau de la version.
Le multiplicateur souvent négligé
L'erreur la plus fréquente consiste à ne considérer que l'instance primaire. La surtaxe par vCPU s'applique en réalité à chaque instance de base de données en cours d'exécution dans le cluster : le standby Multi-AZ est facturé pour l'intégralité de ses vCPU, et chaque réplica en lecture est également facturé. Dans l'exemple d'un primary 16 vCPU, d'un réplica identique et du standby Multi-AZ, ce sont donc 48 vCPU qui sont soumis à la surtaxe, et non 16. Aucun engagement de réservation (RI) ni "Database Savings Plans" (DBSP) ne couvre cette surtaxe, car il s'agit d'une ligne tarifaire distincte, indépendante des engagements de capacité.
Des leviers à actionner sans attendre la migration
Plusieurs actions peuvent être mises en œuvre dès maintenant pour réduire la facture sans avoir à effectuer la mise à niveau logicielle. L'ordre de priorité varie selon chaque cluster, mais certains leviers sont systématiquement recommandés.
Redimensionner le cluster avec rigueur
Le premier levier est le redimensionnement (right-sizing). Il ne suffit pas de regarder l'utilisation CPU de l'instance primaire. Le diagnostic pertinent repose sur l'analyse des pics soutenus dans quatre dimensions : CPU, pression mémoire (mémoire libérable et ratio de "buffer cache hit" combinés), utilisation des IOPS, et nombre de connexions par rapport à max_connections. Si ces quatre indicateurs restent sous un seuil acceptable, le redimensionnement peut être envisagé. La décision dépend aussi du rôle de l'instance : les réplicas en lecture et les standbys Multi-AZ peuvent souvent être redimensionnés plus agressivement que le primaire, car ils ne portent pas la charge d'écriture.
Réduire le nombre de réplicas inutiles
Beaucoup de clusters conservent des réplicas en lecture qui ne sont plus utilisés, ou qui peuvent être consolidés. Chaque réplica superflu augmente la surtaxe. Une analyse de l'utilisation réelle permet de supprimer ou de redimensionner ces réplicas.
Limiter l'activation Multi-AZ sur les environnements non critiques
Le standby Multi-AZ est précieux pour la haute disponibilité en production, mais il est souvent activé par défaut sur des bases de développement ou de test, où la redondance n'est pas nécessaire. Désactiver Multi-AZ sur ces instances supprime immédiatement la surtaxe correspondante.
Utiliser des instances de type Graviton ? Pas encore possible
Les instances Graviton3 (M7g, R7g) offrent des gains de performance et de coût, mais elles exigent des versions de moteur récentes : MySQL 8.0.28 ou supérieur, PostgreSQL 13.4 ou supérieur. Les clusters en support étendu utilisent des versions trop anciennes pour en bénéficier. Ce levier reste donc inaccessible tant que la mise à niveau n'est pas effectuée.
Planifier la migration pour limiter la durée de la surtaxe
Le seul moyen de supprimer définitivement la surtaxe est de migrer vers une version prise en charge en standard. Cependant, en attendant, les actions ci-dessus permettent de réduire significativement la facture mensuelle. La plupart des équipes ne les ont pas encore mises en œuvre, soit par méconnaissance, soit parce qu'elles supposent à tort que rien ne peut être fait avant la mise à niveau.
