WordPress sur AWS : RDS MySQL vs Aurora vs Aurora Serverless — quelle couche de données convient

Si vous déployez un site WordPress sur AWS, ce guide vous aide à choisir la base de données qui ira derrière. Trois options se présentent, et ce choix se défait mal ensuite, parce que cette base contient chaque article, chaque commande et chaque compte depuis le lancement du site. Pour la plupart des sites WordPress, la réponse est RDS MySQL (Relational Database Service) en Multi-AZ, qui garde une copie de relève dans un second centre de données et bascule tout seul. Aurora, le moteur compatible MySQL d’Amazon, vaut le déplacement dès qu’il vous faut plusieurs répliques de lecture, ces copies qui répondent aux requêtes en lecture seule. À la fin, vous saurez laquelle convient à votre trafic et comment chacune réagit quand WP-Admin s’emballe.

Restez sur RDS MySQL en Multi-AZ si vos écritures sont régulières, si un cache d’objets absorbe l’essentiel des lectures et si une seule réplique de lecture suffit. Passez à Aurora MySQL quand il vous faut une troisième lectrice, des lectrices dans une autre région ou des clones rapides de la base pour la mise à l’essai. Aurora aide aussi quand il vous faut plus d’IOPS en écriture (opérations d’entrée-sortie par seconde, le rythme de travail du stockage) que gp3, le SSD polyvalent de RDS, n’en fournit. Choisissez Aurora Serverless v2 quand le trafic arrive vraiment en rafales, de longues accalmies coupées de pointes courtes et vives. Il se dimensionne en ACU (Aurora Capacity Units, des paliers d’un demi-gigaoctet de mémoire avec le CPU assorti), et il met un moment à monter en puissance après une accalmie.

Trois options en un coup d’œil

Les lignes de décision en un coup d’œil :

Quand RDS MySQL convient

RDS MySQL avec Multi-AZ est le choix par défaut pour la couche de données WordPress et reste le bon choix plus longtemps que la plupart des équipes ne le réalisent. Trois signaux pointent vers lui :

Votre pression de lecture est absorbée par Redis. Lorsque le taux de présence en cache d’objets dépasse 95 % et que le CPU de la BD d’écriture ne franchit jamais 50 %, ajouter une lectrice résout un problème que vous n’avez pas. RDS gère ce cas avec la complexité opérationnelle la plus faible — un point d’accès d’écriture, un standby qui ne fait rien jusqu’à ce que l’écrivain tombe.

Votre patron d’écriture est prévisible. Les écritures WordPress varient avec l’activité éditoriale (insertions wp_posts, mises à jour wp_postmeta, changements d’options chargées automatiquement), avec les soumissions de commande ou de formulaire, et avec les écritures wp_users/wp_usermeta à la connexion. La plupart des sites WordPress en production génèrent des écritures soutenues bien en dessous de ce que db.r6g.large traite. RDS gp3 provisionné à 3000 IOPS couvre aisément un WordPress à six chiffres de pages vues par jour avec commerce actif.

Vous voulez un coût IOPS prévisible. RDS gp3 a un prix IOPS plat lié au stockage provisionné. Aurora facture par opération d’E/S. Pour un WordPress où la majeure partie du trafic est en lecture servie depuis le cache et où la base absorbe en moyenne 50 à 200 écritures/s, RDS est sensiblement moins cher qu’Aurora à taille d’instance égale parce que les frais par E/S d’Aurora s’accumulent même sur les ratés de cache.

Le piège de rester avec RDS trop longtemps, c’est la troisième réplique de lecture. RDS prend en charge un seul standby Multi-AZ et peut avoir des répliques de lecture, mais chacune est une instance indépendante avec son propre stockage et son propre flux de réplication depuis l’écrivain. Au-delà de deux lectrices, le surcoût opérationnel — réglage du délai de réplication, posture de sauvegarde distincte, groupes de paramètres distincts — dépasse ce qu’Aurora vous donne pour le même prix.

Quand Aurora gagne

