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

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

1. Objectif de l’expérience

Dans cette deuxième expérience, l’objectif était d’explorer une architecture plus modulaire et évolutive pour héberger plusieurs petits sites WordPress sur AWS.

Plus précisément, je voulais tester si déléguer la base de données à Amazon RDS et externaliser le cache objet vers ElastiCache pouvait compenser une instance EC2 volontairement sous-dimensionnée hébergeant trois sites WordPress.

Les objectifs étaient :

• améliorer les performances avec une instance EC2 légère,
• accroître la modularité en découplant les couches base de données et cache,
• simplifier la mise à l’échelle verticale/horizontale,
• préparer une meilleure résilience et une récupération plus facile,
• évaluer la charge opérationnelle et les coûts réels.

2. Contexte et contraintes techniques

Motivation architecturale

Au lieu d’exécuter tout sur une seule instance EC2 (serveur web + base de données + cache objet), l’idée était de :

• garder l’instance EC2 minimale et économique,
• déplacer la base de données vers Amazon RDS,
• déplacer le cache objet vers ElastiCache (Redis),
• stocker les données WordPress sur EBS pour faciliter le remplacement de l’instance.

Cette séparation s’aligne sur les architectures WordPress haute disponibilité traditionnelles — mais la question était de savoir si cela aide réellement les petits sites.

Exigences de sécurité

• EC2 protégé derrière CloudFront/WAF (comme dans l’expérience n°1).
• RDS placé dans des sous-réseaux privés sans accès public.
• ElastiCache également isolé dans le VPC.
• Security Groups restreints à EC2 uniquement.

Exigences fonctionnelles

• Héberger trois petits sites WordPress avec un trafic faible à moyen.
• Garantir des performances acceptables malgré une instance EC2 modeste.
• Réduire la dépendance monolithique : remplacer EC2 indépendamment de la base de données.

Exigences de coût

• Garder tous les composants petits (db.t3.micro, cache.t3.micro, petite EC2).
• Éviter le multi-AZ inutile ou les classes d’instance surdimensionnées.
• Comparer le coût à une simple configuration EC2 tout-en-un.

Exigences de maintenance

• Maintenir WordPress sur EC2 avec des changements minimaux.
• Déléguer les correctifs de base de données à RDS.
• Éviter de gérer Redis manuellement.

Vue d’ensemble de l’architecture — EC2 + RDS + ElastiCache

3. Architecture testée

3.1. Composants de l’infrastructure AWS

• Instance EC2

  • Petite instance hébergeant Nginx/Apache + PHP + WordPress pour trois sites.
  • EBS utilisé pour /var/www afin de simplifier le remplacement de l’instance.

• Amazon RDS (MySQL/PostgreSQL selon les tests)

  • Service de base de données géré.
  • Sous-réseaux privés uniquement.
  • Sauvegardes automatisées.

• ElastiCache (Redis)

  • Utilisé pour le cache objet WordPress.
  • Également dans des sous-réseaux privés.
  • Connecté via des extensions basées sur Redis (ex. Redis Object Cache).

• VPC + sous-réseaux

  • Sous-réseau public pour EC2.
  • Sous-réseaux privés pour RDS et ElastiCache.

• CloudFront + WAF

  • Même modèle de protection que l’expérience n°1.

3.2. Sécurité de l’infrastructure (architecture AWS)

• EC2 accessible uniquement via CloudFront.
• Accès RDS restreint au Security Group EC2.
• ElastiCache restreint au Security Group EC2.
• Aucun point de terminaison public pour RDS ou Redis.
• SSM pour l’accès à l’instance (pas de SSH exposé).
• Terminaison TLS sur CloudFront via ACM.

3.3. Sécurité applicative (couche WordPress)

La sécurité applicative était similaire à l’expérience n°1 :

• Protections CloudFront/WAF sur wp-login.php.
• Intégration optionnelle avec Twingate ou Cloudflare ZTNA pour l’accès admin.
• Durcissement WordPress (édition de fichiers désactivée, mots de passe robustes, restriction des extensions).
• XML-RPC bloqué.

Rien dans cette expérience n’était fondamentalement différent au niveau applicatif — l’accent principal portait sur l’architecture.

3.4. Flux de trafic de haut niveau

