Aller au contenu

AWS Mis à jour le 2026-07-04

Hébergement WordPress géré sur AWS : performance, sécurité, sauvegardes et mises à jour prises en charge de bout en bout

Gérer un hébergement WordPress sur AWS, c'est que quelqu'un possède chaque couche que l'ancien hébergeur géré assumait : mises à jour, sécurité, sauvegardes, restaurations et mise à l'échelle. Voici ce que couvre vraiment la prise en charge de bout en bout.

Déménager WordPress sur AWS, c’est troquer la plateforme opiniâtre d’un hébergeur géré contre de l’infrastructure brute — et chaque tâche que l’ancien hébergeur faisait sans bruit vous suit. Mises à jour du cœur et des extensions, versions de PHP, durcissement de sécurité, sauvegardes et les tests de restauration qui les rendent réelles, renouvellement TLS, mise à l’échelle, et la réponse à 2 h du matin : sur AWS, chacun de ces éléments a un propriétaire, et si vous ne pouvez pas le nommer, c’est actuellement personne. La « gestion d’hébergement WordPress sur AWS », c’est la discipline d’assigner et d’exécuter cette liste, pas un produit qu’on active d’un clic.

Ce que vous décidez

La vraie décision est une matrice de responsabilité, couche par couche. AWS possède les hôtes physiques et l’interne de ses services gérés; tout ce qui est au-dessus de cette ligne est à vous. Pour une charge WordPress, la ligne traverse six couches :

  • Application : mises à jour du cœur, des extensions et des thèmes; l’environnement de test où on les valide; le chemin de retour arrière quand une mise à jour casse le panier ou l’éditeur.
  • Exécution : version et extensions PHP, configuration du serveur web, dimensionnement d’OPcache. Les versions de PHP perdent leur soutien de sécurité selon un calendrier fixe, et rien sur AWS ne fera la mise à niveau pour vous.
  • Données : le moteur de base de données, sa fenêtre de correctifs, ses sauvegardes et — la partie qui sépare les opérateurs des optimistes — des restaurations prouvées régulièrement.
  • Médias et livraison : déporter les téléversements vers S3 pour que les serveurs web restent jetables, et un CDN devant pour que les pointes de trafic frappent CloudFront, pas PHP.
  • Sécurité : règles WAF devant wp-login.php et xmlrpc.php, IAM au moindre privilège, pas d’identifiants FTP éternels, et un balayage de maliciels que quelqu’un lit.
  • Vigie et réponse : alarmes sur les symptômes (taux de 5xx, latence, disque, expiration de certificat) avec un humain au bout.

Vos options : porter tout ça à l’interne (réaliste quand vous avez du personnel d’infrastructure qui connaît aussi WordPress), retourner vers une plateforme WordPress gérée (correct sous le niveau de trafic et de conformité où AWS commence à gagner), ou garder la charge dans votre propre compte AWS avec un opérateur qui la fait tourner — ce qui conserve le contrôle et la porte de sortie tout en louant la discipline.

Quoi vérifier en premier

  • Si une restauration testée existe : pas « on a des sauvegardes », mais « on en a restauré une au dernier trimestre et le site s’est relevé ».
  • Le retard de mises à jour : wp core version et le nombre d’extensions avec des correctifs de sécurité en attente. Soixante jours de retard, c’est la norme sur les sites sans propriétaire, et c’est comme ça qu’ils se font compromettre.
  • Si le serveur est un animal de compagnie : pouvez-vous reconstruire le palier web à partir du code aujourd’hui, ou le site vit-il sur une seule instance configurée à la main dont le volume EBS est le point de défaillance unique?
  • Où vivent les médias — un wp-content/uploads local sur une seule instance signifie que le site ne peut pas s’étendre horizontalement et que chaque perte d’instance est une perte de données.
  • Qui a remarqué la dernière panne en premier : la surveillance, ou un client.

Comment vérifier

Depuis l’instance (ou via SSM Session Manager) :

# Posture de mise à jour
wp core version
wp plugin list --update=available --format=table
php -v

# Les médias sont-ils locaux ou déportés?
du -sh /var/www/html/wp-content/uploads/

Depuis le compte :

# Les sauvegardes de base de données existent-elles, et quel âge a la plus récente?
aws rds describe-db-snapshots \
  --db-instance-identifier prod-wp-db \
  --query 'sort_by(DBSnapshots,&SnapshotCreateTime)[-1].[DBSnapshotIdentifier,SnapshotCreateTime]'