Le signal que vous avez dépassé RDS, c’est la troisième lectrice. Le modèle de stockage partagé d’Aurora signifie que les lectrices ne maintiennent pas chacune une copie — elles lisent toutes depuis le même volume sous-jacent, répliqué six fois sur trois AZ. Ajouter une lectrice est une étape de provisionnement de 5 minutes, pas une danse instantané-puis-réplication de 30 minutes. Le point d’accès lecteur répartit les requêtes en tourniquet sur toutes les lectrices, vous n’avez donc pas à enseigner la lectrice N+1 à l’application.

Au-delà de l’échelle en lecture, Aurora gagne sur trois fonctionnalités opérationnelles que les équipes WordPress utilisent réellement :

• Clones rapides pour la mise à l’essai. Un clone Aurora est une fourche copie-sur-écriture du stockage du cluster. Il se provisionne en minutes peu importe la taille de la base — une BD de production de 200 Go se clone vers la mise à l’essai dans environ le même temps qu’une de 20 Go. L’instantané-puis-restauration RDS s’échelonne linéairement avec la taille.
• Backtrack (Aurora MySQL uniquement). Rembobinez le cluster à n’importe quel point des dernières 72 heures en secondes. Utile pour les opérations admin accidentelles — suppression massive d’articles, mauvais UPDATE SQL — sans restaurer un instantané ni passer par le PITR.
• Granularité PITR à la seconde. La sauvegarde continue d’Aurora signifie que la reprise à un point dans le temps est à la seconde, pas aux 5 minutes. Pour les sites WordPress de commerce où chaque commande compte, cela peut être la différence entre perdre cinq commandes et en perdre une.

Le prix à payer pour ces fonctionnalités est la facturation par E/S d’Aurora. Chaque lecture qui ne touche pas le pool tampon, chaque écriture, chaque opération de réplication entraîne un frais d’E/S. Pour un WordPress à 95 % de cache, c’est fin — la base de données fait relativement peu d’E/S et les coûts par E/S Aurora sont absorbés par les économies de lectrices consolidées. Pour un WordPress chargé en recherche ou en administration où le cache est constamment contourné, les frais d’E/S d’Aurora peuvent gonfler. Aurora I/O-Optimized (la classe de stockage qui plafonne les frais d’E/S en échange d’un tarif de stockage de base plus élevé) inverse ce calcul — choisissez-le lorsque votre facture mensuelle d’E/S dépasse régulièrement environ 25 % du coût de base de l’instance.

Aurora porte une prime par-IOPS qui devient significative au-dessus d’environ 50 % de trafic de lecture en raté de cache ; en dessous, le modèle par-E/S d’Aurora est presque toujours moins cher que le modèle IOPS provisionnées de RDS parce que vous ne payez que pour les E/S réellement effectuées.

Quand Aurora Serverless v2 convient

Aurora Serverless v2 est Aurora avec mise à l’échelle par ACU au lieu de classes d’instance. Le cluster s’échelonne entre un ACU minimum et un maximum (Aurora Capacity Unit, environ 2 GiB de mémoire + CPU proportionnel) en secondes, selon la charge. Ce n’est pas le même produit que v1 — v2 maintient le cluster toujours en marche (pas de pause-reprise), évite le long démarrage froid pour lequel v1 a été pénalisé, et prend en charge les répliques. L’ACU minimum est 0,5 (vous ne pouvez jamais aller à zéro, vous payez pour 0,5 ACU même au repos).

Serverless v2 convient lorsque :

• Le trafic est véritablement en rafale. Un WordPress B2B qui gère 20 RPS pendant les heures de bureau et 0,5 RPS la nuit, avec un événement de presse par trimestre qui pousse à 800 RPS. Aurora provisionné à la taille de régime établi est gaspillé la nuit et sous-dimensionné les jours de presse ; Serverless v2 s’adapte.
• Vous exploitez plusieurs sites WordPress avec différentes formes de trafic. Une pile d’agence multi-locataires où dix sites partagent un cluster et où n’importe lequel peut faire un pic. Serverless v2 met à l’échelle tout le cluster vers le haut lorsqu’un locataire fait un pic, et redescend quand le pic passe — pas de surdimensionnement.
• Vous voulez le modèle opérationnel d’Aurora sans choisir une classe d’instance. Certaines équipes préfèrent ne pas trancher entre db.r6g.large et db.r6g.xlarge. Serverless v2 contourne la question.

