Ressources

Support étendu EKS et RDS : calendrier de fin 2026, tarifs et calcul de l'exposition

Support étendu EKS et RDS : dates de fin 2026 et 2027, tarif par cluster et par vCPU, formule pour chiffrer l'exposition et ordre des mises à jour.

Par Corentin Mas, publié le 29 septembre 2026 · 20 min de lecture

Base d'expérience : Méthode d'inventaire et de chiffrage établie à partir de la documentation officielle AWS (calendriers de versions, pages et liste de prix, guides EKS et RDS), sans donnée ni configuration client.

Relecture factuelle : Claude Code (revue indépendante déléguée par Corentin Mas, 28/09/2026), le 29 septembre 2026

Un cluster Amazon Elastic Kubernetes Service (EKS) resté sur une ancienne version de Kubernetes, ou une base PostgreSQL ou MySQL restée sur sa version majeure dans Amazon Relational Database Service (RDS), ne tombe pas en panne à la fin du support standard : il change de tarif. Sur EKS, l'heure de cluster passe de 0,10 $ à 0,60 $. Sur RDS, une charge par processeur virtuel (vCPU) et par heure s'ajoute au prix de l'instance, secours Multi-AZ et réplicas compris. Rien ne casse, et la dépense ne se voit qu'à la lecture de la facture.

Faits datés

Cet article établit le calendrier des échéances de l'automne 2026 à l'été 2027, la formule qui chiffre l'exposition d'un parc, l'ordre des opérations pour en sortir par la mise à jour et la routine qui évite de redécouvrir le sujet chaque trimestre, pour la direction technique qui arbitre la charge de travail comme pour la direction financière qui voit la ligne arriver. Les dates et tarifs cités proviennent des calendriers de versions Amazon EKS (1.31 à 1.36), RDS for PostgreSQL et RDS for MySQL, des pages et de la liste de prix AWS et de la politique de versions de PostgreSQL, vérifiés le 28 septembre 2026 ; toute décision doit repartir de ces pages.

Vérifié le 28 septembre 2026

En bref

EKS : 14 mois de support standard, puis 12 mois de support étendu à 0,60 $ par heure de cluster au lieu de 0,10 $ ; la politique qui y conduit est active par défaut et ne se change plus une fois le cluster entré en support étendu.
RDS for PostgreSQL et MySQL : en règle générale jusqu'à trois ans de support étendu facturé par vCPU et par heure, secours et réplicas compris, au tarif doublé la troisième année.
Échéances : MySQL 8.0 payant sur RDS depuis le 1er août 2026 ; EKS 1.31 mis à jour d'office à partir du 26 novembre 2026 ; EKS 1.34 au tarif étendu le 2 décembre 2026 ; PostgreSQL 14 payant sur RDS à partir du 1er mars 2027.
Exposition : clusters × heures × 0,50 $ pour EKS ; vCPU facturés × heures × tarif de l'année et de la région pour RDS.
La mise à jour forcée d'EKS vise la version supportée la plus ancienne, souvent encore en support étendu : elle n'arrête pas la facturation.

Support standard, support étendu, mise à jour forcée

Les deux services prolongent une version contre paiement, mais l'un facture un cluster et l'autre un vCPU. Les confondre fausse toute estimation.

Amazon EKS : 14 mois, puis 12 mois à 0,60 $ l'heure

EKS assure le support standard d'une version mineure pendant 14 mois après sa sortie sur EKS, puis un support étendu de 12 mois. La page de prix fixe l'heure de cluster à 0,10 $ en support standard et à 0,60 $ en support étendu. La liste de prix AWS publie les mêmes montants pour la région Europe (Paris), sur deux types d'usage distincts : l'heure de cluster à 0,10 $ et l'heure de support étendu à 0,50 $. Sur les douze mois de support étendu d'une version, soit 8 760 heures hors année bissextile, la composante de plan de contrôle passe de 876 $ à 5 256 $ par cluster. La facturation étendue commence au début du jour de fin du support standard, en temps universel (UTC+0).

Le comportement à la fin du support standard dépend du champ upgradePolicy.supportType. Avec EXTENDED, réglage par défaut des clusters nouveaux et existants, le cluster entre en support étendu. Avec STANDARD, il est mis à jour automatiquement vers la version suivante, sans charge étendue. Une fois le cluster en support étendu, la politique ne peut plus être changée. À la fin du support étendu, EKS met à jour le seul plan de contrôle vers la version supportée la plus ancienne, par un déploiement progressif ; modules et nœuds restent à mettre à jour. Enfin, un retour à la version précédente reste possible dans les sept jours suivant une mise à jour en place, sauf après une mise à jour automatique de fin de support étendu ; revenir vers une version en support étendu exige de repasser d'abord la politique en EXTENDED, et la facturation étendue reprend.

