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

Expérience n°4 — AWS EC2 + ALB + CloudFront + AWS WAF + Cognito + Origine VPC

1. Objectif de l’expérience

Cette expérience évalue une architecture WordPress de niveau production entièrement sur AWS, utilisant :

• CloudFront comme couche de périphérie globale et de cache,
• AWS WAF pour une sécurité maîtrisée et prévisible,
• Application Load Balancer (ALB) pour un routage propre et l’intégration Cognito,
• Amazon Cognito pour un accès admin basé sur l’identité,
• Origine VPC / connectivité CloudFront→VPC pour garantir un trafic privé et interne uniquement,
• EC2 comme origine WordPress.

L’objectif était d’atteindre le plus haut niveau de sécurité, avec un coût raisonnable, une facturation prévisible et une compatibilité maximale avec WordPress — sans dépendre de Cloudflare ni de fournisseurs ZTNA externes.

2. Contexte et contraintes techniques

Motivation architecturale

Les expériences précédentes ont révélé des lacunes :

• Les configurations 100 % AWS (EC2 + WAF) étaient sécurisées mais trop complexes et coûteuses.
• Les architectures RDS + ElastiCache étaient surdimensionnées et même plus lentes pour les petits sites.
• Cloudflare Tunnel offrait une excellente sécurité mais trop d’inconvénients opérationnels.

Le but de cette expérience était de construire une architecture équilibrée, moderne et durable :

• séparation claire des couches,
• connectivité privée de bout en bout,
• coûts WAF prévisibles,
• intégration Cognito propre,
• posture de sécurité robuste sans fragilité du tunnel.

Exigences de sécurité

• EC2 et ALB ne doivent pas être exposés à Internet public.
• CloudFront doit communiquer avec l’ALB via une connectivité privée (Origine VPC / PrivateLink).
• Cognito doit imposer l’authentification avant l’accès à l’admin WordPress.
• Le WAF doit bloquer le trafic malveillant globalement avant qu’il n’atteigne AWS.
• Tout le TLS géré par ACM avec des politiques de chiffrement robustes.

Exigences fonctionnelles

• Zéro friction administrative pour la connexion WordPress.
• Comportements CloudFront propres et prévisibles.
• Support complet des fonctionnalités dynamiques WordPress.
• Fiabilité et facilité de débogage.

Exigences de coût

• Le coût ALB doit être compensé par un comportement WAF plus simple et moins de règles.
• Le nouveau forfait forfaitaire AWS WAF (automne 2025) doit réduire l’imprévisibilité.
• Cible globale de l’architecture : 50–60 USD/mois.

Exigences de maintenance

• Garder un nombre de composants raisonnable et aligné sur les bonnes pratiques AWS.
• Minimiser les CloudFront Functions ou contournements personnalisés.
• Laisser Cognito gérer la protection basée sur l’identité plutôt que des astuces WAF.

Architecture finale — CloudFront + ALB + Cognito (origine VPC)

3. Architecture testée

3.1. Composants AWS

• CloudFront (CDN de périphérie + terminaison TLS)

  • Utilise Origin Access Control (OAC).
  • Se connecte en privé à l’ALB via CloudFront VPC Origin / PrivateLink.
  • Aucune exposition publique.

• AWS WAF

  • Appliqué sur CloudFront pour un filtrage global.
  • Jeu de règles bien plus simple grâce à ALB + Cognito.

• Application Load Balancer (ALB)

  • Sous-réseaux privés uniquement.
  • Non joignable publiquement.
  • Effectue le routage et l’authentification Cognito.

• Cognito

  • Protège /wp-admin et /wp-login.php.
  • MFA, OAuth ou user pools pris en charge.

• VPC Endpoints

  • VPC Endpoint pour l’origine CloudFront (PrivateLink).
  • Endpoints S3 et SSM optionnels pour un fonctionnement entièrement privé.

• EC2 (WordPress)

  • Instance privée derrière l’ALB uniquement.
  • EBS stocke les fichiers WP pour un remplacement facile de l’instance.

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

La sécurité est considérablement renforcée grâce à :

• ALB privé uniquement : aucune entrée publique du tout.

• CloudFront→ALB via Origine VPC / PrivateLink :

  • le trafic ne touche jamais Internet public,
  • CloudFront communique avec l’ALB via un chemin interne AWS.

• OAC (Origin Access Control) garantit que CloudFront est le seul appelant autorisé.

• AWS WAF sur CloudFront filtre les menaces avant même qu’elles n’atteignent les couches réseau AWS.

• Cognito sur l’ALB ajoute une protection admin basée sur l’identité.

• SSM Session Manager pour EC2 — pas de SSH exposé.

• Security Groups stricts :

  • endpoint CloudFront → ALB
  • ALB → EC2
  • Aucune exposition latérale.

C’est l’une des postures de sécurité WordPress les plus robustes possibles sur AWS.

3.3. Sécurité applicative (couche WordPress)

