Distributions CloudFront et origines

Amazon CloudFront est le réseau mondial de diffusion de contenu (CDN) d’AWS. Il met en cache et distribue le contenu depuis des emplacements périphériques répartis dans plus de 400 villes de plus de 90 pays. Lorsqu’un utilisateur demande du contenu, CloudFront le diffuse depuis l’emplacement périphérique le plus proche, ce qui réduit considérablement la latence par rapport à une récupération depuis le serveur d’origine.

CloudFront ne sert pas uniquement aux fichiers statiques : il accélère également le contenu dynamique, les API et la diffusion vidéo en continu. Il s’intègre à d’autres services AWS tels que S3, ALB, Lambda@Edge, WAF et Shield, ce qui en fait la couche de distribution standard des architectures AWS modernes.

Une distribution CloudFront est l’unité de configuration principale. Elle définit : une ou plusieurs origines (l’emplacement du contenu), les comportements de mise en cache (la manière dont les différents chemins d’URL sont mis en cache), les paramètres de sécurité et les niveaux de tarification. Vous accédez à votre contenu via le nom de domaine de la distribution (par exemple, d1234abcdef.cloudfront.net) ou un domaine personnalisé (par exemple, cdn.example.com) à l’aide d’un enregistrement CNAME ou ALIAS.

Après sa création, une distribution nécessite 10 à 15 minutes pour être déployée mondialement dans tous les emplacements périphériques. Les modifications apportées à une distribution existante nécessitent également plusieurs minutes pour se propager. Il existait historiquement deux types de distributions, mais aujourd’hui toutes les distributions utilisent l’interface de configuration unifiée.

Utiliser un compartiment S3 comme origine CloudFront est l’un des modèles les plus courants. CloudFront récupère les objets depuis S3, les met en cache dans les emplacements périphériques, puis sert les requêtes suivantes depuis le cache sans solliciter à nouveau S3. Cela réduit les coûts des requêtes S3, améliore la latence pour les utilisateurs du monde entier et décharge S3 d’une partie de la bande passante.

Pour servir un site reposant sur S3, vous n’avez pas besoin de rendre le compartiment public. Utilisez plutôt Origin Access Control (OAC), le remplacement moderne de Origin Access Identity (OAI). OAC accorde uniquement à la distribution CloudFront l’autorisation de lire le compartiment, ce qui permet de conserver S3 privé tout en diffusant publiquement le contenu via CloudFront.

CloudFront prend également en charge les origines personnalisées : tout serveur HTTP ou HTTPS accessible depuis Internet, notamment les instances EC2, les équilibreurs de charge d’application, les points de terminaison API Gateway et les serveurs sur site. Les origines personnalisées permettent à CloudFront de mettre en cache et d’accélérer les applications dynamiques et les API, et pas seulement les fichiers statiques.

Lorsque vous utilisez un ALB comme origine personnalisée, configurez-le pour qu’il n’accepte dans son groupe de sécurité que les connexions provenant des plages d’adresses IP CloudFront. Tout le trafic externe passe ainsi par CloudFront, ce qui permet d’appliquer les règles WAF et de terminer TLS à la périphérie, tout en conservant l’ALB à l’intérieur d’AWS.

Origin Access Identity (OAI) était la méthode originale pour restreindre l’accès d’un compartiment S3 à CloudFront. Il s’agit d’une identité utilisateur CloudFront spéciale à laquelle une autorisation est accordée dans la stratégie du compartiment S3. Bien que OAI fonctionne toujours, cette solution est considérée comme obsolète.

Origin Access Control (OAC) est son remplacement moderne. OAC prend en charge tous les types de compartiments S3 (notamment S3 dans les Regions AWS Chine et les compartiments chiffrés avec SSE-KMS), utilise des principaux de service IAM pour un contrôle plus précis et signe automatiquement les requêtes adressées à S3 avec SigV4. Pour les nouvelles distributions, utilisez toujours OAC plutôt que OAI.

La Viewer Protocol Policy contrôle la manière dont CloudFront gère les connexions entre les utilisateurs (visiteurs) et l’emplacement périphérique :

• HTTP et HTTPS : autoriser les deux protocoles ; déconseillé pour le contenu sensible
• Rediriger HTTP vers HTTPS : rediriger automatiquement les requêtes HTTP vers HTTPS ; le paramètre le plus courant
• HTTPS uniquement : rejeter entièrement les connexions HTTP ; à utiliser pour imposer strictement TLS