Le tarif est fixé par cluster, pas par nœud : un cluster de développement de deux nœuds paie le même écart qu'un cluster de production.

Amazon RDS : par vCPU, jusqu'à trois ans

Sur RDS, le support étendu couvre les versions majeures de RDS for MySQL et RDS for PostgreSQL, jusqu'à trois ans après la fin du support standard RDS en règle générale (MySQL 5.7 fait exception, prolongé jusqu'au 30 juin 2029). La facturation commence le lendemain de cette date et dépend du nombre de vCPU, de la région et de l'année d'extension. Les exemples publiés par AWS en région US East (Ohio) donnent 0,100 $ par vCPU-heure en années 1 et 2, puis 0,200 $ en année 3 : deux niveaux de prix, pas trois. Pour la région Europe (Paris), la liste de prix AWS publiée le 24 septembre 2026 indique 0,118 $ puis 0,235 $ par vCPU-heure pour les versions déjà en support étendu.

La charge s'applique à l'instance principale, à chaque instance de secours Multi-AZ et à chaque réplica en lecture sur une version hors support standard. Les remises d'instances réservées ne s'y appliquent pas. En contrepartie, AWS continue de publier des versions mineures portant des correctifs, dont ceux des vulnérabilités publiques (CVE, Common Vulnerabilities and Exposures) critiques et élevées.

L'inscription dépend du paramètre EngineLifecycleSupport (open-source-rds-extended-support ou open-source-rds-extended-support-disabled). Sans précision, l'API, l'interface en ligne de commande et le fournisseur Terraform aws inscrivent l'instance ; seule la console laisse la case décochée par défaut. Un parc géré en infrastructure en tant que code est donc, sauf réglage explicite, inscrit d'office. Désinscrire une instance déjà hors support standard déclenche sa montée automatique vers la version majeure suivante : ce n'est pas un levier d'économie, c'est une montée de version non préparée. À la fin du support étendu, RDS procède de toute façon à cette montée.

Les dates communautaires et RDS ne coïncident pas. PostgreSQL maintient une version majeure cinq ans et cesse de corriger PostgreSQL 14 le 12 novembre 2026, mais RDS garde PostgreSQL 14 en support standard jusqu'au 28 février 2027. La fin de vie communautaire annonce le risque ; la date RDS déclenche la facture.

Ce qui se passe à la fin du support standard

Le schéma suit une version depuis la fin de son support standard jusqu'à la mise à jour automatique, selon le service et le réglage choisi.

Schéma défilable horizontalement ; sa version textuelle complète suit.

Lire le schéma sous forme textuelle

Une version en support standard atteint sa date de fin de support standard.
Sur EKS en politique STANDARD, le cluster est mis à jour automatiquement vers la version suivante.
Sur EKS en politique EXTENDED, réglage par défaut, il paie 0,60 $ par heure de cluster pendant 12 mois.
Sur RDS avec l'inscription active, défaut hors console, l'instance paie une charge par vCPU et par heure pendant au plus trois ans en règle générale.
Sur RDS avec l'inscription désactivée, l'instance subit une montée de version majeure automatique.
Dans les deux services, la fin du support étendu entraîne une mise à jour automatique : du seul plan de contrôle pour EKS, de la version majeure pour RDS.

Modèle explicatif, sans donnée client, d'après les guides EKS et RDS et les pages de prix AWS cités en fin d'article.

Le calendrier de fin 2026 et du premier semestre 2027

Les tableaux reprennent les calendriers officiels consultés le 28 septembre 2026, limités aux versions utiles à une décision sur les douze prochains mois.

Amazon EKS

Fin du support standard, fin du support étendu et état des versions Amazon EKS 1.31 à 1.36
Version	Fin du support standard	Fin du support étendu	État au 28 septembre 2026
1.31	26 novembre 2025	26 novembre 2026	Support étendu, mise à jour forcée imminente
1.32	23 mars 2026	23 mars 2027	Support étendu
1.33	29 juillet 2026	29 juillet 2027	Support étendu
1.34	2 décembre 2026	2 décembre 2027	Standard jusqu'au 2 décembre 2026
1.35	27 mars 2027	27 mars 2028	Standard
1.36	2 août 2027	2 août 2028	Standard

