Aurora Serverless v2 : comportement réel de mise à l'échelle, coûts plancher, et quand ça convient vraiment

Aurora Serverless v2 fait monter et descendre la capacité de la base par petits paliers pendant que les connexions restent ouvertes, ce qui le rend vraiment bon pour les charges en pics ou souvent inactives. Mais ce n’est pas « payer seulement pour les requêtes » : à moins de configurer un minimum de zéro et d’accepter des pauses, la capacité minimale que vous fixez tourne 24 h sur 24, et à charge élevée constante, une ACU-heure coûte plus cher que l’instance provisionnée équivalente. La décision est une question d’utilisation, pas une question de mode.

Ce que vous décidez

La capacité Serverless v2 se mesure en ACU — chacune environ 2 Gio de mémoire avec le CPU et le réseau correspondants. Vous fixez un minimum et un maximum par instance; la plage pratique va de 0 (auto-pause) ou 0,5 ACU jusqu’à 256. La mise à l’échelle est sur place et incrémentale : pas de failover, pas de coupure de connexion, capacité ajoutée par fractions d’ACU en secondes, et la vitesse de mise à l’échelle croît avec la taille courante — une instance occupée à 64 ACU ajoute de la capacité beaucoup plus vite qu’une autre qui tourne au ralenti à 1.

Trois comportements comptent plus que la brochure :

Le plancher tourne jour et nuit. Un minimum de 2 ACU est facturé chaque heure du mois, qu’on interroge la base ou non. Multipliez par le writer plus les readers plus les environnements et l’hypothèse « serverless coûte moins cher » meurt en silence. Fixer le minimum à 0 active l’auto-pause après une période d’inactivité, et la reprise prend de l’ordre de quinze secondes — correct pour une base de dev, inacceptable pour tout ce qu’un client touche.

La vitesse de montée dépend du point de départ. Depuis un plancher de 0,5 ACU, absorber un pic soudain prend nettement plus longtemps que depuis 4 ACU, et le buffer pool d’un plancher minuscule est froid — les premières minutes d’un pic tournent avec de mauvais taux de cache même une fois le CPU rattrapé. Les équipes qui fixent le plancher purement au coût blâment ensuite Aurora pour les matins lents.

La charge constante se paie plus cher qu’en provisionné. Le tarif par ACU-heure (qui varie selon la région et la configuration Standard vs I/O-Optimized du cluster) est fixé pour que la flexibilité se paie une prime. Une charge qui reste à 80 % d’utilisation toute la journée appartient aux instances provisionnées — modélisez les deux honnêtement dans le calculateur de prix AWS avant de décider. Vous pouvez aussi mélanger : un writer provisionné avec des readers Serverless v2 dans le même cluster est un patron légitime pour du trafic de lecture en pics.

Savoir si Aurora lui-même est la bonne plateforme par rapport à RDS standard est une question distincte — voir Aurora vs RDS pour Postgres / MySQL en production. Les détails de capacité par version de moteur sont dans la documentation Aurora sur https://docs.aws.amazon.com/rds/.

Quoi vérifier en premier

• Votre vraie courbe d’utilisation — une semaine de CPU et de mémoire sur la base actuelle. Courbe plate : provisionné. Grands pics au-dessus d’une base faible, ou longues périodes creuses : territoire Serverless v2.
• Tolérance à l’inactivité — quelque chose de visible par l’utilisateur peut-il attendre ~15 secondes à la reprise? Sinon, le minimum 0 est exclu pour cette instance.
• Fonctionnalités gourmandes en mémoire — forte dépendance au buffer pool, gros tris, nombreuses connexions consomment tous des ACU; la pression mémoire, pas le CPU, fixe souvent votre vrai plancher.
• Support de version du moteur — Serverless v2 exige des versions raisonnablement récentes d’Aurora MySQL et Aurora PostgreSQL.
• Gestion des connexions — les applications qui gardent des centaines de connexions inactives épinglent la capacité; RDS Proxy ou un pool de connexions change le calcul.

