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 Simple Storage Service (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 AWS Web Application Firewall (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.