Kubernetes 1.37 est sorti en amont le 26 août 2026 et n'apparaît pas encore dans le calendrier EKS consulté.

Amazon RDS for PostgreSQL et RDS for MySQL

Fin du support standard RDS, début de facturation, début du tarif de l'année 3 et état des versions RDS for PostgreSQL et RDS for MySQL
Version	Fin du support standard RDS	Facturation dès le	Tarif année 3 dès le	État au 28 septembre 2026
PostgreSQL 11	29 février 2024	1er avril 2024	1er avril 2026	Support étendu, année 3, jusqu'au 31 mars 2027
PostgreSQL 12	28 février 2025	1er mars 2025	1er mars 2027	Support étendu, années 1 et 2
PostgreSQL 13	28 février 2026	1er mars 2026	1er mars 2028	Support étendu, années 1 et 2
PostgreSQL 14	28 février 2027	1er mars 2027	1er mars 2029	Standard
MySQL 5.7	29 février 2024	1er mars 2024	1er mars 2026	Support étendu, année 3, jusqu'au 30 juin 2029
MySQL 8.0	31 juillet 2026	1er août 2026	1er août 2028	Support étendu, années 1 et 2

PostgreSQL 11 fait exception : entré en support étendu le 1er mars 2024, il n'a été facturé qu'à partir du 1er avril 2024.

La colonne « Tarif année 3 » applique la règle publiée par AWS : le tarif de l'année 3 s'applique à partir du premier jour de la troisième année de facturation. MySQL 5.7 et 8.0 sont désormais tous deux en support étendu sur RDS ; celui de MySQL 5.7 a été prolongé jusqu'au 30 juin 2029.

Ce qui change entre novembre 2026 et mars 2027

26 novembre 2026 : fin du support étendu d'EKS 1.31 ; mise à jour forcée vers 1.32, lui-même en support étendu.
2 décembre 2026 : EKS 1.34 passe à 0,60 $ en politique EXTENDED, ou est mis à jour vers 1.35 en politique STANDARD.
1er mars 2027 : PostgreSQL 14 devient payant sur RDS ; PostgreSQL 12 passe au tarif double de l'année 3.
23 mars 2027 : mise à jour forcée d'EKS 1.32 vers 1.33, toujours en support étendu.
31 mars 2027 : fin du support étendu de PostgreSQL 11 sur RDS ; les instances restantes sont montées automatiquement de version majeure.

D'après le calendrier et la règle de mise à jour vers la version supportée la plus ancienne, un cluster laissé sur 1.31 passe à 1.32 fin novembre, à 1.33 fin mars, à 1.34 fin juillet 2027 : des mises à jour non planifiées du plan de contrôle, sans jamais cesser de payer 0,60 $ de l'heure.

Chiffrer son exposition : clusters, instances, vCPU

Le chiffrage part d'un inventaire, pas de la facture : la facture dit ce qui a été payé, l'inventaire rapproché du calendrier dit ce qui va l'être. Les commandes suivantes sont en lecture seule.

Inventaire

# EKS : nom, version et politique de chaque cluster. Répéter par compte et par région.
REGION=eu-west-3
for c in $(aws eks list-clusters --region "$REGION" --query 'clusters[]' --output text); do
  aws eks describe-cluster --region "$REGION" --name "$c" \
    --query '[cluster.name, cluster.version, cluster.upgradePolicy.supportType]' --output text
done

# RDS for PostgreSQL et MySQL (Aurora exclu, calendriers distincts).
aws rds describe-db-instances --region "$REGION" \
  --query "DBInstances[?Engine=='postgres' || Engine=='mysql'].[DBInstanceIdentifier, EngineVersion, DBInstanceClass, MultiAZ, ReadReplicaSourceDBInstanceIdentifier, EngineLifecycleSupport]" \
  --output table

La sortie RDS ne donne pas le nombre de vCPU : il se lit par classe dans la page « Hardware specifications for DB instance classes » de la documentation RDS ou dans la colonne vCPU de la liste de prix (2 vCPU pour db.m6g.large, 4 pour db.r6g.xlarge, 8 pour db.r6g.2xlarge).

Les deux formules

écart EKS = clusters en support étendu × heures de la période × 0,50 $

