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

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

1. Objectif de l’expérience

Cette première expérience évalue une approche entièrement native AWS pour héberger WordPress avec trois contraintes centrales :

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

L’objectif était de déterminer si une conception simple basée sur EC2, protégée par CloudFront et AWS WAF, pouvait réalistement répondre à ces exigences pour un petit site web.

2. Contexte et contraintes techniques

Exigences de sécurité

Les considérations de sécurité ont été réparties en deux couches distinctes :

• Sécurité de l’infrastructure (architecture AWS)
  Protéger l’origine EC2, réduire la surface d’attaque, imposer un filtrage strict au edge et isoler l’application derrière CloudFront et WAF.

• Sécurité applicative (WordPress lui-même)
  Protéger WordPress et ses points de terminaison intrinsèquement vulnérables via des solutions ZTNA, des enveloppes de contrôle d’accès et une authentification sélective.

Exigences fonctionnelles

• Accélération via CDN (mise en cache CloudFront).
• Terminaison TLS cohérente avec ACM.
• Capacité à gérer un trafic modeste sans mise à l’échelle.
• Maintenir une pile simple et compréhensible.

Exigences de coût

• Maintenir les coûts mensuels aussi bas que possible.
• Éviter les frais imprévisibles tels que les requêtes WAF ou l’ingestion de logs CloudFront.
• Rester proche des limites du free tier ou quasi free tier lorsque c’est réaliste.

Exigences de maintenance

• Préférer les certificats gérés aux certificats auto-gérés.
• Éviter l’automatisation ou l’orchestration complexes.
• Limiter le nombre de composants nécessitant des correctifs réguliers.

Schéma d’architecture

3. Architecture testée

3.1. Composants de l’infrastructure AWS

• Instance EC2
  Exécute WordPress (PHP + Nginx/Apache) sur une instance légère avec stockage EBS.

• CloudFront

  • Couche edge principale.
  • Terminaison TLS via ACM.
  • Met en cache le contenu statique et sert de couche de distribution globale.

• AWS WAF

  • Attaché à CloudFront.
  • Règles gérées AWS + règles personnalisées de base.

• Security Groups

  • Seul CloudFront autorisé à atteindre l’origine.
  • SSH désactivé ; SSM Session Manager pour l’accès.

• IAM

  • Permissions minimales pour les rôles d’instance, selon le principe du moindre privilège.

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

Principaux contrôles de sécurité à cette couche :

• Filtrage au edge via AWS WAF (règles gérées + limitation de débit).
• Verrouillage de l’origine pour que l’instance EC2 ne soit pas accessible publiquement.
• Couverture TLS via ACM avec renouvellement automatique.
• Transfert strict des en-têtes pour empêcher le contournement de l’origine.
• Pas de SSH exposé ; tout accès administratif passe par SSM.

3.3. Sécurité applicative (couche WordPress)

WordPress expose plusieurs points de terminaison à haut risque (/wp-login.php, /wp-admin/, xmlrpc.php).

Flux de sécurisation de l’accès admin

1. Twingate ZTNA

• Seuls les utilisateurs authentifiés sur des appareils de confiance pouvaient accéder à l’admin WordPress.
• Trafic routé via un connecteur Twingate privé.
• Sécurité très robuste (identité + posture de l’appareil).
• Inconvénient : perturbe le flux normal du « panneau admin public » ; crée de la friction ; inadapté aux visiteurs anonymes si mal configuré.

2. Cloudflare ZTNA (Access + Tunnel)

• Un Cloudflare Tunnel exposait l’origine EC2 de manière privée — aucune IP d’origine publique.
• Cloudflare Access exigeait l’authentification utilisateur (e-mail, OAuth, etc.) avant d’accéder à /wp-admin.
• Très pratique et extrêmement sécurisé.
• Mais introduit une dépendance à Cloudflare et des composants supplémentaires.

3. Durcissement CloudFront + AWS WAF

