« Selon le rapport officiel AWS, Aurora Serverless v2 ajuste la capacité de calcul en quelques secondes, par incréments de 0,5 ACU, sans interruption des connexions actives » — c’est cette promesse précise qui a poussé un site d’actualités à migrer sa base MySQL/MariaDB classique vers ce service, après plusieurs incidents où un pic de trafic imprévisible avait saturé une instance dimensionnée pour un trafic moyen.
Le cas est fréquent dans la presse en ligne : un article partagé massivement sur les réseaux sociaux peut multiplier le trafic par vingt en quelques minutes, puis retomber tout aussi vite. Une instance de base de données dimensionnée pour absorber ce pic resterait surdimensionnée — et coûteuse — le reste du temps. C’est exactement le problème qu’Aurora Serverless v2 cherche à résoudre, à la différence d’une réplication classique où le nombre de répliques reste fixe tant qu’on ne l’ajuste pas manuellement.
Mise en place
Aurora Serverless v2 fonctionne comme un cluster Aurora classique compatible MySQL, mais la capacité de calcul se définit par une plage d’ACU (Aurora Capacity Units) plutôt que par un type d’instance fixe. Chaque ACU correspond approximativement à 2 Gio de mémoire avec le processeur et la bande passante réseau associés.
{
"ServerlessV2ScalingConfiguration": {
"MinCapacity": 0.5,
"MaxCapacity": 16
}
}
Le connecteur WordPress ne change pas : wp-config.php pointe vers l’endpoint du cluster comme pour n’importe quelle base MySQL distante, sans configuration spécifique côté application.
Ce qu’on observe en conditions réelles
Sur le site accompagné, la capacité de base tourne à 0,5 ACU la majorité du temps, ce qui correspond au strict minimum facturable. Lors d’un pic de trafic (article viral, pic à 15 000 visiteurs simultanés), la capacité est montée automatiquement jusqu’à 8 ACU en moins de deux minutes, sans qu’aucune intervention manuelle n’ait été nécessaire ni qu’aucune connexion active n’ait été coupée.
- Montée en charge automatique en quelques dizaines de secondes à quelques minutes selon l’ampleur du pic
- Aucune coupure de connexion observée pendant la bascule de capacité
- Redescente automatique à la capacité minimale une fois le pic retombé
Les coûts réels observés
Sur trois mois d’observation, la facture mensuelle du cluster est restée sous 45 dollars en période calme, avec des pics ponctuels à 90 dollars les mois où plusieurs articles sont devenus viraux. À titre de comparaison, une instance provisionnée en permanence pour absorber le pic maximal aurait coûté plus de 150 dollars mensuels, systématiquement, pic ou non.
Les limites à connaître
La montée en charge n’est pas instantanée : sur un pic extrêmement brutal (multiplication du trafic par cinquante en moins de trente secondes), quelques requêtes peuvent rencontrer une latence accrue le temps que la capacité s’ajuste. Un cache applicatif (objet ou page) reste indispensable pour absorber ces toutes premières secondes, Aurora Serverless v2 n’étant pas conçu pour remplacer un cache.
Un pic de trafic imprévisible ne prévient jamais à l’avance : la vraie valeur d’Aurora Serverless v2 n’est pas la performance en soi, mais l’absence d’astreinte pour ajuster manuellement la capacité un dimanche soir.
Compatibilité avec l’écosystème WordPress
Aurora Serverless v2 reste compatible avec le moteur InnoDB et le protocole MySQL standard, ce qui signifie qu’aucune extension WordPress n’a besoin d’être adaptée pour fonctionner avec ce type de cluster. Les outils de sauvegarde habituels (WP-CLI, ou des snapshots automatisés via l’API AWS) fonctionnent sans modification, ce qui facilite grandement l’adoption pour une équipe déjà familière de l’écosystème AWS.
- Aucune modification du code applicatif WordPress n’est nécessaire pour utiliser ce type de cluster
- Les sauvegardes automatiques (snapshots) restent gérées nativement par le service, avec une rétention configurable
- La bascule vers une instance provisionnée classique reste possible a posteriori si le profil de trafic devient plus stable
Verdict
Pour un site à trafic très irrégulier, où les pics ne suivent aucun calendrier prévisible, Aurora Serverless v2 évite le choix binaire entre surdimensionnement permanent et risque de saturation. Le coût réel constaté sur ce projet reste inférieur à une instance provisionnée fixe, à condition d’accepter que la montée en charge prenne quelques dizaines de secondes plutôt que d’être instantanée, et de maintenir un cache applicatif solide pour absorber les toutes premières requêtes d’un pic brutal.
