Aurora serverless porte son plafond à 384 ACU et cale la base serverless d’AWS sur les pics des agents IA

27 octobre 2026. AWS annonce qu’Amazon Aurora serverless accepte désormais jusqu’à 384 ACU (Aurora Capacity Units) pour l’édition compatible PostgreSQL, soit 50 % de plus que le précédent maximum de 256 ACU. Chaque ACU fournit environ 2 Gio de mémoire avec le CPU et le réseau correspondants : une seule base peut donc monter à 768 Gio de mémoire. 28 octobre 2026. La documentation de capacité est mise à jour. Le point qui compte : AWS pousse simultanément les deux curseurs — le plafond vers le haut, le plancher vers zéro — pour faire d’Aurora serverless la base par défaut des workloads d’IA agentique, imprévisibles et en rafale.

Ce que « 384 ACU » veut dire concrètement

L’ACU est l’unité de mesure d’Aurora serverless : environ 2 Gio de mémoire, une part de vCPU et une bande passante réseau proportionnelles. La base s’ajuste en continu — par paliers de 0,5 ACU — entre un minimum et un maximum que vous fixez, et la facturation est à la seconde.

Jusqu’ici, le plafond était de 256 ACU, un seuil fixé en 2024. Le relever à 384 ACU revient à dire qu’une seule base serverless peut désormais encaisser une pointe de charge qui, il y a encore trois ans, aurait exigé plusieurs instances provisionnées soigneusement dimensionnées. AWS cite des versions PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23, toutes sur la Platform Version 4.

Le détail d’exploitation compte autant que le chiffre. Pour un cluster existant déjà sur Platform Version 4, la montée du plafond se fait sans interruption : il suffit de modifier le réglage de capacité maximale. Pour un cluster sur une plateforme antérieure, il faut d’abord passer par une action de maintenance planifiée vers la PV4.

La descente à zéro est l’autre moitié de l’annonce

Le plafond de 384 ACU ne prend tout son sens que combiné à une autre évolution, datée d’avril 2026 : Aurora serverless peut redescendre à 0 ACU quand la base est inactive, et repartir à la demande. C’est la définition même du profil de charge que vise AWS : des rafales d’activité suivies de longues fenêtres d’inactivité, et un trafic imprévisible — exactement le comportement des applications d’IA agentique.

En août 2026, AWS avait déjà accéléré la montée en charge dans ce sens : la base peut atteindre 12 ACU en moins d’une seconde avant de poursuivre vers le plafond, précisément pour qu’un agent qui s’éveille ne paie pas plusieurs secondes de latence au démarrage. La logique d’ensemble est limpide : monter vite quand l’agent lance une rafale, redescendre à zéro quand il se tait, payer seulement ce qui est consommé.

Pourquoi c’est un pari sur l’IA agentique

Le communiqué d’AWS ne prend même pas la peine de dissimuler la cible : « Aurora serverless est particulièrement adapté aux applications d’IA agentique, qui ont typiquement des rafales d’activité, de longues fenêtres d’inactivité et des motifs de trafic imprévisibles. » La phrase résume une thèse : l’agent IA devient un consommateur de base de données structurellement différent d’une application web classique.

Une API web a une charge relativement lisse et prévisible. Un agent qui planifie, enchaîne des appels d’outils, rédige puis réfléchit longtemps ne sollicite la base que par à-coups. Dimensionner une base provisionnée pour ses pointes revient à payer en permanence une capacité utilisée 10 % du temps. La serverless, elle, absorbe la pointe et rend la capacité inutilisée.

Ce n’est pas un cas d’usage théorique. AWS relie explicitement les deux annonces — le plafond à 384 ACU et la descente à zéro — au même public : les équipes qui construisent des agents, des pipelines d’inférence et des traitements par lots à la demande. La base de données devient l’arrière-plan élastique de ces charges, au même titre que les fonctions serverless le sont devenues pour l’informatique événementielle.

