Architectures AWS pour WordPress : sécurité et coût minimal

Série : expérimenter des architectures AWS pour héberger WordPress de façon sécurisée et à moindre coût

1. Introduction

Cette série documente mes expérimentations sur l’hébergement de WordPress sur AWS sous trois contraintes strictes :

• sécurité maximale,
• coût minimal,
• maintenance minimale.

L’objectif n’est pas de construire une solution parfaite de niveau entreprise, mais d’explorer ce qui est réaliste pour de petits sites ou des projets personnels — sans dépenser des centaines d’euros par mois, et sans y consacrer des heures chaque semaine.

Au fil de ce parcours, j’ai testé plusieurs architectures sur AWS, chacune avec des compromis différents en matière de complexité, de posture de sécurité et de coût. Cet article en propose une vue d’ensemble. Les articles suivants de la série approfondiront chaque approche individuellement — jusqu’au chapitre #5 sur la performance WordPress, qui complète les expériences d’architecture.

2. Approche globale

Avant d’entrer dans les détails, voici la méthodologie globale utilisée dans ce laboratoire :

• Partir de la configuration la plus simple possible sur AWS : une instance EC2 basique hébergeant WordPress.
• Durcir ou découpler progressivement les composants pour améliorer la fiabilité ou la sécurité.
• Introduire des services supplémentaires uniquement lorsqu’ils apportent des améliorations mesurables (sécurité, résilience, optimisation des coûts).
• Analyser chaque architecture selon les mêmes critères :
  • exposition sécuritaire et surface d’attaque,
  • maintenance opérationnelle requise,
  • coûts attendus et cachés,
  • faisabilité concrète.

Cette série se concentre sur les décisions, les résultats et les enseignements — pas sur des tutoriels pas à pas.

3. Synthèse des principales expérimentations

Voici un aperçu rapide des configurations testées. Chacune fera l’objet d’un article dédié.

Tableau comparatif

3.1. Expérience n° 1 — AWS + EC2 + CloudFront + AWS WAF

Objectif : construire une architecture minimaliste, entièrement native AWS, mais sécurisée.

Points clés :

• Simple en théorie ; étonnamment complexe en pratique.
• Options de sécurité solides, mais sensibles aux erreurs de configuration.
• Les règles WAF et les comportements CloudFront font monter les coûts rapidement.
• La gestion TLS/certificats s’est avérée plus complexe que prévu.

3.2. Expérience n° 2 — AWS + EC2 + RDS + ElastiCache

Objectif : découpler WordPress en couches distinctes (calcul, base de données, cache) pour améliorer la scalabilité, la résilience et la maintenabilité.

Cette configuration utilisait :

• une instance EC2 légère uniquement pour PHP + Nginx/Apache,
• Amazon RDS (MySQL) pour la base de données,
• ElastiCache (Redis) pour le cache d’objets.

Points clés :

• L’architecture devient nettement plus complexe.
• La séparation de la base de données améliore les scénarios de reprise (snapshots, basculement).
• Facile de mettre à l’échelle chaque composant (calcul, BDD, cache).
• Mais les performances étaient inférieures pour les petits sites :
  • sauts réseau supplémentaires,
  • latence accrue pour les petites requêtes,
  • la surcharge Redis l’emportait sur les bénéfices du cache.
• Les performances dépendaient fortement du thème et des extensions :
  • certains thèmes WordPress ralentissaient considérablement le site.
• Les coûts augmentent vite : RDS + ElastiCache ne conviennent pas aux petits sites.

Conclusion : Excellente architecture pour un trafic moyen/élevé — pas rentable ni performante pour de très petits sites.

3.3. Expérience n° 3 — AWS + EC2 + Cloudflare

Objectif : réduire la complexité AWS en déléguant le cache, TLS et la sécurité à Cloudflare.

Points clés :

• Simplifie considérablement TLS et la protection en périphérie.
• Coût très faible possible.
• Cloudflare ZTNA et Tunnel rendent l’origine entièrement privée.
• Mais :
  • crée une forte dépendance à Cloudflare,
  • le comportement de Cloudflare peut perturber l’administration WordPress,
  • la logique de cache diffère de CloudFront,
  • certaines intégrations AWS (ACM, URL signées S3, redimensionnement d’images Lambda) ne s’accordent pas bien.

3.4. Expérience n° 4 — AWS + EC2 + ALB + CloudFront + AWS WAF

Objectif : introduire un Application Load Balancer (ALB) pour séparer proprement les responsabilités et simplifier l’intégration WAF et Cognito.

Points clés :

• Flux de trafic plus clair et conception plus alignée sur AWS.
• L’ALB simplifie grandement les règles WAF et les flux d’authentification (Cognito).
• Fonctionne extrêmement bien avec CloudFront et les origines VPC.
• Mais ajoute :
  • des services supplémentaires,
  • des journaux supplémentaires,
  • un coût supplémentaire (heures ALB + LCU),
  • davantage de risques de mauvaise configuration.
• Paraît robuste et scalable, mais excessif pour un seul petit site WordPress.

4. Ce que ces expérimentations ont révélé

Sur l’ensemble des expériences, plusieurs tendances se sont dégagées :

• Sécurité et simplicité : un compromis permanent. Ajouter des composants renforce la protection, mais aussi le coût et la charge opérationnelle.

• CloudFront, Cloudflare, ALB et RDS ont tous des comportements peu évidents. Chacun peut introduire des contraintes subtiles en matière de cache, de routage ou de certificats.

• La gestion des certificats devient vite complexe. Surtout lorsqu’on mélange ACM, CDN externes et proxys multi-couches.

• Les coûts peuvent grimper de façon inattendue. Facturation WAF, heures RDS, nœuds ElastiCache, LCU ALB, journaux CloudFront… tout s’additionne rapidement.

• La maintenance n’est jamais nulle. Même les services managés exigent surveillance, correctifs et débogage.

Ce premier article pose le cadre. Les suivants examineront chaque configuration en profondeur, avec une discussion claire des forces, faiblesses et coût total de possession.

5. Structure prévue de la série

La série comprend les articles suivants :

• Expérience n° 1 — AWS + EC2 + CloudFront + WAF
• Expérience n° 2 — AWS + EC2 + RDS + ElastiCache
• Expérience n° 3 — AWS + EC2 + Cloudflare
• Expérience n° 4 — AWS + EC2 + ALB + CloudFront + WAF
• Chapitre n° 5 — Performance WordPress — réduire le bruit plutôt qu’ajouter de la puissance

6. Conclusion

Cette vue d’ensemble résume les principales pistes explorées pour héberger WordPress sur AWS de façon sécurisée, abordable et avec un minimum de travail continu. Chaque architecture m’a appris des leçons différentes — notamment sur les pièges de coût, la complexité architecturale et les interactions subtiles entre services AWS.

Les prochains articles approfondiront chaque configuration selon une structure cohérente : contraintes → architecture → analyse → avantages/inconvénients → coûts → conclusion.