charge RDS = vCPU de la classe × instances facturées × heures de la période × tarif de l'année d'extension dans la région

Les instances facturées comptent l'instance principale, chaque secours Multi-AZ et chaque réplica sur la même version majeure ; c'est la méthode d'estimation publiée par AWS. Les heures se comptent depuis le début du palier, et une période qui chevauche le passage à l'année 3 se découpe en deux.

Exemple fictif

Exemple fictif. Les parcs ci-dessous sont inventés et ne décrivent aucune organisation. La période est un trimestre de 90 jours, soit 2 160 heures. Les tarifs RDS sont ceux de l'exemple public AWS en région US East (Ohio) ; pour un parc en Europe (Paris), remplacez-les par 0,118 $ et 0,235 $.

Exemple fictif : écart de support étendu EKS sur 90 jours après le 2 décembre 2026, par cluster
Cluster EKS (fictif), 90 jours après le 2 décembre 2026	Version	Heures en support étendu	Écart à 0,50 $
Production	1.34	2 160	1 080 $
Préproduction	1.34	2 160	1 080 $
Développement 1	1.33	2 160	1 080 $
Développement 2	1.33	2 160	1 080 $
Outillage	1.35	0	0 $
Total		8 640	4 320 $

Exemple fictif : charge de support étendu RDS sur 90 jours à partir du 1er mars 2027, par base
Base RDS (fictive), 90 jours à partir du 1er mars 2027	Version et année	Instances facturées	vCPU facturés	Tarif	Charge
Base A, classe à 4 vCPU	PostgreSQL 13, année 2	principale, secours, 1 réplica	12	0,100 $	2 592 $
Base B, classe à 2 vCPU	PostgreSQL 12, année 3	principale	2	0,200 $	864 $
Base C, classe à 2 vCPU	MySQL 8.0, année 1	principale	2	0,100 $	432 $
Base D, classe à 8 vCPU	PostgreSQL 16, standard	principale, secours	0	sans objet	0 $
Total			16		3 888 $

La structure compte plus que le total : secours et réplica triplent les vCPU facturés de la base A, la base B paie le double par vCPU depuis son passage en année 3, et les deux clusters de développement coûtent autant que la production et la préproduction réunies. PostgreSQL 14 entre en support étendu le premier jour de cette période, mais la liste de prix AWS consultée le 28 septembre 2026 (régions Ohio et Paris) ne publie pas encore son tarif : relevez-le au moment du calcul plutôt que de le supposer.

Chiffrage fondé sur vos données

CTN Solutions ne publie aucun pourcentage d'économie type : les écarts dépendent des usages réels et des contrats en cours.

Recouper avec l'export de coûts

AWS indique que le support étendu RDS apparaît comme une ligne distincte, filtrable dans Cost Explorer par un type d'usage contenant ExtendedSupport. La liste de prix nomme aussi le type d'usage du support étendu EKS : pour la région Europe (Paris), EUW3-AmazonEKS-Hours:extendedSupport, distinct de l'heure de cluster EUW3-AmazonEKS-Hours:perCluster. Dans un export Cost and Usage Report (CUR) 2.0 :

-- Lecture seule. line_item_resource_id exige un export avec données de ressources.
SELECT line_item_usage_account_id, line_item_product_code, line_item_resource_id,
       line_item_usage_type,
       sum(line_item_usage_amount)   AS quantite,
       sum(line_item_unblended_cost) AS cout_non_combine
FROM cur2.cur2
WHERE bill_billing_period_start_date = TIMESTAMP '2026-08-01 00:00:00'
  AND line_item_line_item_type = 'Usage'
  AND line_item_product_code IN ('AmazonEKS', 'AmazonRDS')
  AND lower(line_item_usage_type) LIKE '%extendedsupport%'
GROUP BY 1, 2, 3, 4
ORDER BY cout_non_combine DESC;

La quantité se lit en heures de cluster pour EKS et en vCPU-heures pour RDS. Rapprochez chaque ligne des clusters et instances de l'inventaire avant de conclure : un nom de type d'usage se vérifie dans votre propre export, région par région. Les règles de lecture de l'export sont détaillées dans « Coût facturé, coût amorti, crédits : réconcilier des montants AWS qui ne tombent jamais juste ».

Mettre à jour plutôt que payer

Sortir du support étendu, c'est revenir sur une version en support standard. La commande tient en une ligne ; la difficulté est le choix de la cible et la préparation.

