AWS CloudFront VPC Origin : Sécurisez et Optimisez vos sites web publics

Amazon CloudFront est l'un de mes services AWS préférés. Grâce à cet outil, nous pouvons exposer des sites sur Internet, qu'ils soient statiques ou dynamiques, hébergés ou non sur AWS, avec une sécurité renforcée.

Grâce à son déploiement au plus près de l'utilisateur, depuis 2008 ce service permet de distribuer le contenu avec les meilleures performances.

Pour mettre du contenu à disposition de CloudFront, nous avons 2 possibilités principales :

• Utiliser Amazon S3 ou AWS Lambda par exemple en utilisant les Origin Access Control

• Utiliser un équilibreur de charge (Load Balancer) ou une instance publique.

Dans la suite de l'article, nous allons nous concentrer sur le cas de l'équilibreur de charge public.

Les groupes de sécurité (Security Groups) doivent être bien configurés pour ne permettre l'accès que depuis CloudFront. Des protections supplémentaires peuvent être mises en place comme un WAF par exemple, qui offre une protection avancée contre les attaques web, mais ceci engendre des coûts additionnels.

Il est possible également d'utiliser un header pour identifier notre distribution CloudFront, mais cette technique ne protège pas contre les tentatives de connexions. Elles sont arrêtées au plus tôt au niveau de l'ALB, mais elles polluent les logs et peuvent impacter les performances.

Voici un exemple de règle de groupe de sécurité permettant un accès uniquement via CloudFront en HTTPS :

Type	Protocol	Port	Source
HTTPS	TCP	443	pl-4fa04526 (com.amazonaws.global.cloudfront.origin-facing)

