Hébergement WordPress sur AWS — Vue d'ensemble de la série

Expérience n°3 — AWS EC2 + Cloudflare Tunnel + Sécurité Cloudflare

1. Objectif de l’expérience

Cette expérience explore une architecture alternative où Cloudflare remplace entièrement CloudFront et AWS WAF, en jouant le rôle de :

  • proxy inverse,
  • couche CDN,
  • couche de sécurité (WAF, filtrage de bots),
  • fournisseur ZTNA (Cloudflare Access),
  • et, en option, autorité DNS.

L’objectif était d’évaluer si Cloudflare pouvait simplifier la stack, réduire les coûts et améliorer la sécurité d’un site WordPress — tout en gardant l’instance EC2 totalement invisible sur Internet public grâce à Cloudflare Tunnel.

2. Contexte et contraintes techniques

Motivation architecturale

Après avoir constaté que la configuration native AWS était lourde et coûteuse, j’ai voulu tester une approche radicalement différente :

  • Masquer EC2 derrière un Cloudflare Tunnel,
  • Laisser Cloudflare gérer TLS, cache, WAF et ZTNA,
  • Éliminer toute exposition de l’origine,
  • Supprimer le coût d’AWS WAF et réduire la complexité de CloudFront,
  • Utiliser le généreux plan gratuit de Cloudflare pour abaisser le coût global.

Exigences de sécurité

  • EC2 doit être totalement non publique (aucune IP publique joignable).
  • L’accès admin à /wp-login.php et /wp-admin doit être restreint.
  • Les attaques de bots et les tentatives de force brute doivent être éliminées.
  • Aucun contournement de l’origine ne doit être possible.

Exigences fonctionnelles

  • Mêmes performances (ou meilleures) qu’avec CloudFront.
  • Fonctionnement WordPress transparent.
  • Aucune rupture des fonctionnalités dynamiques ou de l’interface d’administration.
  • Possibilité d’utiliser AWS Lambda@Edge pour le redimensionnement dynamique d’images.

Exigences de coût

  • Rester dans le plan gratuit de Cloudflare (Access + Tunnel + CDN).
  • Éviter les frais AWS supplémentaires pour le trafic ou le WAF.
  • Garder une infrastructure minimaliste (EC2 + EBS uniquement).

Exigences de maintenance

  • Implication administrative minimale.
  • Pas de configuration AWS multi-services compliquée.
  • Idéalement plus simple que la configuration CloudFront/WAF.

Vue d’ensemble de l’architecture — EC2 masqué derrière Cloudflare Tunnel

Origine WordPress entièrement masquée derrière Cloudflare Tunnel, avec DNS, CDN, WAF et ZTNA gérés en périphérie Cloudflare.
Figure A — Origine WordPress entièrement masquée derrière Cloudflare Tunnel, avec DNS, CDN, WAF et ZTNA gérés en périphérie Cloudflare.

3. Architecture testée

3.1. Composants de cette configuration

  • Cloudflare Tunnel

    • Architecture sans origine exposée.
    • EC2 n’est jamais exposé à Internet public.

  • Cloudflare CDN

    • Mise en cache en périphérie similaire à CloudFront.

  • Cloudflare Access (ZTNA)

    • Utilisé pour protéger les points de terminaison d’administration WordPress.

  • Cloudflare DNS

    • Requis pour une intégration optimale (bien que cela ait introduit des problèmes).

  • Instance EC2

    • WordPress + PHP + Nginx/Apache.
    • Aucun trafic public.

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

  • EC2 n’a aucune entrée publique du tout.
  • Security Groups restreints au connecteur Cloudflare Tunnel uniquement.
  • Accès SSM pour l’administration (pas de SSH).
  • TLS entièrement déchargé sur Cloudflare.
  • Pas besoin de CloudFront, AWS WAF, ACM ou ELB.

Cela a considérablement réduit la complexité côté AWS et la surface d’attaque.

3.3. Sécurité applicative (couche WordPress)

Cloudflare a fourni plusieurs couches de protection :

1. Cloudflare Access (ZTNA)

  • Authentification ajoutée avant d’atteindre l’admin WordPress.
  • Protection très robuste : par e-mail, par identité ou via OAuth.
  • Élimination totale des attaques par force brute.

2. Cloudflare WAF + Bot Management

  • Blocage des crawlers malveillants.
  • Réduction drastique du bruit d’attaque.
  • Mais : le « Bot Fight Mode » et d’autres filtres agressifs cassaient souvent l’admin WordPress.

3. Isolation via Cloudflare Tunnel

  • Seuls les nœuds de périphérie Cloudflare peuvent atteindre l’origine.
  • Supprime la possibilité d’attaques directes sur l’IP EC2.

3.4. Flux de trafic de haut niveau

  1. Le visiteur atteint le point de terminaison HTTPS Cloudflare.
  2. Cloudflare applique :
    • le routage DNS,
    • les règles WAF,
    • le filtrage de bots,
    • le ZTNA (si accès admin).
  3. Cloudflare Tunnel se connecte à l’origine EC2.
  4. WordPress génère la réponse.

