Comportements du cache et paramètres TTL

Les comportements du cache sont les règles qui indiquent à CloudFront comment traiter les requêtes correspondant à différents modèles de chemins d’URL. Chaque comportement du cache associe un modèle de chemin (par exemple /images/*, /api/*, *.css) à une origine et à une configuration de mise en cache spécifiques.

Une distribution possède un comportement de cache par défaut (qui correspond à tous les chemins non pris en charge par des comportements plus spécifiques) et jusqu’à 25 comportements supplémentaires fondés sur des chemins. CloudFront évalue les comportements du plus spécifique au moins spécifique, puis utilise le comportement par défaut si aucun autre ne correspond.

Les modèles de chemins prennent en charge les caractères génériques : * correspond à toute combinaison de caractères, y compris les barres obliques, et ? correspond à un seul caractère. Exemples :

• /images/* — toutes les URL commençant par /images/
• *.jpg — toutes les requêtes se terminant par .jpg, où que ce soit dans le chemin
• /api/v2/* — toutes les routes de l’API v2
• /static/??.css — les fichiers CSS statiques comportant exactement deux caractères avant .css

Les comportements sont évalués dans l’ordre indiqué dans la configuration de la distribution. Placez les modèles les plus spécifiques en premier. Le comportement par défaut (*) correspond toujours en dernier.

CloudFront sépare la logique de mise en cache en deux types de stratégies :

• Stratégie de cache : définit ce que CloudFront utilise comme clé de cache : la combinaison d’en-têtes, de chaînes de requête et de cookies qui détermine si un objet mis en cache correspond à une requête. Elle définit également les limites TTL.
• Stratégie de requête vers l’origine : définit les en-têtes, chaînes de requête et cookies transmis à l’origine, même s’ils ne font pas partie de la clé de cache (afin d’envoyer les en-têtes d’authentification à l’origine sans faire varier le cache pour chaque jeton)

AWS fournit des stratégies gérées (par exemple CachingOptimized et CachingDisabled) qui couvrent la plupart des cas d’utilisation, ou vous pouvez créer des stratégies personnalisées.

CloudFront respecte trois valeurs TTL provenant de la stratégie de cache :

• TTL minimal : la durée la plus courte pendant laquelle CloudFront conserve un objet en cache, quels que soient les en-têtes de l’origine (valeur par défaut : 0)
• TTL par défaut : la durée pendant laquelle CloudFront conserve un objet en cache lorsque l’origine n’envoie pas d’en-tête Cache-Control ou Expires (valeur par défaut : 86 400 secondes = 1 jour)
• TTL maximal : la durée la plus longue pendant laquelle CloudFront conserve un objet en cache, en plafonnant la directive Cache-Control max-age de l’origine (valeur par défaut : 31 536 000 = 1 an)

Ces trois valeurs encadrent la durée réelle de mise en cache indiquée par les origines via les en-têtes Cache-Control.

Lorsque votre origine envoie un en-tête Cache-Control: max-age=3600, CloudFront conserve l’objet en cache pendant 3 600 secondes, à condition que cette valeur se situe entre les TTL minimal et maximal de la stratégie de cache. Si l’origine envoie Cache-Control: no-cache ou Cache-Control: no-store, CloudFront vérifie l’origine avant de diffuser la copie mise en cache à chaque requête.

Pour les ressources statiques qui changent rarement, définissez un max-age élevé (par exemple 31536000 = 1 an) et utilisez l’invalidation par versionnement : incluez une empreinte du contenu dans les noms de fichiers (par exemple app.a3f4b5.js) afin que l’URL change lorsque le contenu est modifié, ce qui invalide automatiquement l’ancienne version mise en cache.

Un modèle puissant de comportement du cache sépare les contenus statiques et dynamiques :

• /static/*, *.css, *.js, *.jpg → origine S3, stratégie CachingOptimized (TTL élevé, sans cookies ni chaînes de requête dans la clé de cache)
• /api/* → origine ALB, stratégie CachingDisabled (récupération systématique depuis l’origine, tous les en-têtes et cookies transmis)
• /* (par défaut) → origine ALB, mise en cache modérée

Cela sépare la couche statique fortement mise en cache de la couche d’API dynamique, ce qui maximise les taux de succès du cache pour le contenu statique tout en garantissant que les réponses de l’API sont toujours à jour.

Lorsque vous mettez à jour du contenu dans S3 ou sur votre origine et que vous souhaitez diffuser immédiatement la nouvelle version depuis CloudFront sans attendre l’expiration du TTL, vous créez une invalidation du cache. Indiquez les chemins à invalider (par exemple /images/logo.png ou /images/*) et CloudFront supprime ces objets de tous les caches périphériques.

Les invalidations sont payantes : les 1 000 premiers chemins par mois sont gratuits ; les chemins supplémentaires sont facturés individuellement. Les invalidations avec caractère générique (par exemple /*) comptent comme un seul chemin. Bonne pratique : utilisez des noms de fichiers versionnés pour les ressources statiques (invalidation par versionnement) plutôt que des invalidations fréquentes, afin de réduire les coûts et les délais.

La clé de cache est l’identifiant unique que CloudFront utilise pour rechercher une réponse mise en cache. Par défaut, la clé de cache contient uniquement le chemin d’URL. L’ajout de composants augmente le nombre d’entrées de cache distinctes :

• Chaînes de requête : /search?q=aws et /search?q=s3 sont des entrées de cache distinctes si q fait partie de la clé de cache
• En-têtes : inclure Accept-Encoding permet à CloudFront de mettre en cache séparément les versions gzip et non gzip
• Cookies : inclure des cookies de session crée des entrées de cache propres à chaque utilisateur, ce qui désactive de fait la mise en cache

Réduisez au minimum les composants de la clé de cache pour optimiser l’efficacité du cache. N’incluez que ceux qui produisent réellement des réponses différentes.

CloudFront peut automatiquement compresser les objets textuels (HTML, CSS, JavaScript, JSON) avec gzip ou Brotli avant de les transmettre aux utilisateurs. Cela réduit la taille de la charge utile de 60 à 80 % et améliore les temps de chargement des pages sans aucune modification de votre origine.

Pour activer la compression : vérifiez que la stratégie de cache inclut Accept-Encoding dans la clé de cache (CloudFront doit mettre en cache séparément les versions gzip et non gzip), puis activez Compress Objects Automatically dans le comportement du cache. CloudFront compresse les objets de plus de 1 000 octets et de moins de 10 Mo.

Le taux de succès du cache est le pourcentage de requêtes servies depuis le cache CloudFront sans contacter l’origine. Un taux élevé (80 % ou plus) signifie des coûts d’origine réduits et de meilleures performances. Surveillez-le via le rapport Cache Statistics de la console CloudFront ou avec la métrique CloudWatch CacheHitRate.

Pour améliorer le taux de succès du cache : augmentez les valeurs TTL, réduisez le nombre d’en-têtes et de cookies dans la clé de cache, utilisez la normalisation des chaînes de requête (ne transmettez que les chaînes réellement utilisées par votre application) et définissez les en-têtes Cache-Control appropriés sur l’origine.

Chaque comportement du cache peut pointer vers une origine différente, ce qui permet à une seule distribution CloudFront de diffuser du contenu provenant de plusieurs systèmes principaux. Par exemple :

• /static/* → origine S3 (compartiment privé via OAC)
• /api/* → origine ALB dans us-east-1
• /media/* → origine CDN MediaPackage pour la diffusion vidéo

Chaque comportement configure également de manière indépendante la stratégie de protocole des utilisateurs, les méthodes HTTP autorisées et les associations de fonctions (CloudFront Functions ou Lambda@Edge). Une seule distribution devient ainsi une couche de diffusion flexible et polyvalente.

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 comportements du cache associent les modèles de chemins d’URL aux origines et aux règles de mise en cache, les TTL minimal, par défaut et maximal déterminent la durée de mise en cache du contenu, les en-têtes Cache-Control de l’origine prenant le dessus lorsqu’ils sont présents, et les invalidations du cache suppriment immédiatement le contenu obsolète de tous les emplacements périphériques. Réduisez au minimum les composants de la clé de cache pour maximiser le taux de succès. Nous allons maintenant étudier les URL signées, les cookies signés et la restriction géographique.