Choisir la version cible

Sur EKS, une mise à jour ne franchit qu'une version mineure : passer de 1.33 à 1.36 en demande trois. Monter de 1.33 à 1.34 en novembre 2026 ne fait gagner que quelques jours avant le 2 décembre ; viser 1.35 (standard jusqu'au 27 mars 2027) ou 1.36 (jusqu'au 2 août 2027) sort réellement le cluster du support étendu. Sur RDS, certaines montées de version peuvent sauter une version majeure : pour PostgreSQL 14, viser 16 ou 17 (support standard RDS jusqu'au 28 février 2029 ou 2030) évite de refaire l'exercice en 2028, sous réserve des extensions utilisées. Pour MySQL 8.0, la cible est 8.4.

Sur EKS

Fixer la politique tant que le cluster est en support standard. STANDARD évite toute charge étendue au prix d'une mise à jour à date imposée, ce qui convient hors production ; EXTENDED reste un filet de sécurité en production si une date de mise à jour est planifiée. Commande : aws eks update-cluster-config --name <cluster> --upgrade-policy supportType=STANDARD.
Lire les cluster insights, rafraîchis toutes les 24 heures, qui signalent notamment les appels à des API Kubernetes supprimées dans la version suivante : aws eks list-insights --cluster-name <cluster> --filter categories=UPGRADE_READINESS.
Vérifier les nœuds. Un kubelet en 1.25 ou plus tolère un plan de contrôle trois versions plus récent. Vérifier aussi la famille d'image machine (AMI) : 1.32 est la dernière version avec des AMI Amazon Linux 2 ; à partir de 1.33, seules Amazon Linux 2023 et Bottlerocket sont publiées. Un parc encore sous Amazon Linux 2 transforme la montée de version en migration de système d'exploitation.
Vérifier l'adressage : jusqu'à cinq adresses IP libres dans les sous-réseaux du cluster.
Mettre à jour le plan de contrôle, une version à la fois (plusieurs minutes chacune), puis les modules VPC CNI, CoreDNS et kube-proxy, puis les nœuds.

Une montée de plusieurs versions se planifie donc version par version, chacune validée avant la suivante. Sa durée dépend du nombre de versions à franchir, de l'état des nœuds et des points relevés par les insights, pas de la commande elle-même : c'est ce travail préparatoire qu'il faut chiffrer en regard du support étendu.

Pour faire de ces mises à jour un geste courant de la plateforme, voir la page Optimisation Kubernetes : mesurer, changer, vérifier.

Sur RDS

Pour PostgreSQL, la procédure AWS tient en quatre temps : groupe de paramètres pour la version cible ; levée des bloquants (transactions préparées, types de données de la famille reg hors regclass et regtype, bases invalides, emplacements de réplication logique, réplicas, extensions comme PostGIS) ; instantané et répétition sur une copie restaurée, en lisant pg_upgrade_precheck.log ; mise à jour de la production puis ANALYZE. Un déploiement bleu/vert monte la version sur un environnement synchronisé ; la bascule interrompt le service généralement moins d'une minute, parfois plus selon la charge.

Pour MySQL 8.0 vers 8.4, AWS documente des changements de comportement : caching_sha2_password devient le plugin d'authentification par défaut ; mysql_native_password, déprécié, reste utilisable par les comptes existants sur RDS for MySQL 8.4 mais disparaît après cette version ; SOURCE et REPLICA à la place de MASTER et SLAVE, nouveaux mots réservés, valeurs par défaut d'InnoDB modifiées. RDS exécute des prévérifications et annule la mise à jour en cas d'incompatibilité, avec un rapport dans PrePatchCompatibility.log. Les comptes applicatifs en mysql_native_password sont le premier point à inventorier.

Quand payer est défendable

Une base décommissionnée dans quelques mois, ou une montée de version bloquée par une dépendance tierce, peut justifier un support étendu borné par une date de sortie, un propriétaire et un budget. Désinscrire une instance RDS déjà hors support standard pour « arrêter la facture » ne l'est jamais : c'est une montée de version majeure sans préparation.

En faire une routine FinOps et plateforme

Le support étendu revient chaque trimestre. Il se range dans la boucle FinOps habituelle : rendre visible, attribuer, décider, vérifier.

La boucle trimestrielle du support étendu

Le schéma décrit la routine qui transforme le calendrier AWS en décisions datées, puis en contrôle dans l'export de coûts.