Ces points d'accès peuvent être découverts via un scan d'IP systématique ou en listant les sous-domaines d'une entrée DNS, et être la cible d'attaques malveillantes (DDoS, DoS, tentative d'exploitation de faille etc.). Si l'instance EC2 derrière le load balancer a un serveur web avec une faille de sécurité critique et que le groupe de sécurité en amont permet du trafic ne venant pas de CloudFront, votre instance et par extension votre VPC pourraient être compromis.

Exemple de règle trop permissive :

Type	Protocol	Port	Source
HTTPS	TCP	443	0.0.0.0/0

Le meilleur moyen d'éviter cela est de garder la source de CloudFront privée, ce qui est possible depuis le 20 novembre 2024 avec les origines VPC sécurisées. Nous pouvons ainsi enlever la partie publique de nos VPCs, et nous pouvons également bloquer l'accès public aux VPCs de manière systématique (https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/security-vpc-bpa.html).

Avec cette architecture, nous réduisons également le besoin d'IPs privées par VPC en enlevant les subnets publics, ce qui est un premier point intéressant pour certaines compagnies où l'adressage privé est un sujet critique.

Nous remplaçons le load balancer public par un privé, ce qui réduit la surface d'exposition de manière significative. S'il y avait déjà un load balancer privé qui exposait ce service, nous faisons donc une petite économie en enlevant un composant redondant.

Une question demeure. En modifiant cette architecture, est-ce que nous modifions les performances de notre service ? Nous allons le vérifier en mettant en place une page Nginx sur une instance EC2 t3.micro à Singapour, et en testant les performances à partir de nos locaux (Lyon - France) ainsi que d'une session CloudShell se trouvant en Irlande. Ce serveur Nginx sera exposé par un Load Balancer public et également via une VPC origin sur CloudFront.

Dans un premier temps, nous n'activerons pas le cache en périphérie pour avoir des résultats objectifs (Si nous l'activions, le contenu ne serait plus récupéré sur le serveur Nginx à Singapour, mais sur l'edge CloudFront le plus proche contenant une copie). Nous ferons une dernière série de tests avec le cache activé, pour montrer l'efficacité d'un cache CloudFront bien configuré avec TTL standard quand on accède à des données qui sont très éloignées.

Nous allons donc effectuer 10 appels curl successifs et synchronisés à la suite pour avoir quelques statistiques intéressantes et fiables (Moyenne, Max, P90, Latence...).

Voici le résultat détaillé de nos tests :

Temps total (mesures complètes)

	Req1	Req2	Req3	Req4	Req5	Req6	Req7	Req8	Req9	Req10
Irlande CloudFront	0.394960s	0.191579s	0.194875s	0.189899s	0.191891s	0.207810s	0.193402s	0.205370s	0.197298s	0.368063s
Irlande ALB	0.364543s	0.367283s	0.363094s	0.366604s	0.359450s	0.362647s	0.361881s	0.365909s	0.365682s	0.365236s
Lyon CloudFront	0.407051s	0.211910s	0.238359s	0.201906s	0.369832s	0.201490s	0.206589s	0.218557s	0.542900s	0.202360s
Lyon ALB	0.361772s	0.322014s	0.322883s	0.317526s	0.315286s	0.317379s	0.318128s	0.316579s	0.321974s	0.324912s
Lyon CloudFront + cache	0.442350s	0.043860s	0.034697s	0.043316s	0.035482s	0.041478s	0.046235s	0.033241s	0.036595s	0.029393s

	Moyenne (sec)	Plus longue (sec)	Plus rapide (sec)	P90 (percentile)
Irlande CloudFront	0.2335147s	0.39496s	0.189899s	0.21557633s
Irlande ALB	0.3642329s	0.367283s	0.35945s	0.363894s
Lyon CloudFront	0.2800954s	0.5429s	0.20149s	0.25089489s
Lyon ALB	0.3238453s	0.361772s	0.315286s	0.31963122s
Lyon CloudFront + cache	0.0786647s	0.44235s	0.029393s	0.03825522s

Comme on peut le voir, les performances sont meilleures en passant par CloudFront, ce qui s'explique aisément par le fait que la requête qui arrive sur CloudFront au plus près de l'utilisateur est ensuite envoyée via les backbones AWS vers la bonne ressource (chemin 1-2-3 et 21-22-23) sur le schéma suivant, optimisant ainsi le temps de latence global.

Dans le cas de l'ALB, on effectue une résolution DNS, puis on passe par internet pour joindre la ressource (chemin 10-11 et 31-32). Nous passons par des ressources publiques et par plusieurs relais que nous ne maîtrisons pas, ce qui allonge les délais de réponses et peut introduire une variabilité importante.

Comme on peut le voir dans les résultats, utiliser le cache CloudFront à la périphérie est la solution la plus performante, ce qui n'est pas une surprise étant donné que le trajet est beaucoup plus court (chemin 1-2 seulement) et bénéficie de l'infrastructure optimisée d'AWS.

La solution via CloudFront et VPC Origin n'est donc pas seulement plus sécurisée, mais aussi plus performante qu'une exposition via un ALB, grâce à la mise en cache globale.

Cette solution est très efficace pour les sites Internet ou l'exposition de contenu de taille importante. Si vous exposez une API via votre ALB, cette solution peut néanmoins devenir coûteuse. Le modèle de facturation de CloudFront étant basé sur les données sortantes ET sur le nombre de requêtes. Dans le cas d'une API, il y a de très nombreuses petites requêtes, ce qui peut rendre l'exposition via CloudFront plus coûteuse que via un ALB classique.

On peut donc dire que les VPC Origins pour CloudFront apportent une nouvelle façon d'exposer le contenu, en ajoutant une seconde couche de protection contre les mauvaises manipulations et les attaques externes. Même si vous définissez une règle en 0.0.0.0/0 pour le HTTP(S) dans votre Security Group, vos ressources étant en privé, elles resteront inaccessibles via Internet. Si vous n'avez pas encore ajouté CloudFront en première ligne de votre exposition Internet, je vous engage à le faire rapidement. Vous pourrez ainsi profiter de performances réseau accrues et d'une sécurité renforcée.