Ce que l’élasticité coûte réellement

La facturation d’Aurora serverless est à la seconde, proportionnelle au nombre d’ACU consommés. Le modèle économique est donc limpide : vous payez la capacité que vous utilisez, pas celle que vous réservez. Une charge qui culmine à 100 ACU pendant deux heures puis retombe à zéro coûte exactement ces deux heures de pointe — là où une instance provisionnée aurait facturé 24 heures d’une capacité dimensionnée pour le pic.

Ce calcul est la raison d’être du produit, et il explique pourquoi AWS l’oriente vers l’IA agentique. Un agent qui enchaîne quelques appels d’outils puis réfléchit longtemps génère un profil de charge en dents de scie : quelques minutes de pointe, puis rien. La serverless épouse ce profil ; le provisionné le subit.

Rappelons d’où vient le produit. Aurora Serverless v1, lancé en 2018, montait en charge par doubles et imposait un temps de chauffe perceptible. La v2, introduite en 2022, a changé d’échelle : des paliers de 0,5 ACU, une montée bien plus rapide, puis la descente à zéro en avril 2026 et la première marche à 12 ACU quasi instantanée en août. Le relèvement à 384 ACU est la suite logique de cette trajectoire : AWS élargit la plage d’élasticité pour que le produit couvre aussi les pointes que l’on croyait réservées au provisionné.

Les pièges du « serverless, donc je ne dimensionne rien »

Le terme « serverless » est trompeur s’il laisse croire que la décision de capacité disparaît. Elle se déplace, elle ne s’évapore pas : le réglage de capacité maximale est désormais une vraie décision de dimensionnement — et de budget.

Premier piège : le plafond par défaut. Une base Aurora serverless créée avec un maximum faible étouffera vos pointes exactement comme une instance sous-dimensionnée. Monter à 384 ACU n’a de sens que si vous le configurez — et le relever n’est pas anodin en facturation, puisque le coût croît linéairement avec la capacité consommée.

Deuxième piège : la latence de montée au-delà du premier palier. La montée « instantanée » annoncée en août vaut pour les 12 premiers ACU ; au-delà, la base continue de monter progressivement à mesure que la charge s’installe. Une rafale très courte et très haute peut donc dépasser ce que la base a eu le temps d’absorber. Pour les pics soutenus et prévisibles, une instance provisionnée reste souvent moins chère et plus prévisible.

Troisième piège : le socle de version. Le plafond de 384 ACU exige la Platform Version 4 et des versions PostgreSQL récentes. Un cluster sur une ancienne plateforme doit planifier une maintenance — ce qui, pour une base en production, est un projet, pas un clic.

Verdict

Si votre charge est en rafale et imprévisible — agents IA, traitements par lots à la demande, trafic saisonnier — montez le plafond de votre base Aurora serverless vers 384 ACU et profitez de la descente à zéro : vous ne paierez que les pointes. Vérifiez d’abord que vous êtes sur Platform Version 4 et une version PostgreSQL compatible, et relevez le minimum si une base au repos doit garder assez de mémoire pour vos fonctionnalités actives. Si votre charge est soutenue et prévisible à plus de la moitié du temps, restez sur une instance provisionnée : le serverless facture la flexibilité, et vous n’en avez pas besoin. La décision n’a jamais été « serverless ou pas » ; elle est « quel plafond, pour quelle forme de charge » — et AWS vient de repousser ce plafond assez haut pour que la réponse penche vers le serverless bien plus souvent qu’avant.

Références

• AWS — Amazon Aurora serverless now supports up to 384 ACUs (27 octobre 2026)
• AWS — Amazon Aurora Serverless v2 now supports up to 256 ACUs (2024)
• AWS — Aurora serverless scales faster to support agentic AI (août 2026)
• AWS — Introducing scaling to 0 capacity with Amazon Aurora Serverless v2 (avril 2026)
• AWS — documentation Aurora serverless : capacité et ACU