Où Serverless v2 vous brûle sur les pics WP-Admin : l’éditeur ouvre un écran d’édition Gutenberg, qui déclenche une série d’appels REST (/wp-json/wp/v2/posts/<id>, /wp-json/wp/v2/users/me, /wp-json/wp/v2/taxonomies, points personnalisés ACF, points personnalisés de plugins tiers). Sur un cluster froid — qui est resté à 0,5 ACU pendant une heure — la première requête d’écran d’édition tombe sur un écrivain sous-dimensionné, fait la file derrière l’initialisation des connexions, met 4 à 8 secondes à se compléter, et l’éditeur voit une roulette. Le cluster se met à l’échelle en secondes, mais la première requête est lente. Pour les sites avec activité éditoriale fréquente, fixez l’ACU minimum assez haut pour que le cluster reste chaud — typiquement 2 à 4 ACU. Cela échange une partie des économies de coûts contre une latence prévisible sur la première édition d’une période calme.

Serverless v2 n’est pas le bon choix pour un WordPress avec activité éditoriale continue toute la journée ou un site de commerce où la latence à la caisse est la métrique limitante. Pour ces charges, Aurora provisionné à une classe d’instance fixe donne une latence plus prévisible.

Parcours de migration depuis des hôtes infogérés/mutualisés existants

Le parcours depuis cPanel mutualisé, Dreamhost, WP Engine, Kinsta ou un VPS auto-géré vers l’une de ces trois options a la même forme : exporter la base existante avec wp db export, nettoyer l’export (supprimer les tables _session, supprimer les options chargées automatiquement qui contiennent des noms d’hôte, supprimer les transients), importer dans le nouveau cluster RDS/Aurora, puis mettre à jour wp-config.php. Les différences sont aux bordures :

Migration vers RDS MySQL. Utilisez mysqldump --single-transaction --routines --triggers --hex-blob ou AWS DMS pour toute base de plus d’environ 5 Go. RDS prend en charge la syntaxe MySQL 8 complète — aucune surprise de compatibilité.

Migration vers Aurora MySQL. Même flux que RDS, avec une réserve : Aurora ne prend pas en charge LOAD DATA INFILE sur les fichiers locaux. Si votre export utilise LOAD DATA LOCAL INFILE pour un import rapide, passez à mysqldump --extended-insert ou utilisez DMS, qui gère la conversion en interne. L’extension aurora_load_from_s3 d’Aurora est le chemin le plus rapide pour les très gros exports.

Migration vers Aurora Serverless v2. Comme Aurora MySQL. Fixez l’ACU minimum à 4 pendant la migration pour que l’import soit rapide, puis abaissez-le au plancher visé (souvent 1 ou 2 ACU) après la bascule.

Dans les trois cas, ne supprimez pas la base source avant une semaine. Exécutez une petite requête de lecture depuis le nouveau WordPress contre l’ancienne base pour confirmer l’absence de données manquantes — wp db query "SELECT COUNT(*) FROM wp_posts" des deux côtés. Testez l’éditeur : ouvrez un article existant, enregistrez-le sans changement, confirmez que la ligne d’enregistrement automatique apparaît. Testez le commerce : passez une commande de test, remboursez-la, confirmez que la ligne de commande et la ligne de remboursement s’écrivent correctement.

Plafond de performance

Chaque option a un mur de mise à l’échelle différent :

• RDS MySQL atteint son plafond au CPU de l’écrivain. Aucune mise à l’échelle horizontale en écriture — vous montez l’écrivain en gamme (db.r6g.large → db.r6g.xlarge → db.r6g.2xlarge → jusqu’à db.r6g.16xlarge). Le standby Multi-AZ unique n’absorbe aucun trafic de lecture. Une réplique de lecture peut prendre une partie de la charge de lecture mais uniquement via un routage applicatif.
• Aurora MySQL a le même plafond d’écrivain, mais ajoute jusqu’à 15 lectrices qui partagent un seul point d’accès. La mise à l’échelle en lecture est effectivement horizontale jusqu’à ce que quelque chose de spécifique (de gros SELECT FOR UPDATE, délai de réplication sur des lignes brûlantes) commence à mordre.
• Aurora Serverless v2 échelonne l’écrivain jusqu’à 128 ACU, ce qui est comparable à un db.r6g.16xlarge. Au-delà, vous avez besoin d’Aurora provisionné.

