Aurora Serverless v2 après six mois : le plancher de 0,5 ACU et le mythe de l'auto-pause

Publié sur le blog TEN INVENT · Septembre 2026

Aurora Serverless v2 se vend en une phrase : payez la capacité de base de données que vous utilisez, ajustée en fractions de seconde. Six mois d'exploitation en production, staging et dev pour la plateforme d'un client américain nous ont appris que la phrase est vraie, et qu'elle cache deux questions qui décident si c'est la bonne base pour vous : quelle est la plus petite capacité que vous avez le droit d'utiliser, et que se passe-t-il quand vous n'en utilisez aucune.

Version courte : c'est le bon choix pour dev et staging, pour les charges de production en pics, et pour quiconque préfère ne pas penser aux classes d'instances. C'est le mauvais choix pour une charge de production petite et stable, où une instance RDS ennuyeuse coûte moins cher, et pour une charge grande et stable, où Aurora provisionné coûte moins cher. Nous le choisirions à nouveau pour ce projet. Voici l'arithmétique.

Ce qu'est une ACU, et ce que 0,5 ACU achète

Une Aurora Capacity Unit, c'est environ 2 Gio de mémoire avec CPU et réseau proportionnels. Vous fixez un minimum et un maximum par cluster, et le cluster s'ajuste entre les deux selon la charge. Le prix est par ACU-heure : 0,12 $ en us-east-1, donc une ACU qui tourne tout le mois coûte environ 88 $, et une demi-ACU environ 44 $.

Le minimum était autrefois 0,5 ACU, point. Depuis fin 2024, vous pouvez le mettre à 0, ce qui active l'auto-pause : après une période d'inactivité configurable, le cluster cesse de facturer le calcul et reprend à la connexion suivante. C'est la fonctionnalité que vise le marketing quand il dit « payez ce que vous utilisez ». C'est aussi là que vit la nuance.

En dev et staging, nous mettons le minimum à 0. Les clusters se mettent en pause la nuit et le week-end, et une reprise prend environ 15 secondes. La première requête après une pause attend, ou échoue et réessaie, et c'est acceptable pour un environnement où la première requête du matin est celle d'un développeur. Deux clusters hors production sont passés d'environ 90 $ par mois à 0,5 ACU chacun à environ 20 $.

En production, nous ne pouvons pas. Un blocage de 15 secondes sur la première requête après une période calme est une panne visible par les utilisateurs sur une application grand public, et il ferait aussi échouer le health check App Runner qui touche la base. Donc la production tourne avec un minimum de 0,5 ACU, en continu, qu'on l'utilise ou non. C'est le plancher : 44 $ par mois avant la première requête. La plupart du temps, notre cluster de production se situe entre 0,5 et 1,5 ACU, et la facture mensuelle de calcul tombe autour de 90 $.

Le bon

La mise à l'échelle est réelle et rapide. Un traitement nocturne qui touche l'essentiel de la table des commandes fait passer le cluster de 0,5 à 4 ACU en moins d'une minute, et redescendre dans les quinze suivantes. Nous n'avons jamais dimensionné d'instance pour lui. Sur RDS provisionné, nous paierions le pic du traitement toute la journée.

C'est Postgres. Extensions, pg_dump, tous les ORM, tous les outils. La Data API et l'authentification IAM sont là si vous les voulez ; nous utilisons l'auth IAM depuis les Lambdas et évitons la gestion des mots de passe pour celles-ci.

Le stockage est séparé et ennuyeux. 0,10 $ par Go-mois, grandit tout seul, pas de volume à redimensionner, pas d'IOPS à provisionner. Les sauvegardes dans la fenêtre de rétention sont incluses.

L'auto-pause hors production est une vraie fonctionnalité de coût. Deux clusters, 70 $ par mois économisés, zéro configuration au-delà d'un minimum à 0 et d'un délai d'inactivité. Elle a rendu les environnements de preview par PR praticables : un cluster partagé en pause, une base par PR, aucun coût de calcul par PR.

Le mauvais

Le plancher, c'est le prix. Pour une petite charge de production, 0,5 ACU en continu, c'est 44 $ plus le stockage. Une instance RDS PostgreSQL db.t4g.medium, 2 vCPU et 4 Gio, coûte environ 47 $ à la demande et 30 $ réservée, elle ne s'ajuste pas, et elle n'en a pas besoin non plus. Si votre charge de production est stable et petite, Serverless v2 est la façon la plus chère d'acheter la même chose.

La réduction est lente, et c'est pendant la réduction que les connexions tombent. La capacité monte en secondes et descend en minutes, délibérément. Quand elle descend, la mémoire de l'instance rétrécit, et les connexions qui tenaient de gros jeux de travail sont tuées. Nous avons vu des erreurs sporadiques de connection reset pendant une semaine avant de les corréler aux événements de réduction. RDS Proxy devant a réglé le problème pour les Lambdas ; pour App Runner, nous avons mis le délai d'inactivité du pool sous l'intervalle de réduction.

L'ACU maximale est une limite de mémoire que vous pouvez atteindre au mauvais moment. Nous avions mis max 4 pour plafonner le coût. Une requête de reporting qui avait besoin de plus de mémoire que 4 ACU n'a pas ralenti, elle a échoué. Sur RDS provisionné, la même requête aurait swappé et rampé, ce qui est sans doute pire, mais elle aurait fini.

La reprise après auto-pause n'est pas 15 secondes pour tout le monde. C'est 15 secondes pour le cluster. Ajoutez le démarrage à froid de la Lambda devant et le pool de connexions de l'instance App Runner qui se rétablit, et la première requête du matin en dev peut prendre 30 secondes. Acceptable là. Pas une fonctionnalité de production, quoi qu'en dise la page de prix.

Le coût, honnêtement

La comparaison que veulent les gens, c'est Serverless v2 contre les alternatives à une charge moyenne donnée. Au prix catalogue en us-east-1, calcul seulement :

Le point de croisement est clair. Sous environ 1 ACU en moyenne, une petite instance RDS est moins chère ou équivalente. Au-dessus d'environ 2 ACU stables, Aurora provisionné est moins cher. Serverless v2 gagne au milieu, et il gagne nettement quand le pic vaut plusieurs fois la moyenne, ce qui est la dernière ligne et celle qui décrit la plupart des applications réelles avec des utilisateurs dans un seul fuseau horaire.

Réglages que nous copierions dans tout nouveau cluster

• Production : min 0,5, max dimensionné sur la plus grosse requête que vous ayez vue plus un, pas sur votre budget. Protection contre la suppression activée. RDS Proxy pour tout ce qui ressemble à une Lambda.
• Hors production : min 0, auto-pause après 10 minutes, max 2. Acceptez le blocage du matin.
• Les deux : délai d'inactivité du pool de connexions sous 5 minutes, pour que les événements de réduction ne vous surprennent pas. Stockage I/O-Optimized seulement si les frais d'I/O dépassent environ 25 % de la facture, ce qui n'est pas notre cas.
• Surveillez ServerlessDatabaseCapacity et ACUUtilization dans CloudWatch. La seconde à 100 % pendant plus de quelques minutes signifie que l'ACU max est trop basse et que quelque chose va échouer plutôt que ralentir.

Verdict

La page de prix dit : payez ce que vous utilisez. La version exacte est : payez au moins une demi-ACU en production, ne payez rien quand c'est en pause ailleurs, et payez une prime par ACU en échange de ne rien dimensionner. Que cette prime en vaille la peine dépend entièrement de la forme de votre charge, et maintenant vous avez le tableau.

Vous choisissez entre Serverless v2, RDS et Aurora provisionné pour quelque chose de réel ? Nous ferons l'arithmétique avec vous.