Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Mise en cache et disponibilité
Vous pouvez l'utiliser CloudFront pour réduire le nombre de demandes auxquelles votre serveur d'origine doit répondre directement. Grâce à CloudFront la mise en cache, un plus grand nombre d'objets sont servis à partir d'emplacements CloudFront périphériques, plus proches de vos utilisateurs. Cela réduit la charge sur votre serveur d'origine et la latence.
Plus le nombre de demandes CloudFront pouvant être traitées à partir des caches périphériques est élevé, moins il y a de demandes des utilisateurs qui CloudFront doivent être transmises à votre source pour obtenir la dernière version ou une version unique d'un objet. Pour optimiser votre CloudFront système afin d'envoyer le moins de demandes possible à votre origine, pensez à utiliser un CloudFront Origin Shield. Pour de plus amples informations, veuillez consulter [Utiliser Amazon CloudFront Origin Shield](origin-shield.md).
La proportion de demandes traitées directement depuis le CloudFront cache par rapport à l'ensemble des demandes est appelée *taux de réussite du cache*. Vous pouvez consulter le pourcentage de demandes des utilisateurs qui sont des réponses positives, manquées ou erronées dans la CloudFront console. Pour de plus amples informations, veuillez consulter [Afficher les rapports statistiques du CloudFront cache](cache-statistics.md).
Un certain nombre de facteurs influencent le taux d'accès au cache. Vous pouvez ajuster CloudFront la configuration de votre distribution pour améliorer le taux de réussite du cache en suivant les instructions fournies dans[Augmenter la proportion de demandes traitées directement à partir des CloudFront caches (taux de réussite du cache)](cache-hit-ratio.md).
Pour en savoir plus sur l'ajout et la suppression du contenu que vous CloudFront souhaitez diffuser, consultez[Ajouter, supprimer ou remplacer du contenu CloudFront diffusé](AddRemoveReplaceObjects.md).
**Topics**
+ [
# Augmenter la proportion de demandes traitées directement à partir des CloudFront caches (taux de réussite du cache)
](cache-hit-ratio.md)
+ [
# Utiliser Amazon CloudFront Origin Shield
](origin-shield.md)
+ [
# Optimisez la haute disponibilité grâce au basculement CloudFront d'origine
](high_availability_origin_failover.md)
+ [
# Gestion de la durée de conservation de contenu dans le cache (expiration)
](Expiration.md)
+ [
# Mise en cache de contenu basée sur les paramètres de chaîne de requête
](QueryStringParameters.md)
+ [
# Mise en cache de contenu basée sur des cookies
](Cookies.md)
+ [
# Mise en cache de contenu basée sur des en-têtes de demandes
](header-caching.md)
# Augmenter la proportion de demandes traitées directement à partir des CloudFront caches (taux de réussite du cache)
Vous pouvez améliorer les performances en augmentant la proportion de demandes de vos visiteurs qui sont traitées directement depuis le CloudFront cache au lieu d'être transmises à vos serveurs d'origine pour le contenu. Ce processus est appelé « amélioration du taux d'accès au cache ».
Les sections suivantes expliquent comment améliorer votre taux d'accès au cache.
**Topics**
+ [
## Spécifiez la durée de mise CloudFront en cache de vos objets
](#cache-hit-ratio-duration)
+ [
## Utilisation d’Origin Shield
](#cache-hit-ratio-use-origin-shield)
+ [
## Mise en cache basée sur les paramètres de chaîne de requête
](#cache-hit-ratio-query-string-parameters)
+ [
## Mise en cache basée sur des valeurs de cookie
](#cache-hit-ratio-cookies)
+ [
## Mise en cache basée sur des valeurs d'en-tête
](#cache-hit-ratio-request-headers)
+ [
## Supprimer l'en-tête `Accept-Encoding` lorsqu'une compression n'est pas nécessaire
](#cache-hit-ratio-remove-accept-encoding)
+ [
## Diffusion de contenu multimédia via HTTP
](#cache-hit-ratio-http-streaming)
## Spécifiez la durée de mise CloudFront en cache de vos objets
Pour augmenter votre taux d'accès au cache, vous pouvez configurer votre origine de sorte qu'une directive [Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) soit ajoutée à vos objets et spécifier la valeur pratique la plus longue pour `max-age`. Plus la durée du cache est courte, plus il CloudFront envoie fréquemment des demandes à votre origine pour déterminer si un objet a changé et pour obtenir la dernière version. Vous pouvez compléter `max-age` avec les directives `stale-while-revalidate` et `stale-if-error` pour améliorer davantage le taux d'accès au cache sous certaines conditions. Pour de plus amples informations, veuillez consulter [Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md).
## Utilisation d’Origin Shield
CloudFront Origin Shield peut contribuer à améliorer le taux de réussite du cache de votre CloudFront distribution, car il fournit une couche de mise en cache supplémentaire devant votre source d'origine. Lorsque vous utilisez Origin Shield, toutes les demandes de toutes les couches CloudFront de mise en cache envoyées à votre origine proviennent d'un seul endroit. CloudFront peut récupérer chaque objet à l'aide d'une seule demande d'origine provenant d'Origin Shield, et toutes les autres couches du CloudFront cache (emplacements périphériques et [caches périphériques régionaux](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) peuvent récupérer l'objet depuis Origin Shield.
Pour de plus amples informations, veuillez consulter [Utiliser Amazon CloudFront Origin Shield](origin-shield.md).
## Mise en cache basée sur les paramètres de chaîne de requête
Si vous configurez CloudFront la mise en cache en fonction des paramètres de chaîne de requête, vous pouvez améliorer la mise en cache en procédant comme suit :
+ Configurez CloudFront pour transmettre uniquement les paramètres de chaîne de requête pour lesquels votre origine renverra des objets uniques.
+ Utilisez la même casse (majuscules ou minuscules) pour toutes les instances du même paramètre. Par exemple, si une demande contient `parameter1=A` et qu'une autre contient`parameter1=a`, CloudFront transfère des demandes distinctes à votre origine lorsqu'une demande contient `parameter1=A` et lorsqu'une demande contient`parameter1=a`. CloudFront met ensuite en cache séparément les objets correspondants renvoyés par votre origine séparément, même s'ils sont identiques. Si vous utilisez uniquement `A` ou `a`, CloudFront réachemine moins de requêtes vers votre origine.
+ Listez les paramètres dans le même ordre. Comme avec les différences de casse, si une requête pour un objet contient la chaîne de requête `parameter1=a¶meter2=b` et une autre requête contient `parameter2=b¶meter1=a`, CloudFront réachemine les deux requêtes à votre origine et met en cache les objets correspondants séparément même s'ils sont identiques. Si vous utilisez toujours le même ordre pour les paramètres, CloudFront vous transférez moins de demandes à votre source.
Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur les paramètres de chaîne de requête](QueryStringParameters.md). Si vous souhaitez consulter les chaînes de requête qui CloudFront sont transmises à votre origine, consultez les valeurs dans la `cs-uri-query` colonne de vos fichiers CloudFront journaux. Pour de plus amples informations, veuillez consulter [Journaux d'accès (journaux standard)](AccessLogs.md).
## Mise en cache basée sur des valeurs de cookie
Si vous configurez CloudFront la mise en cache en fonction des valeurs des cookies, vous pouvez améliorer la mise en cache en procédant comme suit :
+ Configurez CloudFront pour transférer uniquement les cookies spécifiés au lieu de transférer tous les cookies. Pour les cookies que vous configurez CloudFront pour rediriger vers votre origine, CloudFront transmet chaque combinaison de nom et de valeur du cookie. Il met ensuite en cache séparément les objets renvoyés par votre origine, même s'ils sont tous identiques.
Supposons, par exemple, que les utilisateurs incluent deux cookies dans chaque demande, que chaque cookie possède trois valeurs possibles et que toutes les combinaisons de valeurs de cookies soient possibles. CloudFront transmet jusqu'à neuf demandes différentes à votre origine pour chaque objet. Si votre origine renvoie différentes versions d'un objet en fonction d'un seul des cookies, cela signifie qu' CloudFront il transmet plus de demandes à votre origine que nécessaire et met inutilement en cache plusieurs versions identiques de l'objet.
+ Créez des comportements de cache distincts pour le contenu statique et dynamique, et configurez CloudFront pour transférer les cookies vers votre origine uniquement pour le contenu dynamique.
Supposons, par exemple, que vous n'ayez qu'un seul comportement de cache pour votre distribution et que vous utilisiez la distribution à la fois pour du contenu dynamique, tel que `.js` des fichiers, et pour `.css` des fichiers qui changent rarement. CloudFront met en cache des versions distinctes de vos `.css` fichiers en fonction des valeurs des cookies, de sorte que chaque emplacement CloudFront périphérique transmet une demande à votre origine pour chaque nouvelle valeur de cookie ou combinaison de valeurs de cookie.
Si vous créez un comportement de cache qui suit le modèle de chemin `*.css` et qui CloudFront ne met pas en cache en fonction des valeurs des cookies, CloudFront vous transférez les demandes de `.css` fichiers à votre origine uniquement pour la première demande reçue par un emplacement périphérique pour un `.css` fichier donné et pour la première demande après l'expiration d'un `.css` fichier.
+ Si possible, créez des comportements de cache distincts pour les contenus dynamiques pour lesquels les valeurs de cookie sont uniques pour chaque utilisateur (comme un ID utilisateur) et les contenus dynamiques qui varient selon un plus petit nombre de valeurs uniques.
Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md). Si vous souhaitez consulter les cookies qui sont CloudFront transférés vers votre source, consultez les valeurs dans la `cs(Cookie)` colonne de vos fichiers CloudFront journaux. Pour de plus amples informations, veuillez consulter [Journaux d'accès (journaux standard)](AccessLogs.md).
## Mise en cache basée sur des valeurs d'en-tête
Si vous configurez CloudFront la mise en cache en fonction des en-têtes de demande, vous pouvez améliorer la mise en cache en procédant comme suit :
+ Configurez CloudFront pour transférer et mettre en cache en fonction uniquement des en-têtes spécifiés au lieu du transfert et de la mise en cache en fonction de tous les en-têtes. Pour les en-têtes que vous spécifiez, CloudFront transfère chaque combinaison de nom et de valeur d'en-tête. Il met ensuite en cache séparément les objets que votre origine renvoie, même s'ils sont tous identiques.
**Note**
CloudFront transmet toujours à votre origine les en-têtes spécifiés dans les rubriques suivantes :
Comment CloudFront traite et transmet les demandes à votre serveur d'origine Amazon S3 > [En-têtes de requête HTTP qui CloudFront suppriment ou mettent à jour](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers)
Comment CloudFront traite et transmet les demandes à votre serveur d'origine personnalisé > [En-têtes et CloudFront comportement des requêtes HTTP (personnalisés et origines d'Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)
Lorsque vous configurez la mise CloudFront en cache en fonction des en-têtes de demande, vous ne modifiez pas les en-têtes qui CloudFront sont transférés, mais uniquement si les objets sont mis en CloudFront cache en fonction des valeurs des en-têtes.
+ Essayez d'éviter d'effectuer la mise en cache en fonction d'en-têtes de demande qui ont des nombres importants de valeurs uniques.
Par exemple, si vous souhaitez diffuser différentes tailles d'image en fonction de l'appareil de l'utilisateur, ne configurez CloudFront pas le cache en fonction de l'`User-Agent`en-tête, qui comporte un très grand nombre de valeurs possibles. Configurez plutôt CloudFront pour mettre en cache en fonction des en-têtes CloudFront de type de périphérique`CloudFront-Is-Desktop-Viewer`,`CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer` et. `CloudFront-Is-Tablet-Viewer` De plus, si vous renvoyez la même version de l'image pour des tablettes et des ordinateurs de bureau, transmettez uniquement l'en-tête `CloudFront-Is-Tablet-Viewer`, pas l'en-tête `CloudFront-Is-Desktop-Viewer`.
Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des en-têtes de demandes](header-caching.md).
## Supprimer l'en-tête `Accept-Encoding` lorsqu'une compression n'est pas nécessaire
Si la compression n'est pas activée, parce que l'origine ne la prend pas en charge, CloudFront ne la prend pas en charge ou parce que le contenu n'est pas compressible, vous pouvez augmenter le taux de réussite du cache en associant un comportement de cache dans votre distribution à une origine qui définit les paramètres suivants : Custom Origin Header
+ **Header name (Nom de l'en-tête**: `Accept-Encoding`
+ **Header value (Valeur de l'en-tête)** : (laisser vide)
Lorsque vous utilisez cette configuration, elle CloudFront supprime l'`Accept-Encoding`en-tête de la clé de cache et ne l'inclut pas dans les demandes d'origine. Cette configuration s'applique à tous les contenus fournis CloudFront par la distribution à partir de cette origine.
## Diffusion de contenu multimédia via HTTP
Pour plus d'informations sur l'optimisation du contenu vidéo à la demande (VOD) et en streaming, consultez [Vidéo à la demande et vidéo en direct avec CloudFront](on-demand-streaming-video.md).
# Utiliser Amazon CloudFront Origin Shield
CloudFront Origin Shield est une couche supplémentaire de l'infrastructure de mise en CloudFront cache qui permet de minimiser la charge de votre origine, d'améliorer sa disponibilité et de réduire ses coûts d'exploitation. Avec CloudFront Origin Shield, vous bénéficiez des avantages suivants :
**Un meilleur taux d'accès au cache**
Origin Shield peut contribuer à améliorer le taux de réussite du cache de votre CloudFront distribution, car il fournit une couche de mise en cache supplémentaire devant votre source d'origine. Lorsque vous utilisez Origin Shield, toutes les requêtes envoyées par toutes les couches CloudFront de mise en cache à votre origine passent par Origin Shield, ce qui augmente le risque d'accès au cache. CloudFrontpeut récupérer chaque objet avec une seule demande d'origine envoyée par Origin Shield à votre origine, et toutes les autres couches du CloudFront cache (emplacements périphériques et [caches périphériques régionaux](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) peuvent récupérer l'objet depuis Origin Shield.
**Une charge d'origine réduite**
La couche Origin Shield peut réduire davantage le nombre de [demandes simultanées](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) envoyées à votre origine pour le même objet. Les demandes de contenu ne se trouvant pas dans le cache d'Origin Shield sont consolidées avec d'autres demandes liées au même objet, ce qui permet qu'une seule demande soit envoyée à votre origine. Le fait de traiter moins de demandes à l'origine peut préserver la disponibilité de votre site d'origine en cas de pic de charge ou de pic de trafic imprévu, et peut réduire les coûts liés à des éléments tels que l' just-in-timeemballage, les transformations d'images et le transfert de données sortantes (DTO).
**De meilleures performances réseau**
Lorsque vous activez Origin Shield dans la AWS région où la [latence par rapport à votre origine est la plus faible](#choose-origin-shield-region), vous pouvez obtenir de meilleures performances réseau. Pour les origines situées dans une AWS région, le trafic CloudFront réseau reste sur le CloudFront réseau à haut débit jusqu'à votre point d'origine. Pour les origines extérieures AWS, le trafic CloudFront réseau reste sur le CloudFront réseau jusqu'à Origin Shield, qui dispose d'une connexion à faible latence avec votre point d'origine.
Vous encourez des frais supplémentaires pour l'utilisation d'Origin Shield. Pour en savoir plus, consultez [PricingCloudFront ](https://aws.amazon.com/cloudfront/pricing/) (Tarification).
**Note**
Origin Shield n’est pas compatible avec les demandes gRPC. Si Origin Shield est activé sur une distribution prenant en charge gRPC, les demandes gRPC continueront de fonctionner. Cependant, les demandes seront transmises directement à l’origine gRPC sans passer par Origin Shield. Pour de plus amples informations, veuillez consulter [Utilisation de gRPC avec des distributions CloudFront](distribution-using-grpc.md).
**Topics**
+ [
## Cas d'utilisation pour Origin Shield
](#origin-shield-use-cases)
+ [
## Choisissez la AWS région pour Origin Shield
](#choose-origin-shield-region)
+ [
## Activer Origin Shield
](#enable-origin-shield)
+ [
## Estimation des frais liés à Origin Shield
](#origin-shield-costs)
+ [
## Haute disponibilité d'Origin Shield
](#origin-shield-high-availability)
+ [
## Comment Origin Shield interagit avec les autres fonctionnalités CloudFront
](#origin-shield-and-other-features)
## Cas d'utilisation pour Origin Shield
CloudFront Origin Shield peut être utile dans de nombreux cas d'utilisation, notamment les suivants :
+ Utilisateurs répartis dans différentes régions géographiques
+ Origines qui fournissent des just-in-time emballages pour la diffusion en direct ou le traitement on-the-fly d'images
+ Origines sur site avec des contraintes de capacité ou de bande passante
+ Charges de travail utilisant plusieurs réseaux de diffusion de contenu () CDNs
Il est possible qu'Origin Shield ne soit pas adapté dans certains cas, par exemple pour du contenu dynamique transmis par proxy à l'origine, du contenu avec une mise en cache faible ou du contenu rarement demandé.
Les sections suivantes expliquent les avantages d'Origin Shield pour les cas d'utilisation suivants.
**Topics**
+ [
### Utilisateurs dans des régions géographiques différentes
](#os-use-cases-global-viewers)
+ [
### Multiple CDNs
](#os-use-cases-multi-cdn)
### Utilisateurs dans des régions géographiques différentes
Avec Amazon CloudFront, vous bénéficiez par nature d'une charge réduite sur votre source, car les demandes qui CloudFront peuvent être envoyées depuis le cache ne sont pas transmises à votre origine. Outre le [réseau mondial CloudFront d'emplacements périphériques, les caches périphériques](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) [régionaux](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) servent de couche de mise en cache de niveau intermédiaire pour fournir des accès au cache et consolider les demandes d'origine pour les utilisateurs des régions géographiques voisines. Les demandes des utilisateurs sont d'abord acheminées vers un emplacement périphérique CloudFront voisin et, si l'objet n'est pas mis en cache dans cet emplacement, la demande est envoyée à un cache périphérique régional.
Lorsque les utilisateurs se trouvent dans des régions géographiques différentes, les demandes peuvent être acheminées via différents caches périphériques régionaux, chacun pouvant envoyer une demande à votre origine pour le même contenu. Avec Origin Shield, vous disposez d'une couche supplémentaire de mise en cache entre les caches périphériques régionaux et votre origine. Toutes les demandes provenant de tous les caches périphériques régionaux passent par Origin Shield, réduisant encore la charge sur votre origine. Les diagrammes suivants illustrent ce concept. Dans les diagrammes suivants, l’origine est AWS Elemental MediaPackage.
**Sans Origin Shield**
Sans Origin Shield, votre origine peut recevoir des demandes en double pour le même contenu, comme le montre le diagramme suivant.
![\[Sans CloudFront Origin Shield, l'origine peut recevoir des demandes dupliquées.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png)
**Avec Origin Shield**
L'utilisation d'Origin Shield permet de réduire la charge sur votre origine, comme le montre le diagramme suivant.
![\[Avec CloudFront Origin Shield, l'origine peut recevoir moins de demandes dupliquées.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png)
### Multiple CDNs
Pour diffuser des événements vidéo en direct ou du contenu populaire à la demande, vous pouvez utiliser plusieurs réseaux de diffusion de contenu (CDNs). L'utilisation de plusieurs CDNs peut offrir certains avantages, mais cela signifie également que votre source peut recevoir de nombreuses demandes dupliquées pour le même contenu, chacune provenant d'emplacements différents CDNs ou différents au sein du même CDN. Ces demandes redondantes peuvent nuire à la disponibilité de votre origine ou entraîner des coûts d'exploitation supplémentaires pour des processus tels que le just-in-time conditionnement ou le transfert de données (DTO) vers Internet.
Lorsque vous associez Origin Shield à l'utilisation de votre CloudFront distribution comme origine pour d'autres CDNs, vous pouvez bénéficier des avantages suivants :
+ Diminution du nombre de demandes redondantes reçues à l'origine, ce qui contribue à réduire les effets négatifs liés à l'utilisation de plusieurs CDNs.
+ Une [clé de cache](controlling-the-cache-key.md) commune et une gestion centralisée des fonctionnalités liées à l'origine. CDNs
+ Amélioration des performances réseau Le trafic réseau en provenance d'un autre réseau CDNs est interrompu à un emplacement CloudFront périphérique proche, ce qui peut provoquer un accès depuis le cache local. Si l'objet demandé ne se trouve pas dans le cache de localisation périphérique, la demande envoyée à l'origine reste sur le CloudFront réseau jusqu'à Origin Shield, qui fournit un débit élevé et une faible latence à l'origine. Si l'objet demandé se trouve dans le cache d'Origin Shield, la demande à votre origine est entièrement évitée.
**Important**
Si vous souhaitez utiliser Origin Shield dans une architecture multi-CDN et bénéficier de tarifs réduits, [contactez-nous ou contactez](https://aws.amazon.com/contact-us/) votre représentant AWS commercial pour plus d'informations. Des frais supplémentaires peuvent s'appliquer.
Les diagrammes suivants montrent comment cette configuration peut aider à minimiser la charge sur votre système d'origine lorsque vous diffusez des événements vidéo populaires en direct avec plusieurs CDNs. Dans les diagrammes suivants, l'origine est AWS Elemental MediaPackage.
**Sans Origin Shield (plusieurs CDNs)**
Sans Origin Shield, votre origine peut recevoir de nombreuses demandes en double pour le même contenu, chacune provenant d'un réseau de diffusion de contenu différent, comme indiqué dans le diagramme suivant.
![\[Graphique montrant comment une origine peut recevoir des demandes dupliquées, chacune provenant d’un CDN différent.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png)
**Avec Origin Shield (multiple CDNs)**
L'utilisation d'Origin Shield, CloudFront comme origine pour votre autre CDNs, peut vous aider à réduire la charge qui pèse sur votre origine, comme le montre le schéma suivant.
![\[Graphique montrant qu' CloudFront Origin Shield reçoit moins de demandes dupliquées.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png)
## Choisissez la AWS région pour Origin Shield
Amazon CloudFront propose Origin Shield dans AWS les régions CloudFront disposant d'un [cache périphérique régional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Lorsque vous activez Origin Shield, vous choisissez la AWS région pour Origin Shield. Vous devez choisir la région AWS dont la latence vers votre origine est la plus faible. Vous pouvez utiliser Origin Shield avec des origines situées dans une AWS région ou non AWS.
### Pour les personnes originaires d'une AWS région
Si votre origine se trouve dans une AWS région, déterminez d'abord si votre origine se trouve dans une région dans laquelle Origin CloudFront Shield est proposé. CloudFront propose Origin Shield dans les AWS régions suivantes.
+ US East (Ohio) – `us-east-2`
+ USA Est (Virginie du Nord) – `us-east-1`
+ USA Ouest (Oregon) – `us-west-2`
+ Asie-Pacifique (Mumbai) – `ap-south-1`
+ Asie-Pacifique (Séoul) – `ap-northeast-2`
+ Asie-Pacifique (Singapour) – `ap-southeast-1`
+ Asie-Pacifique (Sydney) – `ap-southeast-2`
+ Asie-Pacifique (Tokyo) : `ap-northeast-1`
+ Europe (Francfort) – `eu-central-1`
+ Europe (Irlande) – `eu-west-1`
+ Europe (Londres) – `eu-west-2`
+ South America (São Paulo) – `sa-east-1`
+ Moyen-Orient (Émirats arabes unis) — `me-central-1`
**Si votre origine se trouve dans une AWS région CloudFront proposant Origin Shield**
Si votre origine se trouve dans une AWS région qui CloudFront propose Origin Shield (voir la liste précédente), activez Origin Shield dans la même région que votre origine.
**Si votre origine ne se trouve pas dans une AWS région CloudFront proposant Origin Shield**
Si votre origine ne se trouve pas dans une AWS région CloudFront proposant Origin Shield, consultez le tableau suivant pour déterminer dans quelle région activer Origin Shield.
| **Si votre origine est dans...** | **Activer Origin Shield dans ...** |
| --- | --- |
| US West (N. California) – `us-west-1` | US West (Oregon) – `us-west-2` |
| Africa (Cape Town) – `af-south-1` | Europe (Ireland) – `eu-west-1` |
| Asia Pacific (Hong Kong) – `ap-east-1` | Asia Pacific (Singapore) – `ap-southeast-1` |
| Canada (Central) – `ca-central-1` | US East (N. Virginia) – `us-east-1` |
| Europe (Milan) – `eu-south-1` | Europe (Frankfurt) – `eu-central-1` |
| Europe (Paris) – `eu-west-3` | Europe (London) – `eu-west-2` |
| Europe (Stockholm) – `eu-north-1` | Europe (London) – `eu-west-2` |
| Middle East (Bahrain) – `me-south-1` | Asia Pacific (Mumbai) – `ap-south-1` |
### Pour les origines situées en dehors de AWS
Vous pouvez utiliser Origin Shield avec une origine sur site ou ne se trouvant pas dans une région AWS . Dans ce cas, activez Origin Shield dans la AWS région où la latence par rapport à votre origine est la plus faible. Si vous ne savez pas quelle AWS région présente la latence la plus faible par rapport à votre point d'origine, vous pouvez utiliser les suggestions suivantes pour vous aider à prendre une décision.
+ Vous pouvez consulter le tableau précédent pour avoir une idée de la région AWS pouvant présenter la latence la plus faible vers votre origine, en fonction de l'emplacement géographique de votre origine.
+ Vous pouvez lancer des instances Amazon EC2 dans différentes AWS régions géographiquement proches de votre origine et effectuer des tests `ping` pour mesurer les latences réseau typiques entre ces régions et votre origine.
## Activer Origin Shield
Vous pouvez activer Origin Shield pour améliorer votre taux d'accès au cache, réduire la charge sur votre origine et améliorer les performances. Pour activer Origin Shield, modifiez les paramètres d'origine dans une CloudFront distribution. Origin Shield est une propriété de l'origine. Pour chaque origine de vos CloudFront distributions, vous pouvez activer Origin Shield séparément dans AWS la région offrant les meilleures performances pour cette origine.
Vous pouvez activer Origin Shield dans la CloudFront console CloudFormation, avec ou avec l' CloudFrontAPI.
------
#### [ Console ]
**Pour activer Origin Shield pour une origine existante (console)**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choisissez la distribution contenant l'origine à mettre à jour.
1. Choisissez l’onglet **Origines**.
1. Choisissez l'origine à mettre à jour, puis choisissez **Edit (Modifier)**.
1. Pour **Enable Origin Shield (Activer Origin Shield)**, choisissez **Yes (Oui)**.
1. Pour **Origin Shield Region (Région pour Origin Shield)**, choisissez la région AWS dans laquelle vous souhaitez activer Origin Shield. Pour obtenir de l’aide sur le choix d’une région, consultez [Choisissez la AWS région pour Origin Shield](#choose-origin-shield-region).
1. Sélectionnez **Enregistrer les modifications**.
Lorsque le statut de votre distribution est **Déployée**, Origin Shield est prêt. Cela prend quelques minutes.
**Pour activer Origin Shield pour une nouvelle origine (console)**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Pour créer la nouvelle origine dans une distribution existante, procédez comme suit :
1. Choisissez la distribution dans laquelle vous souhaitez créer l'origine.
1. Choisissez **Créer une origine**, puis passez à l'étape 3.
Pour créer la nouvelle origine dans une nouvelle distribution standard, procédez comme suit :
1. Suivez ces étapes pour créer une distribution standard dans la console. Pour de plus amples informations, veuillez consulter [Création d'une CloudFront distribution dans la console](distribution-web-creating-console.md#create-console-distribution).
1. Dans la section **Paramètres**, sélectionnez **Personnaliser les paramètres d’origine**. Passez à l'étape 3.
1. Pour **Activer Origin Shield**, choisissez **Oui**.
1. Pour **Origin Shield Region (Région pour Origin Shield)**, choisissez la région AWS dans laquelle vous souhaitez activer Origin Shield. Pour obtenir de l’aide sur le choix d’une région, consultez [Choisissez la AWS région pour Origin Shield](#choose-origin-shield-region).
1. Suivez les étapes de la console pour terminer la création de votre origine ou de votre distribution.
Lorsque le statut de votre distribution est **Déployée**, Origin Shield est prêt. Cela prend quelques minutes.
------
#### [ CloudFormation ]
Pour activer Origin Shield avec CloudFormation, utilisez la `OriginShield` propriété dans le type de `Origin` propriété d'une `AWS::CloudFront::Distribution` ressource. Vous pouvez ajouter la propriété `OriginShield` à un type de propriété `Origin` existant, ou l'inclure lorsque vous créez un nouveau type de propriété `Origin`.
L'exemple suivant présente la syntaxe, au format YAML, pour l'activation d'`OriginShield` dans la région USA Ouest (Oregon) (`us-west-2`). Pour obtenir de l’aide sur le choix d’une région, consultez [Choisissez la AWS région pour Origin Shield](#choose-origin-shield-region). Cet exemple montre uniquement le type de propriété `Origin`, et non l'ensemble de la ressource `AWS::CloudFront::Distribution`.
```
Origins:
- DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com
Id: Example-EMP-3ae97e9482b0d011
OriginShield:
Enabled: true
OriginShieldRegion: us-west-2
CustomOriginConfig:
OriginProtocolPolicy: match-viewer
OriginSSLProtocols: TLSv1
```
Pour plus d'informations, consultez [AWS::CloudFront::Distribution Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) dans la section de référence des ressources et des propriétés du *guide de AWS CloudFormation l'utilisateur*.
------
#### [ API ]
Pour activer Origin Shield avec l' CloudFront API à l'aide du AWS SDKs ou AWS Command Line Interface (AWS CLI), utilisez le `OriginShield` type. Vous spécifiez `OriginShield` dans un type `Origin`, dans un type`DistributionConfig`. Pour plus d'informations sur le `OriginShield` type, consultez les informations suivantes dans le *Amazon CloudFront API Reference*.
+ [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html)(type)
+ [Origin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html) (type)
+ [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)(type)
+ [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)(opération)
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)(opération)
La syntaxe spécifique pour l'utilisation de ces types et opérations varie en fonction du client SDK, CLI ou de l'API. Pour plus d’informations, consultez la documentation de référence de votre kit SDK, CLI ou client.
------
## Estimation des frais liés à Origin Shield
Les frais liés à Origin Shield augmentent en fonction du nombre de demandes adressées à Origin Shield en tant que couche incrémentielle.
Pour les demandes dynamiques (ne pouvant pas être mises en cache) qui sont transmises par proxy à l'origine, Origin Shield est toujours une couche incrémentielle. Les demandes dynamiques utilisent les méthodes HTTP `PUT`, `POST`, `PATCH` et `DELETE`.
Les demandes `GET` et `HEAD` dont la durée de vie est inférieure à 3 600 secondes sont considérées comme des demandes dynamiques. En outre, les demandes `GET` et `HEAD` dont la mise en cache est désactivée sont également considérées comme des demandes dynamiques.
Pour estimer vos frais liés à Origin Shield pour les demandes dynamiques, utilisez la formule suivante :
Nombre total de demandes dynamiques **x** frais Origin Shield pour 10 000 demandes **/** 10 000
Pour les demandes non dynamiques utilisant les méthodes HTTP `GET`, `HEAD` et `OPTIONS`, Origin Shield constitue parfois une couche supplémentaire. Lorsque vous activez Origin Shield, vous choisissez Origin Shield. Région AWS Pour les demandes qui vont naturellement vers le [cache périphérique régional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) dans la même région qu’Origin Shield, Origin Shield n’est pas une couche incrémentielle. Vous n’avez pas de frais Origin Shield supplémentaires pour ces demandes. Pour les demandes qui vont vers un cache périphérique régional dans une autre région que celle d’Origin Shield, puis vers Origin Shield, Origin Shield est une couche incrémentielle. Des frais Origin Shield supplémentaires seront facturés pour ces demandes.
Pour estimer vos frais liés à Origin Shield pour les demandes pouvant être mises en cache, utilisez la formule suivante :
Nombre total de demandes pouvant être mises en cache **x** (1 – taux d'accès au cache) **x** pourcentage de demandes allant à Origin Shield à partir d'un cache périphérique régional dans une autre région **x** frais Origin Shield pour 10 000 demandes **/** 10 000
Pour de plus amples informations sur les frais liés à 10 000 demandes pour Origin Shield, veuillez consulter [Tarification CloudFront ](https://aws.amazon.com/cloudfront/pricing/).
## Haute disponibilité d'Origin Shield
Origin Shield tire parti de la fonctionnalité de [caches périphériques CloudFront régionaux](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Chacun de ces caches périphériques est créé dans une AWS région utilisant au moins trois [zones de disponibilité](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) avec des flottes d'instances Amazon EC2 auto-scalables. Les connexions à Origin Shield à partir d'emplacements CloudFront utilisent également le suivi actif d'erreurs pour chaque demande, afin d'acheminer automatiquement la demande vers un emplacement Origin Shield secondaire si l'emplacement Origin Shield principal n'est pas disponible.
## Comment Origin Shield interagit avec les autres fonctionnalités CloudFront
Les sections suivantes expliquent comment Origin Shield interagit avec d'autres fonctions CloudFront.
### Origin Shield et CloudFront journalisation
Pour connaître le moment où Origin Shield a traité une demande, vous devez activer l'une des options suivantes :
+ [CloudFront journaux standard (journaux d'accès)](AccessLogs.md). Les journaux standard sont fournis gratuitement.
+ [CloudFront journaux d'accès en temps réel](real-time-logs.md). L'utilisation des journaux d'accès en temps réel entraîne des frais supplémentaires. Consultez les [ CloudFronttarifs d'Amazon](https://aws.amazon.com/cloudfront/pricing/).
Les accès au cache provenant d'Origin Shield apparaissent comme `OriginShieldHit` `x-edge-detailed-result-type` sur le terrain dans CloudFront les journaux. Origin Shield exploite les CloudFront [caches périphériques régionaux](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) d'Amazon. Si une demande est acheminée depuis un emplacement CloudFront périphérique vers le cache périphérique régional qui agit en tant qu'Origin Shield, elle est signalée comme un `Hit` dans les journaux, et non comme un`OriginShieldHit`.
### Origin Shield et groupes d'origines
Origin Shield est compatible avec les [groupes d'origines CloudFront ](high_availability_origin_failover.md). Origin Shield étant une propriété de l'origine, les demandes passent toujours par Origin Shield pour chaque origine, même lorsque l'origine fait partie d'un groupe d'origines. Pour une demande donnée, CloudFront achemine la demande vers l'origine principale du groupe d'origine via le Origin Shield de l'origine principale. Si cette demande échoue (selon les critères de basculement du groupe d'origine), CloudFront achemine la demande vers l'origine secondaire via le Origin Shield de l'origine secondaire.
### Origin Shield et Lambda@Edge
Origin Shield n'a pas d'impact sur l'exécution des fonctions de [Lambda@Edge](lambda-at-the-edge.md), mais peut affecter la région AWS dans laquelle ces fonctions s'exécutent.
Lorsque vous utilisez Origin Shield avec Lambda @Edge, les [déclencheurs orientés vers](lambda-cloudfront-trigger-events.md) l'origine (demande d'origine et réponse d'origine) s'exécutent dans la région AWS où Origin Shield est activé. Si l'emplacement Origin Shield principal n'est pas disponible et CloudFront achemine les demandes vers un emplacement Origin Shield secondaire, les déclencheurs Lambda @Edge orientés vers l'origine seront également déplacés pour utiliser l'emplacement secondaire d'Origin Shield.
Les déclencheurs liés à l'utilisateur ne sont pas affectés.
# Optimisez la haute disponibilité grâce au basculement CloudFront d'origine
Vous pouvez configurer le basculement CloudFront d'origine pour les scénarios nécessitant une haute disponibilité. Pour commencer, vous créez un *groupe d'origine* avec deux origines : une principale et une secondaire. Si l'origine principale n'est pas disponible ou renvoie des codes d'état de réponse HTTP spécifiques indiquant un échec, passe CloudFront automatiquement à l'origine secondaire.
Pour configurer le basculement d'origine, vous devez avoir une distribution avec au moins deux origines. Ensuite, vous créez un groupe d'origine pour votre distribution incluant deux origines, en en définissant une comme la principale. Enfin, vous créez ou mettez à jour un comportement de cache pour utiliser le groupe d'origine.
Pour voir les étapes de configuration des groupes d’origine et des options de basculement pour une origine spécifique, consultez [Création d’un groupe d’origine](#concept_origin_groups.creating).
Après avoir configuré le basculement d'origine pour un comportement de cache, CloudFront procédez comme suit pour les demandes des utilisateurs :
+ En cas d'accès au cache, CloudFront renvoie l'objet demandé.
+ En cas de perte de cache, CloudFront achemine la demande vers l'origine principale du groupe d'origine.
+ Lorsque l'origine principale renvoie un code d'état qui n'est pas configuré pour le basculement, tel qu'un code d'état HTTP 2xx ou 3xx, envoie l'objet CloudFront demandé au visualiseur.
+ Lorsque l'une des situations suivantes se produit :
+ L'origine principale renvoie un code d'état HTTP que vous avez configuré pour le basculement
+ CloudFront ne parvient pas à se connecter à l'origine principale (lorsque 503 est défini comme code de basculement)
+ La réponse de l’origine principale dépasse le délai d’attente (délai dépassé) (lorsque le code 504 est défini comme code de basculement)
CloudFront Route ensuite la demande vers l'origine secondaire du groupe d'origine.
**Note**
Dans certains cas d'utilisation, tels que le streaming de contenu vidéo, vous CloudFront souhaiterez peut-être passer rapidement à l'origine secondaire. Pour régler la rapidité CloudFront du basculement vers l'origine secondaire, voir[Contrôle des délais d’expiration et des tentatives de l’origine](#controlling-attempts-and-timeouts).
CloudFront achemine toutes les demandes entrantes vers l'origine principale, même lorsqu'une demande précédente a échoué vers l'origine secondaire. CloudFront envoie des demandes à l'origine secondaire uniquement après l'échec d'une demande à l'origine principale.
CloudFront bascule vers l'origine secondaire uniquement lorsque la méthode HTTP de la demande du spectateur est `GET``HEAD`, ou`OPTIONS`. CloudFront ne bascule pas lorsque le visualiseur envoie une autre méthode HTTP (par exemple `POST``PUT`,, etc.).
**Note**
CloudFront ne basculeront pas s'`OPTIONS`ils ne sont pas définis comme un comportement [Méthodes HTTP mises en cache](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods) dans votre cache.
Le graphique suivant illustre le fonctionnement du basculement d'origine
![\[Comment fonctionne le basculement d'origine\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png)
**Topics**
+ [
## Création d’un groupe d’origine
](#concept_origin_groups.creating)
+ [
## Contrôle des délais d’expiration et des tentatives de l’origine
](#controlling-attempts-and-timeouts)
+ [
## Utilisation du basculement d'origine avec les fonctions Lambda@Edge
](#concept_origin_groups.lambda)
+ [
## Utilisation des pages d'erreur personnalisées avec le basculement d'origine
](#concept_origin_groups.custom-error)
## Création d’un groupe d’origine
**Pour créer un groupe d'origine**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choisissez la distribution pour laquelle vous souhaitez créer le groupe d'origine.
1. Choisissez l’onglet **Origines**.
1. Assurez-vous qu’il existe plusieurs origines pour la distribution. Si ce n'est pas le cas, ajoutez une deuxième origine.
1. Sous l'onglet **Origins (Origines)** du volet **Origin groups (Groupes d'origines)**, choisissez **Create origin group (Créer un groupe d'origines)**.
1. Choisissez les origines du groupe d'origine. Après avoir ajouté des origines, utilisez les flèches pour définir la priorité, c'est-à-dire l'origine principale et l'origine secondaire.
1. Saisissez un nom pour le groupe d’origines.
1. Choisissez les codes d'état HTTP à utiliser comme critères de basculement. Vous pouvez choisir n'importe quelle combinaison des codes d'état suivants : 400, 403, 404, 416, 429, 500, 502, 503 ou 504. Lorsqu'il CloudFront reçoit une réponse avec l'un des codes d'état que vous spécifiez, il bascule vers l'origine secondaire.
**Note**
CloudFront bascule vers l'origine secondaire uniquement lorsque la méthode HTTP de la demande du spectateur est `GET``HEAD`, ou`OPTIONS`. CloudFront ne bascule pas lorsque le visualiseur envoie une autre méthode HTTP (par exemple `POST``PUT`,, etc.).
1. Dans **Critères de sélection des origines**, indiquez comment vos origines sont sélectionnées lorsque votre distribution achemine les demandes des utilisateurs. Vous pouvez choisir les options suivantes.
**Par défaut**
CloudFront utilisera la priorité d'origine par défaut que vous spécifiez sur la page **Paramètres**.
**Score de qualité des médias**
CloudFront suit et utilise ce score pour déterminer la première origine à laquelle transmettre la demande. Cela autorise également CloudFront à faire des `HEAD` demandes asynchrones à l'origine alternative dans le groupe d'origine afin de déterminer son score de qualité multimédia. Vous ne pouvez choisir cette option que pour les origines de la AWS Elemental MediaPackage version 2. Pour de plus amples informations, veuillez consulter [Résilience tenant compte de la qualité média](media-quality-score.md).
1. Choisissez **Create origin group (Créer un groupe d'origines)**.
Assurez-vous de définir votre groupe d’origines comme origine pour le comportement de cache de votre distribution. Pour de plus amples informations, veuillez consulter [Nom](DownloadDistValuesOrigin.md#DownloadDistValuesId).
## Contrôle des délais d’expiration et des tentatives de l’origine
Par défaut, CloudFront essaie de se connecter à l'origine principale dans un groupe d'origine pendant 30 secondes maximum (3 tentatives de connexion de 10 secondes chacune) avant de basculer vers l'origine secondaire. Dans certains cas d'utilisation, tels que le streaming de contenu vidéo, vous CloudFront souhaiterez peut-être passer plus rapidement à l'origine secondaire. Vous pouvez ajuster les paramètres suivants pour déterminer la rapidité avec laquelle vous CloudFront basculez vers l'origine secondaire. Si l'origine est une origine secondaire ou une origine ne faisant pas partie d'un groupe d'origine, ces paramètres affectent la rapidité CloudFront avec laquelle une réponse HTTP 504 est renvoyée au lecteur.
Pour basculer plus rapidement, spécifiez un délai d'expiration de connexion plus court, moins de tentatives de connexion, ou les deux. Pour les origines personnalisées (y compris les origines de compartiment Amazon S3 qui *sont* configurées avec un hébergement de site web statique), vous pouvez également ajuster le délai d'expiration de la réponse d'origine.
**Délai d'expiration de la connexion d'origine**
Le paramètre de délai d'expiration de la connexion d'origine influe sur le temps d' CloudFront attente lors de la tentative d'établissement d'une connexion avec l'origine. Par défaut, CloudFront attend 10 secondes pour établir une connexion, mais vous pouvez spécifier 1 à 10 secondes (inclus). Pour de plus amples informations, veuillez consulter [Délai de connexion](DownloadDistValuesOrigin.md#origin-connection-timeout).
**Tentatives de connexion de l'origine**
Le paramètre Tentatives de connexion d'origine affecte le nombre de CloudFront tentatives de connexion à l'origine. Par défaut, CloudFront essaie 3 fois de se connecter, mais vous pouvez spécifier 1 à 3 (inclus). Pour de plus amples informations, veuillez consulter [Tentatives de connexion](DownloadDistValuesOrigin.md#origin-connection-attempts).
Pour une origine personnalisée (y compris un compartiment Amazon S3 configuré avec un hébergement de site Web statique), ce paramètre affecte également le nombre de CloudFront tentatives d'obtention d'une réponse de la part de l'origine en cas d'expiration du délai de réponse d'origine.
**Délai de réponse de l’origine**
Le délai de réponse d'origine, également appelé délai de lecture d'origine, affecte le temps d'attente pour recevoir une réponse (ou pour recevoir la réponse complète) de la part de l'origine. CloudFront Par défaut, CloudFront attend 30 secondes, mais vous pouvez spécifier 1 à 120 secondes (incluses). Pour de plus amples informations, veuillez consulter [Délai de réponse](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### Comment modifier ces paramètres
**Pour modifier ces paramètres dans la [console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home)**
+ Pour une nouvelle origine ou une nouvelle distribution, vous spécifiez ces valeurs lorsque vous créez la ressource.
+ Pour une origine existante dans une distribution existante, vous spécifiez ces valeurs lorsque vous modifiez l'origine.
Pour plus d’informations, consultez [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).
## Utilisation du basculement d'origine avec les fonctions Lambda@Edge
Vous pouvez utiliser les fonctions Lambda @Edge avec des CloudFront distributions que vous avez configurées avec des groupes d'origine. Pour utiliser une fonction Lambda, spécifiez-la dans [une demande d'origine ou un déclencheur de réponse de l'origine](lambda-cloudfront-trigger-events.md) pour un groupe d'origine lorsque vous créez le comportement de cache. Lorsque vous utilisez une fonction Lambda@Edge avec un groupe d'origine, la fonction peut être déclenchée deux fois pour une seule demande d'utilisateur. Par exemple, envisagez le scénario suivant :
1. Vous créez une fonction Lambda@Edge avec un déclencheur de demande d'origine.
1. La fonction Lambda est déclenchée une fois lors de l' CloudFront envoi d'une demande à l'origine principale (en cas d'échec du cache).
1. L'origine principale répond avec un code d'état HTTP configuré pour le basculement.
1. La fonction Lambda est à nouveau déclenchée lorsqu'elle CloudFront envoie la même demande à l'origine secondaire.
Le schéma suivant illustre la façon dont le basculement d'origine fonctionne lorsque vous incluez une fonction Lambda@Edge dans une requête d'origine ou un déclencheur de réponse.
![\[Comment fonctionne le basculement d'origine avec les fonctions Lambda@Edge\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png)
Pour plus d'informations sur l'utilisation des déclencheurs Lambda@Edge, consultez [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md).
Pour plus d’informations sur la gestion du basculement DNS, consultez [Configuration du basculement DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) dans le *Guide du développeur Amazon Route 53*.
## Utilisation des pages d'erreur personnalisées avec le basculement d'origine
Vous pouvez utiliser des pages d'erreur personnalisées avec des groupes d'origine de la même façon dont vous les utiliseriez avec des origines qui ne sont pas configurées pour le basculement d'origine.
Lorsque vous utilisez le basculement d'origine, vous pouvez configurer CloudFront pour renvoyer une page d'erreur personnalisée pour l'origine principale ou secondaire (ou les deux) :
+ **Renvoyer une page d'erreur personnalisée pour l'origine principale** : si l'origine principale renvoie un code d'état HTTP qui n'est pas configuré pour le basculement, CloudFront renvoie la page d'erreur personnalisée aux lecteurs.
+ **Renvoie une page d'erreur personnalisée pour l'origine secondaire** : si CloudFront l'origine secondaire envoie un code d'état de défaillance, CloudFront renvoie la page d'erreur personnalisée.
Pour plus d'informations sur l'utilisation de pages d'erreur personnalisées avec CloudFront, consultez[Génération de réponses aux·erreurs personnalisées](GeneratingCustomErrorResponses.md).
# Gestion de la durée de conservation de contenu dans le cache (expiration)
Vous pouvez contrôler la durée pendant laquelle vos fichiers restent dans le CloudFront cache avant de CloudFront transmettre une autre demande à votre source. Réduire la durée vous permet de servir des contenus dynamiques. Augmenter la durée signifie que vos utilisateurs obtiennent de meilleures performances parce que vos fichiers sont plus susceptibles d'être servis directement à partir du cache périphérique. Une durée plus longue réduit également la charge sur votre origine.
Généralement, CloudFront diffuse un fichier à partir d'un emplacement périphérique jusqu'à ce que la durée de cache que vous avez spécifiée soit atteinte, c'est-à-dire jusqu'à ce que le fichier expire. Après son expiration, la prochaine fois que l'emplacement périphérique reçoit une demande pour le fichier, CloudFront transmet la demande à l'origine pour vérifier que le cache contient la dernière version du fichier. La réponse de l'origine varie selon que le fichier a changé ou non :
+ Si le CloudFront cache possède déjà la dernière version, l'origine renvoie un code d'état`304 Not Modified`.
+ Si le CloudFront cache ne possède pas la dernière version, l'origine renvoie un code d'état `200 OK` et la dernière version du fichier.
Si un fichier situé dans un emplacement périphérique n'est pas fréquemment demandé, CloudFront vous pouvez l'expulser (supprimer le fichier avant sa date d'expiration) pour faire de la place aux fichiers demandés plus récemment.
Nous vous recommandons de gérer la durée de votre cache en mettant à jour la politique de cache de votre distribution. Si vous choisissez de ne pas utiliser de politique de cache, la durée de vie par défaut est de 24 heures, mais vous pouvez mettre à jour les paramètres suivants pour remplacer cette valeur par défaut :
+ Pour modifier la durée du cache pour tous les fichiers qui correspondent au même schéma de chemin, vous pouvez modifier les CloudFront paramètres TTL **minimum, TTL** **maximum et TTL** **par défaut pour un comportement** de cache. Pour en savoir plus sur les paramètres individuels, consultez [Durée de vie minimale](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL), [Durée de vie (TTL) maximale](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) et [TTL par défaut](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL).
+ Pour changer la durée de conservation en cache pour un fichier individuel, vous pouvez configurer votre origine de sorte à ajouter un en-tête `Cache-Control` avec la directive `max-age` ou `s-maxage`, ou un en-tête `Expires` au fichier. Pour de plus amples informations, veuillez consulter [Utilisation des en-têtes pour contrôler la durée de conservation en cache pour des objets individuels](#expiration-individual-objects).
Pour plus d’informations sur la manière dont la **durée de vie minimale**, la **durée de vie par défaut** et la **durée de vie maximale** interagissent avec les directives `max-age` et `s-maxage`, ainsi que le champ d’en-tête `Expires`, consultez [Spécifiez la durée de mise en CloudFront cache des objets](#ExpirationDownloadDist).
Vous pouvez également contrôler la durée pendant laquelle les erreurs (par exemple`404 Not Found`) restent dans un CloudFront cache avant de CloudFront réessayer d'obtenir l'objet demandé en transférant une autre demande à votre origine. Pour de plus amples informations, veuillez consulter [Comment CloudFront traite les codes d'état HTTP 4xx et 5xx de votre origine](HTTPStatusCodes.md).
**Topics**
+ [
## Utilisation des en-têtes pour contrôler la durée de conservation en cache pour des objets individuels
](#expiration-individual-objects)
+ [
## Diffusion de contenu obsolète (expiré)
](#stale-content)
+ [
## Spécifiez la durée de mise en CloudFront cache des objets
](#ExpirationDownloadDist)
+ [
## Ajout d’en-têtes à vos objets à l’aide de la console Amazon S3
](#ExpirationAddingHeadersInS3)
## Utilisation des en-têtes pour contrôler la durée de conservation en cache pour des objets individuels
Vous pouvez utiliser les en-têtes `Cache-Control` et `Expires` pour contrôler pendant combien de temps des objets restent dans le cache. Les valeurs de **Durée de vie minimale**, **Durée de vie par défaut** et **Durée de vie maximale ** affectent également la durée de conservation en cache, mais voici un aperçu de l'incidence de ces en-têtes sur cette durée :
+ La `Cache-Control max-age` directive vous permet de spécifier la durée (en secondes) pendant laquelle vous souhaitez qu'un objet reste dans le cache CloudFront avant de le récupérer depuis le serveur d'origine. Le délai d'expiration minimum pris CloudFront en charge est de 0 seconde. La valeur maximale est 100 ans. Spécifiez la valeur au format suivant :
`Cache-Control: max-age=`*seconds*
Par exemple, la directive suivante indique CloudFront de conserver l'objet associé dans le cache pendant 3 600 secondes (une heure) :
`Cache-Control: max-age=3600`
Si vous souhaitez que les objets restent dans les caches CloudFront périphériques pendant une durée différente de celle dans les caches du navigateur, vous pouvez utiliser les `Cache-Control s-maxage` directives `Cache-Control max-age` et conjointement. Pour de plus amples informations, veuillez consulter [Spécifiez la durée de mise en CloudFront cache des objets](#ExpirationDownloadDist).
+ Le champ d'en-tête `Expires` vous permet de spécifier une date et une heure d'expiration au format spécifié dans [RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 Section 3.3.1, Full Date](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1), par exemple :
`Sat, 27 Jun 2015 23:59:59 GMT`
Nous vous recommandons d'utiliser la directive `Cache-Control max-age` plutôt que le champ d'en-tête `Expires` pour contrôler la mise en cache des objets. Si vous spécifiez des valeurs pour `Cache-Control max-age` et pour `Expires`, CloudFront utilise uniquement la valeur de `Cache-Control max-age`.
Pour de plus amples informations, veuillez consulter [Spécifiez la durée de mise en CloudFront cache des objets](#ExpirationDownloadDist).
Vous ne pouvez pas utiliser les champs HTTP `Cache-Control` ou d'`Pragma`en-tête dans une `GET` demande d'un visualiseur CloudFront pour forcer le retour de l'objet sur le serveur d'origine. CloudFront ignore ces champs d'en-tête dans les demandes des utilisateurs.
Pour plus d'informations sur les champs d'en-tête `Cache-Control` et `Expires`, consultez les sections suivantes de *RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1*:
+ [Section 14.9 Cache Control](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
+ [Section 14.21 Expires](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)
## Diffusion de contenu obsolète (expiré)
CloudFront prend en charge `Stale-While-Revalidate` les directives de contrôle du `Stale-If-Error` cache et. Vous pouvez utiliser ces directives pour définir la durée pendant laquelle le contenu obsolète reste accessible aux utilisateurs.
**Topics**
+ [
### `Stale-While-Revalidate`
](#stale-while-revalidate)
+ [
### `Stale-If-Error`
](#stale-if-error-only)
+ [
### Utilisation des deux directives
](#use-both-stale-directives)
### `Stale-While-Revalidate`
Cette directive permet CloudFront de diffuser du contenu périmé depuis le cache tout en récupérant de CloudFront manière asynchrone une nouvelle version depuis l'origine. Cela permet d’améliorer la latence, car les utilisateurs reçoivent immédiatement les réponses depuis les emplacements périphériques sans devoir attendre la récupération en arrière-plan. Le nouveau contenu est chargé en arrière-plan pour les prochaines demandes.
**Example Exemple : `Stale-While-Revalidate`**
CloudFront effectue les opérations suivantes lorsque vous configurez l'`Cache-Control`en-tête pour qu'il utilise ces directives.
```
Cache-Control: max-age=3600, stale-while-revalidate=600
```
1. CloudFront mettra en cache une réponse pendant une heure (`max-age=3600`).
1. Si une demande est faite après cette durée, CloudFront diffuse le contenu périmé, tout en envoyant simultanément une demande à l'origine pour revalider et actualiser le contenu mis en cache.
1. Pendant la revalidation du contenu, CloudFront diffuse le contenu périmé pendant 10 minutes maximum ()`stale-while-revalidate=600`.
**Note**
CloudFront diffusera le contenu périmé jusqu'à la valeur de la `stale-while-revalidate` directive ou à la valeur du [TTL CloudFront maximal](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL), la valeur la plus faible étant retenue. Une fois la durée de vie maximale écoulée, l’objet obsolète n’est plus disponible dans le cache périphérique, quelle que soit sa valeur `stale-while-revalidate`.
### `Stale-If-Error`
Cette directive permet CloudFront de diffuser du contenu périmé depuis le cache si l'origine est inaccessible ou renvoie un code d'erreur compris entre 500 et 600. Cela garantit que les utilisateurs peuvent accéder au contenu même en cas de panne de l'origine.
**Example Exemple : `Stale-If-Error`**
CloudFront effectue les opérations suivantes lorsque vous configurez l'`Cache-Control`en-tête pour qu'il utilise ces directives.
```
Cache-Control: max-age=3600, stale-if-error=86400
```
1. CloudFront met en cache la réponse pendant une heure (`max-age=3600`).
1. Si l'origine est en panne ou renvoie une erreur après cette durée, CloudFront continue à diffuser le contenu périmé pendant 24 heures au maximum () `stale-if-error=86400`
1. Si vous avez configuré des réponses d'erreur personnalisées, CloudFront tentera de diffuser le contenu obsolète si une erreur est détectée dans le délai spécifié`stale-if-error`. Si le contenu périmé n'est pas disponible, il CloudFront diffusera les réponses d'erreur personnalisées que vous avez configurées pour le code d'état d'erreur correspondant. Pour de plus amples informations, veuillez consulter [Génération de réponses aux·erreurs personnalisées](GeneratingCustomErrorResponses.md).
**Remarques**
CloudFront diffusera le contenu périmé jusqu'à la valeur de la `stale-if-error` directive ou à la valeur du [TTL CloudFront maximal](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL), la valeur la plus faible étant retenue. Une fois la durée de vie maximale écoulée, l’objet obsolète n’est plus disponible dans le cache périphérique, quelle que soit sa valeur `stale-if-error`.
Si vous ne configurez pas `stale-if-error` ou ne personnalisez pas les réponses d'erreur, vous CloudFront renverrez l'objet périmé ou redirigerez la réponse d'erreur au visualiseur, selon que l'objet demandé se trouve dans le cache périphérique ou non. Pour de plus amples informations, veuillez consulter [Comment CloudFront traite les erreurs si vous n'avez pas configuré de pages d'erreur personnalisées](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
### Utilisation des deux directives
`stale-while-revalidate` et `stale-if-error` sont des directives de contrôle du cache indépendantes que vous pouvez utiliser ensemble pour réduire la latence et ajouter une mémoire tampon permettant à votre origine de répondre ou de récupérer.
**Example Exemple : utilisation des deux directives**
CloudFront effectue les opérations suivantes lorsque vous configurez l'`Cache-Control`en-tête pour qu'il utilise les directives suivantes.
```
Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400
```
1. CloudFront met en cache la réponse pendant une heure (`max-age=3600`).
1. Si une demande est faite après cette durée, CloudFront diffuse le contenu périmé pendant 10 minutes maximum (`stale-while-revalidate=600`) pendant la revalidation du contenu.
1. Si le serveur d'origine renvoie une erreur alors qu'il CloudFront tente de revalider le contenu, CloudFront il continuera à diffuser le contenu périmé pendant 24 heures au maximum ()`stale-if-error=86400`.
La mise en cache est un équilibre entre performance et actualisation. L'utilisation de directives telles que `stale-while-revalidate` et `stale-if-error` peut améliorer les performances et l'expérience utilisateur, mais vérifiez que les configurations correspondent à l'actualisation souhaitée pour votre contenu. Les directives de contenu obsolètes conviennent mieux aux cas d'utilisation où le contenu doit être actualisé, mais où il n'est pas essentiel de disposer de la dernière version. De plus, si votre contenu ne change pas ou change rarement, `stale-while-revalidate` peut ajouter des demandes réseau inutiles. Envisagez plutôt de définir une durée de cache longue.
## Spécifiez la durée de mise en CloudFront cache des objets
Pour contrôler la durée pendant laquelle un objet CloudFront est conservé dans le cache avant d'envoyer une autre demande à l'origine, vous pouvez :
+ Définissez les valeurs TTL minimale, maximale et par défaut dans le comportement du cache d'une CloudFront distribution. Vous pouvez définir ces valeurs dans une [politique de cache](controlling-the-cache-key.md) associée au comportement de cache (recommandé) ou dans les paramètres de cache hérités.
+ inclure l'en-tête `Cache-Control` ou `Expires` dans les réponses de l'origine. Ces en-têtes permettent également de déterminer la durée pendant laquelle un navigateur conserve un objet dans le cache du navigateur avant d'envoyer une autre demande à CloudFront.
Le tableau suivant explique comment les en-têtes `Cache-Control` et `Expires` envoyés à partir de l'origine fonctionnent avec les paramètres TTL dans un comportement de cache pour affecter la mise en cache.
****
| En-têtes d'origine | Durée de vie minimale = 0 | Durée de vie minimale > 0 |
| --- | --- | --- |
| **L'origine ajoute une directive `Cache-Control: max-age` à l'objet** | **CloudFront mise en cache** CloudFront met en cache l'objet pour la valeur la plus faible entre la valeur de la `Cache-Control: max-age` directive ou la valeur TTL CloudFront maximale. **Conservation en cache par les navigateurs** Les navigateurs mettent l'objet en cache selon la valeur de la directive `Cache-Control: max-age`. | **CloudFront mise en cache** CloudFront la mise en cache dépend des valeurs du TTL CloudFront minimum et du TTL maximum et de la directive : `Cache-Control max-age` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Conservation en cache par les navigateurs** Les navigateurs mettent l'objet en cache selon la valeur de la directive `Cache-Control: max-age`. |
| **L'origine n'ajoute pas de directive `Cache-Control: max-age` à l'objet** | **CloudFront mise en cache** CloudFront met en cache l'objet pour la valeur du TTL CloudFront par défaut. **Conservation en cache par les navigateurs** Dépend du navigateur. | **CloudFront mise en cache** CloudFront met en cache l'objet pour la valeur la plus élevée entre le TTL CloudFront minimum ou le TTL par défaut. **Conservation en cache par les navigateurs** Dépend du navigateur. |
| **L'origine ajoute les directives `Cache-Control: max-age` et `Cache-Control: s-maxage` à l'objet** | **CloudFront mise en cache** CloudFront met en cache l'objet pour la valeur la plus faible entre la valeur de la `Cache-Control: s-maxage` directive ou la valeur TTL CloudFront maximale. **Conservation en cache par les navigateurs** Les navigateurs mettent l'objet en cache selon la valeur de la directive `Cache-Control max-age`. | **CloudFront mise en cache** CloudFront la mise en cache dépend des valeurs du TTL CloudFront minimum et du TTL maximum et de la directive : `Cache-Control: s-maxage` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Conservation en cache par les navigateurs** Les navigateurs mettent l'objet en cache selon la valeur de la directive `Cache-Control: max-age`. |
| **L'origine ajoute un en-tête `Expires`à l'objet** | **CloudFront mise en cache** CloudFront met en cache l'objet jusqu'à la date indiquée dans l'`Expires`en-tête ou jusqu'à la valeur du TTL CloudFront maximal, selon la première de ces deux dates. **Conservation en cache par les navigateurs** Les navigateurs mettent l'objet en cache jusqu'à la date indiquée dans l'en-tête `Expires`. | **CloudFront mise en cache** CloudFront la mise en cache dépend des valeurs du TTL CloudFront minimum et du TTL maximum et de l'en-tête : `Expires` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Conservation en cache par les navigateurs** Les navigateurs mettent l'objet en cache jusqu'à la date et l'heure indiquées dans l'en-tête `Expires`. |
| **L'origine ajoute les directives `Cache-Control: no-cache`, `no-store` et/ou `private` à l'objet** | CloudFront et les navigateurs respectent les en-têtes. | **CloudFront mise en cache** CloudFront met en cache l'objet pour la valeur TTL CloudFront minimale. [Voir l'avertissement en dessous de ce tableau. ](#stale-if-error) **Conservation en cache par les navigateurs** Les navigateurs respectent les en-têtes. |
**Avertissement**
Si votre TTL minimum est supérieur à 0, CloudFront utilise le TTL minimum de la politique de cache, même si les and/or `private` directives`Cache-Control: no-cache`,`no-store`, sont présentes dans les en-têtes d'origine.
Si l'origine est accessible, CloudFront récupère l'objet depuis l'origine et le renvoie au visualiseur.
Si l'origine est inaccessible et que la valeur TTL minimale *ou* maximale est supérieure à 0, CloudFront servira l'objet obtenu précédemment par l'origine.
Pour éviter ce comportement, incluez la directive `Cache-Control: stale-if-error=0` avec l'objet renvoyé de l'origine. Cela CloudFront entraîne le renvoi d'une erreur en réponse aux futures demandes si l'origine est inaccessible, plutôt que de renvoyer l'objet obtenu précédemment.
CloudFront ne met pas en cache le code d'état HTTP 501 (non implémenté) à partir d'une origine S3 lorsque les en-têtes d'origine incluent les and/or `private` directives`Cache-Control: no-cache`,`no-store`,. Il s’agit du comportement par défaut pour une origine S3, même si votre paramètre [Durée de vie minimale](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) est supérieur à 0.
Pour plus d'informations sur la façon de modifier les paramètres des distributions à l'aide de la CloudFront console, consultez[Mettre à jour une distribution](HowToUpdateDistribution.md). Pour plus d'informations sur la modification des paramètres des distributions à l'aide de l' CloudFront API, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
## Ajout d’en-têtes à vos objets à l’aide de la console Amazon S3
Vous pouvez ajouter le champ d’en-tête `Cache-Control` ou `Expires` à vos objets Amazon S3. Pour ce faire, vous devez modifier les champs de métadonnées de l’objet.
**Vous pouvez ajouter un champ d’en-tête `Cache-Control` ou `Expires` à vos objets Amazon S3**
1. Suivez la procédure décrite dans la section **Remplacement de métadonnées définies par le système** de la rubrique [Modification des métadonnées d’objet dans la console Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) du *Guide de l’utilisateur Amazon S3*.
1. Dans **Key (Clé)**, choisissez le nom de l'en-tête que vous ajoutez (**Cache-Control** ou **Expires**).
1. Dans **Value (Valeur)**, entrez une valeur d'en-tête. Par exemple, pour une en-tête `Cache-Control`, vous pouvez entrer `max-age=86400`. Pour `Expires`, vous pouvez entrer une date et une heure d'expiration comme `Wed, 30 Jun 2021 09:28:00 GMT`.
1. Suivez le reste de la procédure pour enregistrer les modifications apportées aux métadonnées.
# Mise en cache de contenu basée sur les paramètres de chaîne de requête
Certaines applications web utilisent des chaînes de requête pour envoyer des informations à l'origine. Une chaîne de requête est la partie d'une requête web qui s'affiche après un caractère `?` ; la chaîne peut contenir un ou plusieurs paramètres séparés par des caractères `&`. Dans l'exemple suivant, la chaîne de requête inclut deux paramètres, *color=red* et *size=large* :
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
Pour les distributions, vous pouvez choisir de transférer les chaînes de requête CloudFront vers votre origine et de mettre en cache votre contenu en fonction de tous les paramètres ou des paramètres sélectionnés. Pourquoi est-ce utile ? Prenez l'exemple de code suivant.
Supposons que votre site web soit disponible en cinq langues. La structure du répertoire et les noms de fichier des cinq versions du site web sont identiques. Lorsqu'un utilisateur consulte votre site Web, les demandes sont transmises pour CloudFront inclure un paramètre de chaîne de requête de langue basé sur la langue choisie par l'utilisateur. Vous pouvez configurer CloudFront pour transférer les chaînes de requête vers l'origine et vers le cache en fonction du paramètre de langue. Si vous configurez votre serveur Web pour renvoyer la version d'une page donnée correspondant à la langue sélectionnée, met en CloudFront cache chaque version de langue séparément, en fonction de la valeur du paramètre de chaîne de requête de langue.
Dans cet exemple, si la page principale de votre site Web est`main.html`, les cinq requêtes suivantes sont mises en CloudFront cache `main.html` cinq fois, une fois pour chaque valeur du paramètre de chaîne de requête de langue :
+ `https://d111111abcdef8.cloudfront.net/main.html?language=de`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=en`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=es`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=fr`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=jp`
Notez ce qui suit :
+ Certains serveurs HTTP ne traitent pas les paramètres des chaînes de requête et ne renvoient donc pas de versions différentes d'un objet basé sur les valeurs des paramètres. Pour ces origines, si vous configurez pour CloudFront transférer les paramètres de chaîne de requête vers l'origine, les mises en cache CloudFront restent basées sur les valeurs des paramètres, même si l'origine renvoie des versions identiques de l'objet CloudFront pour chaque valeur de paramètre.
+ Pour que les paramètres de chaîne de requête fonctionnent comme décrit dans l'exemple ci-dessus avec les langues, vous devez utiliser le caractère `&` comme délimiteur entre les paramètres de chaîne de requête. Si vous utilisez un autre délimiteur, vous risquez d'obtenir des résultats inattendus, en fonction des paramètres que vous spécifiez comme base de mise en cache et de l'ordre dans lequel les paramètres apparaissent dans la chaîne de requête. CloudFront
Les exemples suivants montrent ce qui se passe si vous utilisez un autre délimiteur et que vous configurez CloudFront le cache uniquement en fonction du `color` paramètre :
+ Dans la demande suivante, met en CloudFront cache votre contenu en fonction de la valeur du `color` paramètre, mais CloudFront interprète la valeur comme suit : *red;size=large*
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large`
+ Dans la requête suivante, met en CloudFront cache votre contenu mais ne base pas la mise en cache sur les paramètres de la chaîne de requête. Cela est dû CloudFront au fait que vous avez configuré le cache en fonction du `color` paramètre, mais CloudFront que vous interprétez la chaîne suivante comme contenant uniquement un `size` paramètre ayant une valeur de *large;color=red* :
`https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red`
Vous pouvez configurer CloudFront pour effectuer l'une des opérations suivantes :
+ Ne réachemine pas du tout les chaînes de requête vers l'origine. Si vous ne transférez pas les chaînes de requête, CloudFront il n'est pas mis en cache en fonction des paramètres des chaînes de requête.
+ Réachemine les chaînes de requête vers l'origine et mette en cache en fonction de tous les paramètres de la chaîne de requête.
+ Réachemine les chaînes de requête vers l'origine et mette en cache en fonction des paramètres spécifiés de la chaîne de requête.
Pour de plus amples informations, veuillez consulter [Optimisation de la mise en cache](#query-string-parameters-optimizing-caching).
**Topics**
+ [
## Paramètres de console et d'API pour le réacheminement et la mise en cache des chaînes de requête
](#query-string-parameters-console)
+ [
## Optimisation de la mise en cache
](#query-string-parameters-optimizing-caching)
+ [
## Paramètres de chaîne de requête et journaux CloudFront standard (journaux d'accès)
](#query-string-parameters-access-logs)
## Paramètres de console et d'API pour le réacheminement et la mise en cache des chaînes de requête
Lorsque vous créez une distribution dans la CloudFront console, CloudFront configure le transfert des chaînes de requête et la mise en cache pour vous en fonction de votre type d'origine. Vous pouvez, si vous le souhaitez, modifier manuellement ces paramètres. Pour plus d’informations, consultez les paramètres suivantes dans le [Référence de tous les paramètres de distribution](distribution-web-values-specify.md) :
+ [Réacheminement et mise en cache des chaînes de requête](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString)
+ [Liste d’autorisation des chaînes de requête](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist)
Pour configurer le transfert et la mise en cache des chaînes de requête avec l' CloudFront API, consultez [CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html)et [OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html)dans le *Amazon CloudFront API Reference*.
## Optimisation de la mise en cache
Lorsque vous configurez CloudFront le cache en fonction des paramètres de chaîne de requête, vous pouvez suivre les étapes suivantes pour réduire le nombre de demandes CloudFront transmises à votre origine. Lorsque les emplacements CloudFront périphériques desservent des objets, vous réduisez la charge sur votre serveur d'origine et la latence, car les objets sont servis depuis des emplacements plus proches de vos utilisateurs.
**Mettre en cache uniquement sur des paramètres pour lesquels votre origine renvoie des versions différentes d'un objet**
Pour chaque paramètre de chaîne de requête vers lequel votre application Web transmetCloudFront, CloudFront transmet les demandes à votre origine pour chaque valeur de paramètre et met en cache une version distincte de l'objet pour chaque valeur de paramètre. Ceci est le cas même si votre origine renvoie toujours le même objet quelle que soit la valeur du paramètre. Dans le cas de plusieurs paramètres, le nombre de requêtes et le nombre d'objets sont multipliés.
Nous vous recommandons de CloudFront configurer la mise en cache uniquement en fonction des paramètres de chaîne de requête pour lesquels votre origine renvoie différentes versions, et d'examiner attentivement les avantages de la mise en cache en fonction de chaque paramètre. Par exemple, supposons que vous ayez un site web de vente au détail. Vous présentez les photos d'une veste dans six couleurs différentes et cette veste est disponible dans 10 tailles. Les photos que vous affichez pour la veste montrent les différentes couleurs proposées, mais pas les différentes tailles. Pour optimiser la mise en cache, vous CloudFront devez configurer la mise en cache uniquement en fonction du paramètre de couleur, et non du paramètre de taille. Cela augmente la probabilité de CloudFront répondre à une demande depuis le cache, ce qui améliore les performances et réduit la charge sur votre origine.
**Toujours répertorier les paramètres dans le même ordre**
L'ordre des paramètres a de l'importance dans les chaînes de requête. Dans l'exemple suivant, les chaînes de requête sont identiques, mais les paramètres sont dans un ordre différent. Cela CloudFront entraîne le transfert de deux requêtes distinctes pour image.jpg à votre origine et la mise en cache de deux versions distinctes de l'objet :
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red`
Nous vous recommandons de toujours utiliser le même ordre pour la liste des noms de paramètres, par exemple l'ordre alphabétique.
**Toujours utiliser la même casse pour les noms et les valeurs des paramètres**
CloudFront prend en compte le cas des noms et des valeurs des paramètres lors de la mise en cache basée sur les paramètres des chaînes de requête. Dans l'exemple suivant, les chaînes de requête sont identiques sauf dans le cas des noms et des valeurs des paramètres. Cela CloudFront entraîne le transfert de quatre requêtes distinctes pour image.jpg à votre origine et la mise en cache de quatre versions distinctes de l'objet :
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red`
Nous vous recommandons d'utiliser systématiquement la même casse pour les noms et valeurs des paramètres, par exemple des minuscules.
**N'utilisez pas de noms de paramètres en conflit avec les noms signés URLs**
Si vous utilisez Signed URLs pour restreindre l'accès à votre contenu (si vous avez ajouté des signataires fiables à votre distribution), CloudFront supprimez les paramètres de chaîne de requête suivants avant de transférer le reste de l'URL vers votre source :
+ `Expires`
+ `Key-Pair-Id`
+ `Policy`
+ `Signature`
Si vous utilisez signed URLs et que vous souhaitez configurer pour transférer les chaînes de requête CloudFront vers votre origine, les paramètres de vos propres chaînes de requête ne peuvent pas être nommés `Expires``Key-Pair-Id`,`Policy`, ou`Signature`.
## Paramètres de chaîne de requête et journaux CloudFront standard (journaux d'accès)
Si vous activez la journalisation, CloudFront enregistre l'URL complète, y compris les paramètres de la chaîne de requête. Cela est vrai, que vous ayez ou non configuré pour CloudFront transmettre les chaînes de requête à l'origine. Pour plus d'informations sur la CloudFront journalisation, consultez[Journaux d'accès (journaux standard)](AccessLogs.md).
# Mise en cache de contenu basée sur des cookies
Par défaut, les cookies CloudFront ne sont pas pris en compte lors du traitement des demandes et des réponses, ni lors de la mise en cache de vos objets dans des emplacements périphériques. S'il CloudFront reçoit deux demandes identiques à l'exception du contenu de l'`Cookie`en-tête, il CloudFront traite par défaut les demandes comme identiques et renvoie le même objet pour les deux demandes.
Vous pouvez configurer CloudFront pour transférer à votre origine une partie ou la totalité des cookies contenus dans les requêtes des utilisateurs, et pour mettre en cache des versions distinctes de vos objets en fonction des valeurs des cookies transférés. Dans ce cas, CloudFront utilise une partie ou la totalité des cookies contenus dans les demandes du lecteur, quels que soient ceux pour lesquels le transfert est configuré, afin d'identifier de manière unique un objet dans le cache.
Par exemple, supposons que des demandes pour `locations.html` contiennent un cookie `country` ayant la valeur `uk` ou `fr`. Lorsque vous configurez CloudFront la mise en cache de vos objets en fonction de la valeur du `country` cookie, que CloudFront vous transmettez les demandes `locations.html` à l'origine et que vous incluez le `country` cookie et sa valeur. Votre origine renvoie `locations.html` et met en CloudFront cache l'objet une fois pour les requêtes contenant la valeur du `country` cookie `uk` et une fois pour les requêtes contenant cette valeur. `fr`
**Important**
Amazon S3 et certains serveurs HTTP ne gèrent pas les cookies. Ne configurez pas CloudFront pour transférer les cookies vers une origine qui ne traite pas les cookies ou dont la réponse ne varie pas en fonction des cookies. Cela peut CloudFront entraîner le transfert d'un plus grand nombre de demandes vers l'origine pour le même objet, ce qui ralentit les performances et augmente la charge sur l'origine. Si, dans l'exemple précédent, votre origine ne traite pas le `country` cookie ou renvoie toujours la même version de `locations.html` to, CloudFront quelle que soit la valeur du `country` cookie, ne configurez pas CloudFront pour transférer ce cookie.
À l'inverse, si votre origine personnalisée dépend d'un cookie en particulier ou envoie des réponses différentes en fonction d'un cookie, assurez-vous de configurer le transfert de ce cookie CloudFront vers l'origine. Dans le cas contraire, CloudFront supprimez le cookie avant de transmettre la demande à votre source.
Pour configurer la transmission des cookies, vous mettez à jour le comportement du cache de votre distribution. Pour de plus amples informations sur les comportements de cache, consultez [Paramètres de comportement du cache](DownloadDistValuesCacheBehavior.md), en particulier les sections [Réacheminer les cookies](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) et [Cookies de la liste d’autorisation](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).
Vous pouvez configurer chaque comportement de cache pour effectuer l'une des opérations suivantes :
+ **Transférer tous les cookies vers votre source :** CloudFront inclut tous les cookies envoyés par le spectateur lorsqu'il transmet des demandes à l'origine. Lorsque votre origine renvoie une réponse, elle la met en CloudFront cache en utilisant les noms et les valeurs des cookies figurant dans la demande du lecteur. Si la réponse d'origine inclut `Set-Cookie` des en-têtes, elle les CloudFront renvoie au visualiseur avec l'objet demandé. CloudFront met également en cache `Set-Cookie` les en-têtes avec l'objet renvoyé par l'origine et envoie ces `Set-Cookie` en-têtes aux spectateurs à chaque accès au cache.
+ **Transférer un ensemble de cookies que vous spécifiez :** CloudFront supprime tous les cookies envoyés par le spectateur qui ne figurent pas sur la liste d'autorisation avant de transmettre une demande à l'origine. CloudFront met en cache la réponse en utilisant les noms et valeurs des cookies répertoriés dans la demande du visualiseur. Si la réponse d'origine inclut `Set-Cookie` des en-têtes, elle les CloudFront renvoie au visualiseur avec l'objet demandé. CloudFront met également en cache `Set-Cookie` les en-têtes avec l'objet renvoyé par l'origine et envoie ces `Set-Cookie` en-têtes aux spectateurs à chaque accès au cache.
Pour plus d'informations sur la spécification de caractères génériques dans des noms des cookies, consultez [Cookies de la liste d’autorisation](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).
Pour déterminer le quota actuel concernant le nombre de noms de cookies que vous pouvez transférer pour chaque comportement de cache ou pour demander un quota supérieur, consultez la section [Quotas sur les chaînes de requêtes (paramètres de cache hérités)](cloudfront-limits.md#limits-allowlisted-query-strings).
+ **Ne transférez pas les cookies vers votre source :** CloudFront ne met pas en cache vos objets en fonction du cookie envoyé par le spectateur. En outre, CloudFront supprime les cookies avant de transférer les demandes à votre source et supprime les `Set-Cookie` en-têtes des réponses avant de renvoyer les réponses à vos spectateurs. Étant donné qu’il ne s’agit pas d’un mode d’utilisation optimal des ressources de l’origine, lorsque vous choisissez ce comportement de cache, veillez à ce que votre origine n’ajoute pas de cookies par défaut dans ses réponses.
Remarque à propos de la spécification des cookies que vous ne souhaitez pas transmettre :
**Journaux d'accès**
Si vous configurez CloudFront pour enregistrer les demandes et pour enregistrer les cookies, CloudFront enregistre tous les cookies et tous les attributs des cookies, même si vous configurez pour CloudFront ne pas transférer les cookies vers votre origine ou si vous configurez CloudFront pour ne transférer que des cookies spécifiques. Pour plus d'informations sur la CloudFront journalisation, consultez[Journaux d'accès (journaux standard)](AccessLogs.md).
**Sensibilité à la casse**
Les noms et valeurs de cookie sont sensibles à la casse. Par exemple, s'il CloudFront est configuré pour transférer tous les cookies et que deux demandes d'affichage pour le même objet contiennent des cookies identiques, sauf majuscules, CloudFront met l'objet en cache deux fois.
**CloudFront trie les biscuits**
S'il CloudFront est configuré pour transférer les cookies (tous ou un sous-ensemble), CloudFront trie les cookies dans l'ordre naturel par nom de cookie avant de transmettre la demande à votre origine.
Les noms de cookies commençant par le `$` caractère ne sont pas pris en charge. CloudFront supprimera le cookie avant de transmettre la demande à l'origine. Vous pouvez supprimer le caractère `$` ou en spécifier un autre au début du nom du cookie.
**`If-Modified-Since` et `If-None-Match`**
`If-Modified-Since`et les demandes `If-None-Match` conditionnelles ne sont pas prises en charge lorsqu'elle CloudFront est configurée pour transférer les cookies (tous ou un sous-ensemble).
**Un format standard de paire nom-valeur est requis**
CloudFront transmet un en-tête de cookie uniquement si la valeur est conforme au [format standard de paire nom-valeur](https://tools.ietf.org/html/rfc6265#section-4.1.1), par exemple : `"Cookie: cookie1=value1; cookie2=value2"`
**Désactiver la mise en cache des en-têtes `Set-Cookie`**
S'il CloudFront est configuré pour transférer les cookies vers l'origine (qu'il s'agisse de tous les cookies ou de cookies spécifiques), il met également en cache `Set-Cookie` les en-têtes reçus dans la réponse d'origine. CloudFront inclut ces `Set-Cookie` en-têtes dans sa réponse au visualiseur d'origine, et les inclut également dans les réponses suivantes diffusées à partir du CloudFront cache.
Si vous souhaitez recevoir des cookies à l'origine, mais que vous ne voulez pas CloudFront mettre en cache `Set-Cookie` les en-têtes dans les réponses de votre origine, configurez votre origine pour ajouter un `Cache-Control` en-tête avec une `no-cache` directive spécifiant un `Set-Cookie` nom de champ. Par exemple : `Cache-Control: no-cache="Set-Cookie"`. Pour de plus amples informations, consultez [Response Cache-Control Directives](https://tools.ietf.org/html/rfc7234#section-5.2.2) dans le standard *Hypertext Transfer Protocol (HTTP/1.1): mise en cache*.
**Longueur maximum des noms de cookie**
Si vous configurez CloudFront pour transférer des cookies spécifiques vers votre origine, le nombre total d'octets de tous les noms de cookies que vous configurez CloudFront pour le transfert ne peut pas dépasser 512 moins le nombre de cookies que vous transférez. Par exemple, si vous configurez CloudFront pour transférer 10 cookies vers votre origine, la longueur combinée des noms des 10 cookies ne peut pas dépasser 502 octets (512 à 10).
Si vous configurez CloudFront pour transférer tous les cookies vers votre origine, la longueur des noms des cookies n'a pas d'importance.
Pour plus d'informations sur l'utilisation de la CloudFront console pour mettre à jour une distribution CloudFront afin de transférer les cookies à l'origine, consultez[Mettre à jour une distribution](HowToUpdateDistribution.md). Pour plus d'informations sur l'utilisation de l' CloudFront API pour mettre à jour une distribution, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
# Mise en cache de contenu basée sur des en-têtes de demandes
CloudFront vous permet de choisir si vous souhaitez transférer les en-têtes CloudFront vers votre origine et mettre en cache des versions distinctes d'un objet spécifique en fonction des valeurs d'en-tête figurant dans les demandes des utilisateurs. Cela vous permet de servir des versions différentes de votre contenu selon l'appareil employé par l'utilisateur, l'emplacement de l'utilisateur, la langue utilisée par l'utilisateur et différents autres critères.
**Topics**
+ [
## En-têtes et distributions web : présentation
](#header-caching-web)
+ [
## Sélection des en-têtes sur lesquels baser la mise en cache
](#header-caching-web-selecting)
+ [
## Configurer CloudFront pour respecter les paramètres CORS
](#header-caching-web-cors)
+ [
## Configuration de la mise en cache en fonction du type d’appareil
](#header-caching-web-device)
+ [
## Configuration de la mise en cache en fonction de la langue de l’utilisateur
](#header-caching-web-language)
+ [
## Configuration de la mise en cache en fonction de l’emplacement de l’utilisateur
](#header-caching-web-location)
+ [
## Configuration de la mise en cache en fonction du protocole de la demande
](#header-caching-web-protocol)
+ [
## Configuration de mise en cache pour les fichiers compressés
](#header-caching-web-compressed)
+ [
## Incidence de la mise en cache basée sur les en-têtes sur les performances
](#header-caching-web-performance)
+ [
## Impact de la casse des en-têtes et des valeurs d'en-tête sur la mise en cache
](#header-caching-web-case)
+ [
## En-têtes CloudFront renvoyés au visualiseur
](#header-caching-web-response)
## En-têtes et distributions web : présentation
Par défaut, les en-têtes CloudFront ne sont pas pris en compte lors de la mise en cache de vos objets dans des emplacements périphériques. Si votre origine renvoie deux objets et qu'ils ne diffèrent que par les valeurs des en-têtes de demande, met en CloudFront cache une seule version de l'objet.
Vous pouvez configurer CloudFront pour transférer les en-têtes vers l'origine, ce qui entraîne la mise CloudFront en cache de plusieurs versions d'un objet en fonction des valeurs d'un ou de plusieurs en-têtes de demande. CloudFront Pour configurer la mise en cache des objets en fonction des valeurs d'en-têtes spécifiques, vous devez spécifier les paramètres de comportement du cache pour votre distribution. Pour plus d'informations, consultez [Mise en cache basée sur des en-têtes de requête sélectionnés](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders).
Par exemple, supposons que des demandes d'utilisateur pour `logo.jpg` contiennent un en-tête `Product` personnalisé ayant la valeur `Acme` ou `Apex`. Lorsque vous configurez CloudFront pour mettre en cache vos objets en fonction de la valeur de l'`Product`en-tête, transférez CloudFront les demandes `logo.jpg` à l'origine et incluez les valeurs de l'`Product`en-tête et de l'en-tête. CloudFront met en cache `logo.jpg` une fois pour les demandes dans lesquelles se trouve la valeur de l'`Product`en-tête `Acme` et une fois pour les demandes dans lesquelles la valeur est`Apex`.
Vous pouvez configurer chaque comportement de cache d'une distribution pour exécuter l'une des opérations suivantes :
+ Transmettre tous les en-têtes à votre origine
**Note**
**Pour les anciens paramètres de cache** : si vous configurez CloudFront pour transférer tous les en-têtes vers votre origine, les objets associés à ce comportement de cache CloudFront ne sont pas mis en cache. Par contre, il envoie chaque demande à l'origine.
+ Transférez la liste des en-têtes que vous spécifiez. CloudFront met en cache vos objets en fonction des valeurs de tous les en-têtes spécifiés. CloudFront transmet également les en-têtes qu'il transmet par défaut, mais il met en cache vos objets uniquement en fonction des en-têtes que vous spécifiez.
+ Transmettre uniquement les en-têtes par défaut. Dans cette configuration, vos objets CloudFront ne sont pas mis en cache en fonction des valeurs contenues dans les en-têtes de demande.
Pour obtenir le quota actuel relatif au nombre d'en-têtes que vous pouvez transférer pour chaque comportement de cache ou pour demander un quota supérieur, consultez la section [Quotas sur les en-têtes](cloudfront-limits.md#limits-custom-headers).
Pour plus d'informations sur l'utilisation de la CloudFront console pour mettre à jour une distribution afin CloudFront de transférer les en-têtes à l'origine, consultez[Mettre à jour une distribution](HowToUpdateDistribution.md). Pour plus d'informations sur l'utilisation de l' CloudFrontAPI pour mettre à jour une distribution existante, consultez [Mettre à jour la distribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) dans le *manuel Amazon CloudFront API Reference*.
## Sélection des en-têtes sur lesquels baser la mise en cache
Les en-têtes que vous pouvez transférer vers l'origine et sur lesquels CloudFront repose la mise en cache varient selon que votre origine est un compartiment Amazon S3 ou une origine personnalisée.
+ **Amazon S3 —** Vous pouvez configurer CloudFront pour transférer et mettre en cache vos objets en fonction d'un certain nombre d'en-têtes spécifiques (voir la liste d'exceptions suivante). Toutefois, nous vous recommandons d'éviter de transférer des en-têtes avec une origine Amazon S3, sauf si vous devez implémenter le partage des ressources cross-origin (CORS) ou que vous souhaitez personnaliser du contenu en utilisant Lambda@Edge dans les événements axés sur l'origine.
+ Pour configurer CORS, vous devez transférer des en-têtes qui permettent CloudFront de distribuer du contenu pour les sites Web activés pour le partage de ressources entre origines (CORS). Pour de plus amples informations, veuillez consulter [Configurer CloudFront pour respecter les paramètres CORS](#header-caching-web-cors).
+ Pour personnaliser le contenu en utilisant des en-têtes que vous transférez vers votre origine Amazon S3, vous écrivez et ajoutez des fonctions Lambda @Edge et vous les associez à CloudFront votre distribution pour qu'elles soient déclenchées par un événement lié à l'origine. Pour plus d'informations sur l'utilisation des en-têtes afin de personnaliser du contenu, consultez [Personnalisation de contenu à l'aide des en-têtes Pays ou Type d'appareil – exemples](lambda-examples.md#lambda-examples-redirecting-examples).
Nous vous recommandons d'éviter de transférer des en-têtes que vous n'utilisez pas pour personnaliser du contenu, car le transfert d'en-têtes supplémentaires peut réduire votre taux d'accès au cache. En d'autres termes, il ne CloudFront peut pas répondre à autant de demandes provenant des caches périphériques par rapport à l'ensemble des demandes.
+ **Origine personnalisée** — Vous pouvez configurer le cache CloudFront en fonction de la valeur de n'importe quel en-tête de demande, à l'exception de ce qui suit :
+ `Connection`
+ `Cookie` – Si vous souhaitez effectuer la transmission et la mise en cache en fonction de cookies, vous utilisez un paramètre distinct dans votre distribution. Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md).
+ `Host (for Amazon S3 origins)`
+ `Proxy-Authorization`
+ `TE`
+ `Upgrade`
Vous pouvez configurer CloudFront pour mettre en cache des objets en fonction des valeurs `User-Agent` des en-têtes `Date` et, mais nous ne le recommandons pas. Ces en-têtes ont de nombreuses valeurs possibles, et la mise en cache basée sur leurs valeurs peut entraîner le transfert d'un plus grand nombre de demandes CloudFront vers votre origine.
Pour obtenir la liste complète des en-têtes de requête HTTP et leur mode CloudFront de traitement, consultez[En-têtes et CloudFront comportement des requêtes HTTP (personnalisés et origines d'Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
## Configurer CloudFront pour respecter les paramètres CORS
Si vous avez activé le partage des ressources cross-origin (CORS) dans un compartiment Amazon S3 ou une origine personnalisée, vous devez choisir des en-têtes spécifiques à transmettre pour respecter les paramètres CORS. Les en-têtes que vous devez transférer diffèrent en fonction de l'origine (Amazon S3 ou origine personnalisée) et selon que vous souhaitez ou non mettre en cache les réponses `OPTIONS`.
**Amazon S3**
+ Si vous souhaitez que les réponses `OPTIONS` soient mises en cache, procédez comme suit :
+ Choisissez les options pour les paramètres de comportement de cache par défaut qui permettent la mise en cache pour les réponses `OPTIONS`.
+ Configurez CloudFront pour transférer les en-têtes suivants : `Origin``Access-Control-Request-Headers`, et`Access-Control-Request-Method`.
+ Si vous ne voulez pas que les réponses `OPTIONS` soient mises en cache, configurez CloudFront de sorte à réacheminer l'en-tête `Origin`, ainsi que tous les autres en-têtes requis par votre origine (`Access-Control-Request-Headers` ou `Access-Control-Request-Method` par exemple).
**Origines personnalisées** – Transmettez l'en-tête `Origin` en même temps que tous les autres en-têtes requis par votre origine.
CloudFront Pour configurer la mise en cache des réponses basées sur CORS, vous devez configurer CloudFront pour transférer les en-têtes à l'aide d'une politique de cache. Pour de plus amples informations, veuillez consulter [Contrôle de la clé de cache à l’aide d’une politique](controlling-the-cache-key.md).
Pour plus d’informations sur CORS et Amazon S3, consultez la section [Utilisation du partage des ressources cross-origin (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) du *Guide de l'utilisateur Amazon Simple Storage Service*.
## Configuration de la mise en cache en fonction du type d’appareil
Si vous souhaitez CloudFront mettre en cache différentes versions de vos objets en fonction de l'appareil utilisé par l'utilisateur pour afficher votre contenu, configurez CloudFront pour transférer les en-têtes applicables vers votre origine personnalisée :
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
Sur la base de la valeur de l'`User-Agent`en-tête, CloudFront définit la valeur de ces en-têtes `false` avant `true` ou avant le transfert de la demande à votre origine. Si un appareil entre dans plusieurs catégories, plusieurs valeurs peuvent être `true`. Par exemple, pour certaines tablettes, CloudFront vous pouvez définir les deux options `CloudFront-Is-Mobile-Viewer` et la valeur `CloudFront-Is-Tablet-Viewer` sur`true`.
## Configuration de la mise en cache en fonction de la langue de l’utilisateur
Si vous souhaitez CloudFront mettre en cache différentes versions de vos objets en fonction de la langue spécifiée dans la demande, configurez CloudFront pour transmettre l'`Accept-Language`en-tête à votre origine.
## Configuration de la mise en cache en fonction de l’emplacement de l’utilisateur
Si vous souhaitez CloudFront mettre en cache différentes versions de vos objets en fonction du pays d'origine de la demande, configurez CloudFront pour transférer l'`CloudFront-Viewer-Country`en-tête à votre origine. CloudFront convertit automatiquement l'adresse IP d'où provient la demande en un code de pays à deux lettres. Pour une easy-to-use liste des codes de pays, triable par code et par nom de pays, voir l'entrée de Wikipédia [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) alpha-2.
## Configuration de la mise en cache en fonction du protocole de la demande
Si vous souhaitez CloudFront mettre en cache différentes versions de vos objets en fonction du protocole de la demande, HTTP ou HTTPS, configurez CloudFront pour transférer l'`CloudFront-Forwarded-Proto`en-tête à votre origine.
## Configuration de mise en cache pour les fichiers compressés
Si votre origine prend en charge la compression Brotli, vous pouvez effectuer une mise en cache en fonction de l'en-tête `Accept-Encoding`. Configurez la mise en cache en fonction de `Accept-Encoding` uniquement si votre origine traite différents contenus selon l'en-tête.
## Incidence de la mise en cache basée sur les en-têtes sur les performances
Lorsque vous configurez CloudFront le cache en fonction d'un ou de plusieurs en-têtes et que les en-têtes ont plusieurs valeurs possibles, CloudFront transfère davantage de demandes à votre serveur d'origine pour le même objet. Ceci ralentit les performances et augmente la charge sur votre serveur d'origine. Si votre serveur d'origine renvoie le même objet quelle que soit la valeur d'un en-tête donné, nous vous recommandons de ne pas CloudFront configurer le cache en fonction de cet en-tête.
Si vous configurez CloudFront pour transférer plusieurs en-têtes, l'ordre des en-têtes dans les demandes des utilisateurs n'affecte pas la mise en cache tant que les valeurs sont identiques. Par exemple, si une demande contient les en-têtes A:1, B:2 et qu'une autre demande contient B:2, A:1, une seule copie de l'objet est mise en CloudFront cache.
## Impact de la casse des en-têtes et des valeurs d'en-tête sur la mise en cache
Lors de la CloudFront mise en cache basée sur les valeurs d'en-tête, il ne prend pas en compte le cas du nom de l'en-tête, mais il prend en compte le cas de la valeur de l'en-tête :
+ Si les demandes de l'utilisateur incluent les deux`product:Acme`, `Product:Acme` et ne met en CloudFront cache un objet qu'une seule fois. La seule différence entre les deux est la casse du nom de l'en-tête qui n'a pas d'incidence sur la mise en cache.
+ Si les demandes de l'utilisateur incluent les deux `Product:Acme` et`Product:acme`, met en CloudFront cache un objet deux fois, car la valeur se trouve `Acme` dans certaines demandes et `acme` dans d'autres.
## En-têtes CloudFront renvoyés au visualiseur
La configuration CloudFront pour transférer et mettre en cache les en-têtes n'a aucune incidence sur les en-têtes CloudFront renvoyés au visualiseur. CloudFront renvoie tous les en-têtes qu'il obtient depuis l'origine, à quelques exceptions près. Pour plus d'informations, consultez la rubrique applicable :
+ **Origines Amazon S3** — Voir [En-têtes de réponse HTTP qui CloudFront suppriment ou mettent à jour](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers).
+ **Origines personnalisées** – Voir [En-têtes de réponse HTTP qui CloudFront suppriment ou remplacent](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders).