Amazon CloudFront
Photo de Tom Morbey sur Unsplash

Amazon CloudFront

Amazon CloudFront accélère la distribution des contenus web statiques et dynamiques tels que les pages html, css, php, images et fichiers multimédias. Lorsque les utilisateurs demandent du contenu, CloudFront le diffuse à travers un réseau mondial de Edge Locations qui offrent une latence faible et des performances élevées.

Voyons son fonctionnement en détail.

Présentation

Amazon CloudFront est un réseau rapide de diffusion de contenu (Content Delivery Network) qui repose sur un système de Caches répartis sur les 230 points de présence (PoPs) de AWS et qui sont interconnectés via la dorsale AWS.

Emplacements des Edge Locations au niveau mondial
Emplacements des Edge Locations au niveau mondial
  • CloudFront offre des fonctions de sĂ©curitĂ© comme :
    • Protection des attaques rĂ©seaux et anti-DDoS
    • Protocole HTTPS
    • Chiffrement au niveau des champs
  • Il s’intègre Ă  AWS Shield, AWS Web Application Firewall et Amazon Route 53
  • Il fonctionne avec n’importe quelle origine :
    • Toutes les origines AWS Amazon S3 Bucket ou WebSite, Amazon EC2, Elastic Load Balancing
    • N’importe quelle terminaison HTTP on-premise

Mécanismes avancés

  • CloudFront permet de configurer diffĂ©rentes Origins (Multiple Origins) en fonction du type de contenu ou du chemin (pattern) du contenu.

  • De mĂŞme, un Origin Group constituĂ© d’une Origine Primaire et Secondaire permet de mettre en place un mĂ©canisme de failover dans le cas oĂą l’Origine Primaire renverrait une erreur.

  • Enfin, il existe un mĂ©canisme de chiffrement asymĂ©trique de champ (Field Level encryption) qui permet Ă  partir de l’Edge Location de chiffrer un champ de formulaire qui ne pourra ĂŞtre dĂ©chiffrĂ© que par le Serveur Web.

Architectures

En fonction de l’origine, CloudFront s’intègre dans 2 types d’architecture.

Bucket S3

Architecture CloudFront avec S3 Bucket comme Origin et une Origin Access Identity
Architecture CloudFront avec S3 Bucket comme Origin et une Origin Access Identity

HTTP End-Point (ALB, EC2)

Architecture CloudFront avec un ALB (HTTP) comme Origin
Architecture CloudFront avec un ALB (HTTP) comme Origin

Securité

Geo Restriction

CloudFront permet de filtrer les utilisateurs par Pays. Une base de données reliant adresses IP et pays d’appartenance permet de n’autoriser que certains pays (whitelist) à accéder à une ressource ou bien, au contraire, de bloquer l’accès à certains pays (blacklist)

HTTPS

CloudFront permet de contrôler le protocole de transport utilisé entre les différents points avec des Protocol Policy :

  • Viewer Protocol Policy :
    • Du client Ă  l’Edge Location
    • Permet de forcer le protocol HTTPS ou de rediriger les appels HTTP vers HTTPS
  • Origin Protocol Policy :
    • De l’Edge Location vers l’Origine (Bucket S3 ou Server HTTP)
    • Permet de choisir entre HTTP et HTTPS

Signed URL / Signed Cookie

Cette fonctionalité de CloudFront permet de mettre à disposition du contenu pendant un certain lapse de temps :

  • Signed URL : met Ă  disposition un fichier Ă  tout utilisateur possĂ©dant cette URL
  • Signed Cookie : met Ă  disposition plusieurs fichiers Ă  tout utilisateur qui possède ce cookie

Le temps de valididité dépend du contenu que l’on souhaite partager :

  • Contenu payant, location pendant 24h,…
  • Espace de stockage rĂ©servĂ© pendant 1 an,…

Ne pas confondre les Signed URLs de CloudFront avec les Pre-Signed URLs de S3

Génération à partir des Trusted Key Groups

A présent, AWS recommande d’utiliser les Trusted Key Groups afin de générer des Signed URL / Cookie. En effet :

  • La gestion (crĂ©ation, rotation,…) des Trusted Key Groups se fait entièrement au moyen des APIs AWS
  • L’utilisation de ces APIs est protĂ©gĂ©e par un Role IAM

Un Trusted Key Groups consiste en :

  1. Une clé privé servant à signé une URL ou un Cookie
  2. Une clé publique servant vérifier que la signature est valide

CloudFront Caching

Le contenu peut être mis en Cache en fonction de 3 critères différents :

  • Header
  • Session Cookie
  • Paramètre d’URL

Le Time To Live (TTL) peut aller de 0s à 1 an et dépend du type de contenu :

  • Pour un contenu statique : le TTL peut ĂŞtre grand car c’est un contenu qui ne change pas beaucoup et c’est une bonne façon de de rĂ©duire la latence. Les critères de Headers et Cookie ne devraient pas rentrer en compte mais uniquement l’URL.
  • Pour un contenu dynamique : le TTL devrait ĂŞtre faible et se baser sur les Headers et les Cookies afin de maximiser le cache sans risquer de dĂ©livrer du contenu obsolète.

Il est possible aussi d’invalider un contenu spécifique des caches (en fonction de patterns) afin que tous les Edge Locations mettent à jour leur cache avec une nouvelle version du contenu.

Price Classes

Parce qu’il existe plus de 230 Edge Locations, le coût de CloudFront peut vite augmenter. Il est possible de réduire ce coût en sélectionnant les Edge Locations en fonction de leur prix par Region.

Pour cela, il existe 3 classes de prix que l’on peut sélectionner :

  • Price Class All : toutes les Regions, coĂ»t Ă©levĂ© mais meilleures performances
  • Price Class 200 : la plupart des Regions mais supprime celles qui ont le coĂ»t le plus Ă©levĂ©
  • Price Class 100 : les Regions les moins chères
Jean-Jerome Levy

Ecrit par

Jean-JĂ©rĂ´me LĂ©vy

Consultant DevOps

Professionnel chevronné dans le domaine de l’informatique, cumulant plus de 20 années d’expérience au sein de DSI de grandes entreprises, mon expertise diversifiée m’a permis de jouer un rôle clé dans de nombreux projets, caractérisés par la mise en place de pratiques DevOps innovantes.