# Le palier de données est-il en haute disponibilité?
aws rds describe-db-instances \
  --db-instance-identifier prod-wp-db \
  --query 'DBInstances[0].[MultiAZ,BackupRetentionPeriod,EngineVersion]'

Dans la console, EC2 > Elastic Block Store > Snapshots montre si le palier web a la moindre histoire de récupération, et CloudWatch > Alarms montre si quelqu’un apprendrait qu’il en a besoin.

L’approche

  1. Écrire la matrice de responsabilité d’abord. Six couches, un nom par couche, des dates de révision par ligne. Chaque post-mortem d’incident sur une pile WordPress sans propriétaire remonte à une ligne sans nom.
  2. Rendre le palier web jetable. Configuration en code, médias sur S3, sessions hors du disque local — pour qu’une instance puisse être détruite sans réunion. L’architecture complète est détaillée dans la grappe WordPress à mise à l’échelle automatique en production sur AWS.
  3. Mettre la base de données sur RDS avec Multi-AZ et une vraie rétention. Correctifs du moteur gérés, sauvegardes automatiques avec récupération à un instant précis, et une bascule qui n’implique l’ordinateur portable de personne.
  4. Installer la cadence de mises à jour. Revue hebdomadaire des extensions et thèmes, environnement de test d’abord, production dans une fenêtre définie pour les correctifs de sécurité. Ennuyant, planifié, et le contrôle de sécurité le plus rentable que WordPress possède.
  5. Durcir la porte d’entrée. CloudFront plus WAF avec limitation de débit sur les points de connexion, TLS via ACM avec renouvellement automatique, et l’accès administrateur derrière une authentification unique ou au minimum une MFA imposée.
  6. Prouver les restaurations chaque trimestre. Restaurer l’instantané de base de données sur une instance jetable, pointer un palier web de test dessus, charger le site, puis tout démonter. Vingt minutes qui transforment « on a des sauvegardes » d’une croyance en un fait.
  7. Brancher la surveillance sur un répondant. Taux de 5xx, latence p95, disque qui se remplit, expiration de certificat, échecs de sauvegarde — acheminés vers le propriétaire de la ligne six de la matrice, peu importe l’heure.

Quand c’est la mauvaise approche

Un site vitrine au trafic modeste, sans exigence de conformité, ne mérite pas cette architecture — un bon hébergeur WordPress géré ou une seule instance Lightsail bien tenue est la réponse honnête, et coûte moins cher que la passerelle NAT à elle seule. La voie AWS rapporte quand le trafic est en pointes, quand le site génère des revenus, quand la résidence des données ou des exigences d’audit s’appliquent (ca-central-1 existe pour une raison), ou quand WordPress est une charge parmi d’autres déjà dans votre compte AWS.

Erreurs fréquentes

  • Transposer le modèle mental cPanel sur une seule instance EC2 : la même fragilité que l’hébergement partagé, avec une facture plus grosse et personne qui surveille Apache.
  • Croire que la responsabilité d’AWS couvre l’application. AWS met à jour l’hyperviseur; votre extension de constructeur de pages périmée, c’est votre brèche.
  • Des sauvegardes sans restaurations — le faux confort le plus répandu en exploitation WordPress, découvert au pire moment possible.
  • Sauter l’environnement de test parce que « c’est juste une mise à jour d’extension », ce qui est vrai jusqu’à ce que la mise à jour couche le panier un vendredi.

Garder le contrôle

  • Une passe d’exploitation hebdomadaire de trente minutes : mises à jour revues, alarmes triées, disque et état des sauvegardes vérifiés d’un coup d’œil.
  • Des exercices de restauration trimestriels, consignés avec dates, pour que la preuve existe quand un client ou un auditeur la demande.
  • Des engagements de correctifs par écrit : correctifs de sécurité en quelques jours, versions de fonctionnalités dans le mois, versions mineures de PHP avant la fin du soutien.
  • Une revue d’architecture annuelle contre le trafic réel — les sites dépassent leur instance unique et rapetissent hors de leur grappe, et les deux directions coûtent de l’argent quand on les ignore.

Rien de tout ça n’est exotique; c’est une liste, avec des propriétaires, exécutée à l’horaire. Faire tourner un WordPress ou un WooCommerce sur AWS qui rapporte vraiment mérite un opérateur, pas un montage de fin de semaine — Stack Harbor opère exactement cette pile sous exploitation WordPress entreprise ; réservez une consultation d’infrastructure.