Séparément, la Origin Protocol Policy contrôle la manière dont CloudFront communique avec votre origine : HTTP uniquement, HTTPS uniquement ou correspondance avec le protocole de l’utilisateur. Pour les origines S3 avec OAC, CloudFront utilise toujours HTTPS.

Pour diffuser du contenu depuis cdn.example.com au lieu du domaine CloudFront, vous configurez un nom de domaine alternatif (CNAME) dans la distribution et vous lui associez un certificat SSL/TLS provenant d’AWS Certificate Manager (ACM). Le certificat ACM doit se trouver dans la région us-east-1 (quel que soit l’emplacement depuis lequel votre distribution diffuse le trafic), car CloudFront est un service mondial géré depuis us-east-1.

Créez l’enregistrement Route 53 en tant qu’enregistrement ALIAS pointant vers le nom de domaine de la distribution CloudFront. CloudFront fournit automatiquement votre certificat pour les requêtes SNI correspondantes.

La classe de prix de CloudFront détermine les emplacements périphériques utilisés pour diffuser votre distribution. Les classes de prix supérieures incluent des emplacements périphériques plus coûteux (généralement dans les régions où la bande passante est plus chère) :

• Classe de prix 100 : Amérique du Nord et Europe uniquement (coût le plus faible)
• Classe de prix 200 : Amérique du Nord, Europe, Asie, Moyen-Orient et Afrique
• Toutes les classes de prix : tous les emplacements périphériques dans le monde (meilleures performances, coût le plus élevé)

Utilisez la classe de prix 100 pour les outils internes ou les audiences limitées à l’Amérique du Nord et à l’Europe. Utilisez toutes les classes de prix pour les applications grand public véritablement mondiales.

Les groupes d’origines permettent le basculement entre les origines CloudFront. Vous définissez une origine principale et une origine secondaire dans un groupe. Si l’origine principale renvoie un code d’erreur HTTP spécifique (par exemple 500, 502, 503 ou 504), CloudFront réessaie automatiquement la requête auprès de l’origine secondaire.

Le basculement d’origine est utile pour la reprise après sinistre : conservez un compartiment S3 principal dans us-east-1 et une sauvegarde répliquée dans us-west-2 comme origine secondaire. CloudFront bascule de manière transparente pendant une interruption de S3, sans nécessiter de modification du DNS. Ce modèle complète la réplication interrégionale S3.

CloudFront peut envoyer des journaux d’accès vers un compartiment S3. Ceux-ci enregistrent les détails de chaque requête d’utilisateur : horodatage, emplacement périphérique, code d’état, octets transférés, résultat de cache (succès ou échec), agent utilisateur, etc. Les journaux sont envoyés par lots toutes les quelques minutes.

Utilisez les journaux d’accès pour analyser les tendances du trafic, repérer les contenus très consultés, contrôler les champs liés à la sécurité (IP, référent, agent utilisateur) et mesurer les taux de succès du cache. Le champ x-edge-result-type indique si la requête a produit un Hit, un Miss ou un RefreshHit à la périphérie.

CloudFront dispose de deux niveaux d’infrastructure de mise en cache :

• Emplacements périphériques : des centaines de PoPs répartis dans le monde, proches des utilisateurs finaux ; ils diffusent le contenu mis en cache avec une latence minimale
• Caches périphériques régionaux (RECs) : 13 caches plus grands et à durée de vie plus longue, situés entre les emplacements périphériques et les origines ; ils diffusent les contenus qui ne sont pas suffisamment populaires pour rester dans les petits caches des emplacements périphériques

Lorsqu’une requête n’est pas trouvée dans le cache de l’emplacement périphérique, CloudFront consulte le REC avant de contacter l’origine. Les REC sont transparents : vous ne les configurez pas directement, mais ils améliorent nettement les taux de succès du cache pour les contenus de longue traîne et réduisent la charge de l’origine.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : les distributions CloudFront mettent le contenu en cache dans des emplacements périphériques répartis dans le monde entier, l’OAC conserve les compartiments S3 privés tout en autorisant l’accès de CloudFront, et les origines personnalisées prennent en charge les ALB, API Gateway et tout serveur HTTP. Les certificats ACM pour CloudFront doivent être provisionnés dans us-east-1. Nous allons maintenant étudier les comportements du cache et les paramètres TTL.