Le plafond des limites de connexions est partagé. WordPress maintient une connexion BD par travailleur PHP-FPM par nœud. Sur un ASG de six nœuds à 30 travailleurs chacun, cela fait 180 connexions. db.r6g.large plafonne par défaut à 1000 connexions, db.r6g.xlarge à 2000. La limite de connexions est rarement la contrainte limitante, mais c’est celle qui déclenche des 500 visibles à l’utilisateur lorsqu’elle est atteinte — pas de dégradation gracieuse, juste des erreurs MySQL: Too many connections. RDS Proxy devant l’écrivain mutualise les connexions et absorbe les pics du pool PHP-FPM ; il ajoute 1 à 2 ms de latence et est la précaution juste au-dessus de six nœuds applicatifs.

Le délai de réplication est l’autre plafond à nommer. Sur les répliques de lecture RDS, la réplication est asynchrone et peut prendre de millisecondes à secondes sous pression d’écriture. Lire les données utilisateur depuis une réplique en retard signifie que l’utilisateur vient d’enregistrer son article et qu’un rafraîchissement affiche l’ancienne version. WordPress n’est pas tolérant aux lectures-après-écritures sans code qui gère ce cas, donc la plupart des équipes en production gardent soit toutes les lectures sur l’écrivain (et utilisent le cache pour absorber la charge), soit routent les lectures vers les lectrices uniquement pour les chemins clairement en lecture seule (le site public) et les chemins admin via l’écrivain. La réplication de stockage d’Aurora est bien plus rapide (typiquement sous 100 ms) mais le même principe s’applique — si votre code attend une cohérence lecture-après-écriture, lisez depuis l’écrivain ou attendez.

Exemple de coût

Sans publier de montants en dollars, les fourchettes qualitatives ressemblent à ceci :

• Pour un WordPress avec 100 RPS soutenu, 95 % de présence en cache, deux nœuds d’ASG et une bibliothèque média modeste, RDS MySQL Multi-AZ sur db.r6g.large est environ 40 à 60 % moins cher que la configuration Aurora MySQL équivalente sur un an. Les économies viennent du coût IOPS plat de gp3 contre la facturation par E/S d’Aurora, plus vous ne payez pas une seconde instance de classe écrivain.
• Pour le même WordPress avec trois répliques de lecture ou plus, l’équation s’inverse : Aurora est moins cher car ajouter une lectrice n’est qu’une instance, pas une réplique de stockage complète avec sa propre facture d’E/S.
• Pour un WordPress avec trafic en rafale — 5 RPS la nuit, 300 RPS au pic — Aurora Serverless v2 avec min ACU 2 / max ACU 16 est typiquement 30 à 50 % moins cher qu’Aurora provisionné dimensionné pour le pic, et à peu près neutre en coût par rapport à RDS Multi-AZ dimensionné pour le pic.

Stack Harbor cadre la tarification selon les facteurs réels — volume de requêtes, ratio écriture/lecture, ratio admin/anonyme, taille de la bibliothèque média, RPO/RTO visés — et chiffre un forfait mensuel fixe après une revue de découverte. Nous ne publions délibérément pas de tarifs par instance car trois des facteurs de coût ci-dessus sont décidés par votre mélange de trafic, pas par le prix de liste AWS, et un chiffre sur une page marketing serait trompeur dans un sens ou dans l’autre.

Voir aussi

• WordPress en production sur AWS : de EC2+RDS au cluster autoscaling
• Stockage de sessions Redis sur ElastiCache — le modèle qui survit à la bascule
• Sessions persistantes ALB : quand en avez-vous réellement besoin
• Solution gestion AWS
• WordPress Entreprise — plateforme infogérée quand opérer la pile en code infrastructure n’est pas le bon compromis
• Managed Operations — opérer la couche de données sous SLA Stack Harbor