Cognito et le WAF simplifient drastiquement la sécurité applicative :

1. Authentification Cognito sur l’ALB

• Protège /wp-admin et /wp-login.php.
• Les attaques par force brute disparaissent entièrement.
• Fonctionne parfaitement avec WordPress lorsqu’il est fait sur l’ALB (pas sur CloudFront).
• Plus propre que Cloudflare Access ou une auth basée sur Lambda@Edge.

2. Règles WAF minimales

Puisque l’admin est protégé par Cognito, le WAF n’a besoin de couvrir que :

• les exploits courants,
• les attaques de bots,
• la limitation de débit.

Le coût WAF est réduit et prévisible.

3. WordPress à origine privée

Comme l’ALB et EC2 ne sont jamais publics :

• pas de fuite d’IP d’origine,
• pas de scans directs,
• pas d’attaques de contournement.

3.4. Flux de trafic de haut niveau

1. Le visiteur se connecte à CloudFront en HTTPS.
2. Le WAF applique l’inspection globale.
3. CloudFront utilise Origin Access Control + Origine VPC pour appeler l’ALB privé.
4. L’ALB décide :
   • Chemin protégé → authentification Cognito,
   • Chemin public → transfert direct.
5. L’ALB transmet le trafic à l’instance EC2 privée.
6. WordPress génère la réponse ; CloudFront met en cache les ressources statiques.

3.5. Observations techniques

1. L’ALB simplifie drastiquement le comportement CloudFront

• Fini les règles regex compliquées.
• Le routage est propre et explicite.
• Le WAF a besoin de moins d’exceptions.

2. L’intégration Cognito est bien plus simple au niveau ALB

• Pas de CloudFront Functions requises.
• Pas de réécriture d’en-têtes.
• Pas de logique Lambda@Edge complexe.

3. L’origine VPC ajoute une sécurité importante

• La connexion entre CloudFront et l’ALB est privée, interne uniquement.
• Internet public est entièrement contourné.
• Réduit l’exposition aux attaques à quasi zéro.

4. Les coûts WAF deviennent prévisibles

Le forfait forfaitaire AWS WAF (fin 2025) est une énorme amélioration :

• coût mensuel fixe,
• facturation simplifiée,
• parfait pour les sites petits à moyens.

5. L’ALB n’est pas un load balancer ici

Bien qu’il s’appelle « load balancer » :

• nous utilisons surtout ses fonctions de routage et d’authentification,
• pas la répartition de charge.

6. Plus de composants = plus de complexité

Par rapport à Cloudflare, vous gérez :

• CloudFront,
• WAF,
• ALB,
• Cognito,
• VPC Endpoints,
• EC2.

Mais l’architecture résultante est plus robuste, plus prévisible et entièrement sous votre contrôle.

4. Résultats et analyse

4.1. Avantages

• Architecture la plus sécurisée testée — de loin.
• L’origine VPC garantit que CloudFront–ALB est entièrement privé.
• Cognito sur l’ALB offre une protection admin propre et moderne.
• L’ALB simplifie drastiquement les règles WAF et les comportements de cache.
• Coût WAF prévisible grâce au forfait forfaitaire.
• Compatibilité WordPress parfaite (pas de problèmes bot/CAPTCHA comme avec Cloudflare).
• Aucune dépendance externe ; tous les services sont natifs AWS.
• Très stable — pas de tunnel fragile comme Cloudflare.

4.2. Inconvénients

• Complexité plus élevée : nécessite une connaissance approfondie d’AWS.
• L’ALB coûte ~25 USD/mois, inévitablement.
• Le temps de configuration initial est plus long qu’avec Cloudflare.
• Plus de pièces mobiles qu’une configuration basée sur Cloudflare.

4.3. Coûts estimés (2025)

Approximatif :

• EC2 : 8–12 USD
• EBS : 1–3 USD
• CloudFront : 1–10 USD
• ALB : ~25 USD
• WAF (forfait forfaitaire) : ~10–15 USD
• VPC Endpoints + logs : 3–5 USD

Total : ~50–60 USD/mois

C’est dans la fourchette attendue pour un hébergement WordPress sécurisé, maintenable et de niveau professionnel.

5. Conclusion

Cette architecture — EC2 + ALB + CloudFront + WAF + Cognito + Origine VPC — offre la meilleure combinaison de :

• sécurité,
• performance,
• coût prévisible,
• stabilité opérationnelle,
• maintenabilité native AWS,
• compatibilité WordPress,
• absence de dépendances externes.

Bien qu’elle ne soit pas la configuration la plus simple, c’est de loin celle avec la posture de sécurité la plus robuste et le modèle opérationnel long terme le plus propre.

Pour les installations WordPress petites mais sérieuses, c’est la meilleure architecture testée dans toute la série.

Poursuivre avec le Chapitre n° 5 — Performance WordPress : réduire le bruit (bots, requêtes inutiles) s’est révélé plus efficace que d’ajouter de l’infrastructure.