• Règles WAF spécifiques pour protéger wp-login.php :
  • limitation de débit,
  • défis CAPTCHA,
  • restrictions géographiques,
  • atténuation des bots.
• XML-RPC entièrement bloqué.
• Fonctionne bien, mais ajoute des coûts et nécessite un réglage continu.

4. Authentification Amazon Cognito (PoC)

• Testé comme « porte d’entrée » avant l’admin WordPress.
• Techniquement possible avec CloudFront Functions ou Lambda@Edge.
• Ajoute une sécurité renforcée, mais :
  • augmente la complexité architecturale,
  • complique les flux de connexion,
  • problématique pour les extensions qui s’attendent à l’authentification WordPress native.

3.4. Flux de trafic de haut niveau

1. Le visiteur se connecte à CloudFront en HTTPS.
2. CloudFront applique les règles WAF, les en-têtes et les politiques TLS.
3. CloudFront transmet les requêtes valides à l’origine EC2.
4. WordPress traite les requêtes dynamiques ; les ressources statiques sont mises en cache au edge.

3.5. Observations techniques

• CloudFront exige une conception soignée des politiques de cache pour ne pas casser les pages admin WordPress.
• Les règles WAF sont puissantes mais peuvent devenir coûteuses rapidement.
• Le débogage des problèmes impliquant cache, cookies et en-têtes transférés n’est pas trivial.
• Les solutions de sécurité applicative (ZTNA, Cognito) renforcent la protection mais augmentent la complexité.

4. Résultats et analyse

4.1. Avantages

• Architecture entièrement native AWS avec une excellente intégration.
• Sécurité infrastructure solide via CloudFront + WAF.
• Performances globales très bonnes grâce au cache CloudFront.
• Certificats ACM simplifient la gestion TLS.
• SSM Session Manager supprime le besoin d’exposer SSH.
• Plusieurs options ZTNA testées (Twingate, Cloudflare) ont montré que l’accès admin peut être durci efficacement.

4.2. Inconvénients

• Complexité de configuration significative, même pour un petit site.
• Coûts WAF pouvant augmenter rapidement selon le volume de trafic.
• CloudFront + WordPress nécessite des ajustements non triviaux de la logique de cache.
• ZTNA + WordPress peut perturber les flux de travail et compliquer le comportement des extensions.
• Maintenance EC2 reste de votre responsabilité (OS, PHP, mises à jour WordPress).
• Intégration Cognito difficile et source de friction importante.
• Visibilité des erreurs faible lorsqu’un problème survient entre CloudFront → origine → WordPress.

4.3. Coûts estimés

Coût mensuel approximatif (scénario faible trafic) :

• Instance EC2 : CHF 8–12
• Stockage EBS : CHF 1–3
• CloudFront : CHF 1–15
• AWS WAF : CHF 20–25 minimum
• Monitoring / logs : CHF 1–5

Total : ~CHF 30–50 par mois.

C’est plus élevé que prévu pour un simple site WordPress et ne répond pas à l’objectif de « coût très bas ».

5. Conclusion

L’expérience n°1 offre une sécurité edge solide et des protections robustes natives AWS, mais révèle aussi des limites claires :

• Les solutions ZTNA (Twingate, Cloudflare Access) sont puissantes mais ajoutent de la friction opérationnelle.
• WAF apporte une protection significative mais avec un coût imprévisible.
• Cognito introduit une lourde complexité architecturale.
• L’instance EC2 nécessite toujours une maintenance et des correctifs réguliers.

Bien que la configuration soit sécurisée et performante, elle ne répond pas à l’objectif de « coût minimal et maintenance minimale » pour une petite installation WordPress.

L’article suivant explore une approche différente : Expérience n° 2 — EC2 + RDS + ElastiCache découple la stack ; Expérience n° 3 — Cloudflare Tunnel simplifie la couche de sécurité avec Cloudflare (CDN + WAF + Access) à la place de CloudFront + AWS WAF.