3.5. Observations techniques

1. La configuration de Cloudflare Tunnel n’est pas « plug and play »

Malgré un marketing orienté simplicité :

  • la configuration prend du temps,
  • il faut installer et exécuter le connecteur,
  • il faut gérer l’authentification et le routage,
  • le débogage peut être pénible si le tunnel tombe.

Et si le tunnel tombe, le site est totalement hors ligne. Il n’y a aucun repli gracieux.

2. Migrer tout le DNS vers Cloudflare est pénible

C’était un inconvénient opérationnel majeur :

  • Les zones DNS volumineuses et complexes (p. ex. enregistrements Microsoft 365) exigent une migration minutieuse.
  • Les services AWS comme :
    • la validation de certificat ACM,
    • les sites statiques S3,
    • les domaines alternatifs CloudFront deviennent plus difficiles à gérer lorsque le DNS est externe.
  • L’interface DNS de Cloudflare est puissante mais extrêmement chargée.

La migration DNS vers Cloudflare n’est pas triviale pour les environnements multi-services.

3. Aucune différence de vitesse notable par rapport à CloudFront

Contrairement aux attentes :

  • les performances étaient équivalentes à CloudFront,
  • parfois plus lentes à cause de la surcharge simulée du Tunnel,
  • les requêtes dynamiques n’ont pas progressé.

4. Problèmes de compatibilité WordPress

Notamment :

  • les défis bot Cloudflare cassant /wp-admin,
  • des en-têtes de sécurité forcés entrant en conflit avec le flux de connexion WordPress,
  • une mise en cache appliquée par erreur aux pages d’administration dynamiques.

5. Les fonctions AWS Lambda (redimensionnement d’images) sont devenues très lentes

Le redimensionnement dynamique d’images via Lambda@Edge a effondré les performances, même derrière Cloudflare.

Cette architecture a amplifié les cold starts Lambda AWS et la latence de routage.

6. L’interface Cloudflare change constamment

Le tableau de bord souffre de :

  • refontes UI fréquentes,
  • fonctionnalités déplacées quotidiennement,
  • navigation peu intuitive,
  • flux de configuration incohérents.

Comparable au « meilleur de Microsoft 365 » — au sens ironique.

7. Panne Cloudflare = panne totale

Puisque Cloudflare Tunnel est le réseau, il n’y a aucun basculement d’origine.

Si Cloudflare connaît une panne, tout disparaît instantanément.

4. Résultats et analyse

4.1. Avantages

  • EC2 totalement masqué d’Internet public.
  • Excellent ZTNA via Cloudflare Access.
  • Coût Cloudflare = zéro (plan gratuit).
  • WAF et atténuation de bots robustes (une fois réglés).
  • Pas de frais AWS WAF et pas de complexité CloudFront.
  • Architecture d’origine simple (EC2 + EBS uniquement).

4.2. Inconvénients

  • Cloudflare Tunnel est un point de défaillance unique.
  • La migration DNS est complexe et risquée pour les environnements multi-services.
  • La protection bot casse fréquemment l’admin WordPress.
  • Aucune amélioration de performance par rapport à CloudFront.
  • Le redimensionnement dynamique d’images via AWS Lambda devient extrêmement lent.
  • L’interface Cloudflare est chaotique, changeante et peu intuitive.
  • Panne Cloudflare = panne complète.
  • Certains plugins/thèmes WordPress se comportent encore de façon imprévisible derrière un Tunnel.

4.3. Analyse des coûts

  • Cloudflare : plan gratuit (Tunnel, Access, CDN, WAF).
  • EC2 : CHF 8–12
  • EBS : CHF 1–3
  • Pas d’AWS WAF : économie d’environ CHF 20–25/mois
  • CloudFront non utilisé : économie supplémentaire de CHF 1–15/mois

Total : ~CHF 10–15 par mois (selon la taille d’EC2)

C’est de loin l’expérience la moins chère jusqu’ici.

5. Conclusion

L’architecture Cloudflare Tunnel apporte une sécurité exceptionnelle (ZTNA, origine invisible, WAF robuste) et le coût le plus bas de toutes les expériences.

Mais elle introduit aussi plusieurs inconvénients majeurs :

  • complexité opérationnelle,
  • casse-têtes de migration DNS,
  • problèmes de compatibilité avec WordPress et les fonctionnalités AWS,
  • fragilité du tunnel,
  • neutralité de performance par rapport à CloudFront,
  • instabilité de l’interface Cloudflare,
  • et le risque d’une panne totale si Cloudflare tombe.

Pour les petits sites, cela peut fonctionner — mais ce n’est pas du « installer et oublier ». Pour les environnements utilisant massivement les services AWS, la gestion devient difficile.

L’article suivant explore l’architecture plus avancée (et plus alignée AWS) : Expérience n° 4 — EC2 + ALB + CloudFront + WAF, et si elle offre un meilleur équilibre entre sécurité, performance et maintenabilité.

Articles connexes