Comment vérifier

Regardez ce que la capacité fait réellement sur une vraie semaine :

aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value=prod-aurora \
  --start-time 2026-06-27T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Average Maximum

ACUUtilization vous dit à quel point vous frôlez votre maximum configuré — des valeurs soutenues près de 100 % signifient que le max vous étrangle. Dans la console, RDS > Databases > (cluster) > Configuration montre la plage de capacité, et l’onglet Monitoring trace ServerlessDatabaseCapacity à côté du CPU et des connexions. Comparez la moyenne d’ACU consommées à la classe d’instance provisionnée qui couvre votre p95 — cette comparaison, chiffrée, est toute la décision.

L’approche

1. Classez la charge par sa forme. En pics, diurne, multi-tenant avec des locataires tranquilles, dev/test, nouveau produit imprévisible : candidats Serverless v2. Plate et occupée : provisionné, point final.
2. Fixez le plancher selon la performance, pas la facturation. Choisissez le minimum qui garde le buffer pool assez chaud pour votre jeu de travail et absorbe la première minute d’un pic — puis vérifiez ce que ce plancher coûte par mois et confirmez que l’entreprise l’accepte.
3. Fixez le plafond comme protection, pas par optimisme. Le maximum est votre disjoncteur de coûts; une requête en fuite à 256 ACU est un incident dispendieux. Plafonnez là où la charge a déjà légitimement eu besoin d’aller, plus une marge.
4. Utilisez le minimum 0 seulement là où les pauses ne coûtent rien. Dev, staging, outils internes, bases de CI — l’auto-pause y est de l’économie pure. Gardez les planchers de production au-dessus de zéro.
5. Mélangez provisionné et serverless délibérément. Un writer provisionné pour la charge d’écriture stable, des readers Serverless v2 qui suivent les pics de lecture : souvent le meilleur des deux.
6. Re-mesurez chaque trimestre. Les charges dérivent vers le plat à mesure que les produits mûrissent; un cluster en pics au lancement est peut-être maintenant une charge provisionnée déguisée en tarification serverless.

Quand c’est la mauvaise approche

Une utilisation constante au-dessus d’environ la moitié d’une instance provisionnée comparable, des SLO de latence qui ne peuvent pas absorber des minutes de cache froid, ou une équipe finance qui a besoin d’une ligne base de données prévisible — tout pointe vers des instances provisionnées, possiblement avec tarification réservée. Serverless v2 ne répare pas non plus les mauvaises requêtes ni les index manquants; mettre à l’échelle une mauvaise requête ne fait que vous la facturer plus, plus vite.

Erreurs courantes

• Fixer un minimum de 0,5 ACU en production pour économiser, puis le payer en latence de cache froid chaque matin.
• Supposer que « serverless » signifie paiement à la requête et découvrir le plancher sur la première facture mensuelle.
• Laisser le maximum à 256 et laisser une requête analytique en fuite devenir un événement budgétaire.
• Comparer les coûts seulement contre le provisionné à la demande — la capacité provisionnée réservée est le vrai point de référence pour une charge stable.

Garder le contrôle

• Alarme sur ACUUtilization soutenu près du maximum et sur ServerlessDatabaseCapacity qui plafonne en moyenne près du maximum pendant des heures.
• Revoyez le ratio moyenne-vs-plancher d’ACU chaque mois; un plancher égal à la moyenne signifie que vous avez acheté du provisionné au prix serverless.
• Étiquetez les clusters serverless par environnement et imposez le minimum 0 hors production.
• Refaites la comparaison de prix provisionné-vs-serverless après tout changement de trafic soutenu, pas seulement à la conception.

Serverless v2 est un outil de précision : superbe là où la charge est vraiment variable, discrètement dispendieux là où elle ne l’est pas, et le graphique de capacité CloudWatch vous dit lequel des deux vous avez. 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.