1. CloudFront reçoit la requête et applique les règles WAF.
2. Les requêtes valides atteignent l’instance EC2.
3. L’instance EC2 interroge :
   • RDS pour les opérations de base de données,
   • ElastiCache pour les objets mis en cache.
4. WordPress renvoie la réponse via CloudFront.

3.5. Observations techniques

Cette architecture a introduit des changements majeurs dans le flux des requêtes, avec des sauts réseau supplémentaires entre les composants :

• EC2 ↔ RDS
• EC2 ↔ ElastiCache
• EC2 ↔ CloudFront (récupération à l’origine)

Cela a apporté des avantages — mais aussi des inconvénients significatifs.

4. Résultats et analyse

4.1. Avantages

1. Excellente modularité

La séparation des composants a rendu le système moins monolithique :

• EC2 peut être remplacée facilement sans perte de base de données.
• Les mises à niveau et sauvegardes de base de données sont plus propres avec RDS.
• Le cache Redis peut être ajusté indépendamment.

2. Mise à l’échelle plus facile

Vous pouvez faire évoluer les goulots d’étranglement individuellement :

• CPU/RAM EC2,
• classe d’instance ou stockage RDS,
• ElastiCache si le taux de hit cache est faible.

C’est beaucoup plus flexible qu’une configuration WordPress mono-instance.

3. Conception plus résiliente

• Les sauvegardes et snapshots RDS simplifient la récupération.
• Les fichiers WordPress sur EBS rendent le remplacement EC2 trivial.
• Une indisponibilité EC2 n’impacte plus la base de données.

4.2. Inconvénients

1. Complexité bien plus élevée

Vous devez concevoir :

• les sous-réseaux VPC,
• les tables de routage,
• les Security Groups par composant,
• les paramètres RDS,
• les connexions Redis,
• la logique de basculement et de maintenance.

Cela ajoute beaucoup de charge opérationnelle pour de petits sites.

2. Performances étonnamment dégradées

Pour de petites charges de travail avec de fréquentes petites requêtes WordPress, l’architecture est devenue plus lente :

• Chaque appel DB = saut réseau VPC
• Chaque hit cache = saut réseau VPC
• Instance EC2 sous-dimensionnée → exécution PHP lente
• L’architecture thème/extension a joué un rôle majeur

Dans plusieurs tests, la latence aller-retour base de données a dépassé les bénéfices de RDS géré, surtout avec des thèmes mal codés.

3. Thèmes WordPress sensibles à la latence très performants

Certains thèmes effectuaient 50+ petites requêtes par page, multipliant les appels inter-VPC.

Conclusion :
Les petits sites WordPress bénéficient davantage d’une DB locale + Redis local que de services distribués gérés.

4. Coût plus élevé

Même avec des tailles d’instance minimales :

• Instance micro RDS
• Instance micro ElastiCache
• Transfert de données supplémentaire
• Stockage EBS supplémentaire

→ le coût est devenu significativement plus élevé qu’une simple configuration EC2 seule.

4.3. Coûts estimés

Coût mensuel approximatif :

• EC2 : CHF 8–12
• RDS micro : CHF 15–25
• ElastiCache micro : CHF 15–20
• EBS : CHF 1–3
• CloudFront : CHF 1–15
• WAF : CHF 20–25

Total : ~CHF 60–100 par mois
C’est bien au-dessus de la cible de coût pour de petits sites.

5. Conclusion

Cette expérience montre que scinder WordPress en EC2 + RDS + ElastiCache offre de solides avantages architecturaux :

• meilleure modularité,
• mise à l’échelle plus simple,
• séparation claire des responsabilités,
• résilience améliorée.

Cependant, pour des configurations multi-sites de faible trafic :

• la latence réseau ajoutée,
• la complexité architecturale substantielle,
• le coût plus élevé,
• et la sensibilité à l’implémentation thème/extension

rendent cette approche moins efficace et moins performante qu’une simple configuration EC2 tout-en-un.

Pour la plupart des environnements WordPress de petite taille, un EC2 monolithique avec un cache approprié est non seulement moins cher mais plus rapide.

L’article suivant explore Expérience n° 3 — Cloudflare Tunnel + sécurité Cloudflare, une architecture Cloudflare visant à réduire la complexité tout en renforçant la sécurité.