Méthodes d’assistance pour la modification de l’origine - Amazon CloudFront

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.

Méthodes d’assistance pour la modification de l’origine

Cette section s'applique si vous mettez à jour ou modifiez dynamiquement l'origine utilisée dans la demande dans votre code CloudFront Functions. Vous pouvez mettre à jour l'origine uniquement à la CloudFront demande du spectateur. CloudFront Functions possède un module qui fournit des méthodes d'assistance pour mettre à jour ou modifier dynamiquement l'origine.

Pour utiliser ce module, créez une CloudFront fonction à l'aide de JavaScript Runtime 2.0 et incluez l'instruction suivante dans la première ligne du code de fonction :

import cf from 'cloudfront';

Pour de plus amples informations, veuillez consulter Fonctionnalités d’exécution JavaScript 2.0 pour les fonctions CloudFront.

Note

Les pages de l’API de test et de la console de test ne vérifient pas si une modification de l’origine s’est produite. Cependant, les tests garantissent que le code de fonction s’exécute sans erreur.

Choisissez entre CloudFront Functions et Lambda @Edge

Vous pouvez mettre à jour vos origines en utilisant CloudFront Functions ou Lambda @Edge.

Lorsque vous utilisez CloudFront Functions pour mettre à jour les origines, vous utilisez le déclencheur d'événement de demande du visualiseur, ce qui signifie que cette logique s'exécutera à chaque demande lorsque cette fonction est utilisée. Lorsque vous utilisez Lambda@Edge, les fonctionnalités de mise à jour de l’origine se trouvent sur le déclencheur d’événement demande de l’origine, ce qui signifie que cette logique ne s’exécute qu’en cas d’échec du cache.

Votre choix dépend largement de votre charge de travail et de toute utilisation existante de CloudFront Functions et Lambda @Edge dans vos distributions. Les considérations suivantes peuvent vous aider à décider d'utiliser CloudFront Functions ou Lambda @Edge pour mettre à jour vos origines.

CloudFront Les fonctions sont particulièrement utiles dans les situations suivantes :

  • Lorsque vos demandes sont dynamiques (c'est-à-dire qu'elles ne peuvent pas être mises en cache) et qu'elles vont toujours à l'origine. CloudFront Les fonctions offrent de meilleures performances et un coût global inférieur.

  • Lorsque vous disposez déjà d'une CloudFront fonction de demande d'affichage qui s'exécute sur chaque demande, vous pouvez ajouter la logique de mise à jour de l'origine à la fonction existante.

Pour utiliser CloudFront Functions pour mettre à jour les origines, consultez les méthodes d'assistance décrites dans les rubriques suivantes.

Lambda@Edge est particulièrement utile dans les cas suivants :

  • Lorsque le contenu peut être facilement mis en cache, Lambda @Edge peut être plus rentable car il s'exécute uniquement en cas d'erreur de cache, CloudFront tandis que Functions s'exécute sur chaque requête.

  • Lorsque vous disposez déjà d’une fonction Lambda@Edge de type demande de l’origine, vous pouvez y ajouter la logique de mise à jour de l’origine.

  • Lorsque votre logique de mise à jour d’origine nécessite de récupérer des données à partir de sources de données tierces, telles qu’Amazon DynamoDB ou Amazon S3.

Pour plus d’informations sur Lambda@Edge, consultez Personnalisation en périphérie avec Lambda@Edge.

updateRequestOrigin() méthode

Utilisez la méthode updateRequestOrigin() pour mettre à jour les paramètres d’origine d’une demande. Vous pouvez utiliser cette méthode pour mettre à jour les propriétés d’origine existantes pour les origines déjà définies dans votre distribution, ou pour définir une nouvelle origine pour la demande. Pour ce faire, spécifiez les propriétés que vous souhaitez modifier.

Important

Tous les paramètres que vous ne spécifiez pas dans updateRequestOrigin() hériteront des paramètres définis dans la configuration de l’origine existante.

L'origine définie par la updateRequestOrigin() méthode peut être n'importe quel point de terminaison HTTP et il n'est pas nécessaire qu'il s'agisse d'une origine existante au sein de votre CloudFront distribution.

Remarques
  • Si vous mettez à jour une origine qui fait partie d’un groupe d’origines, seule l’origine principale du groupe d’origines est mise à jour. L’origine secondaire reste inchangée. Tout code de réponse provenant de l’origine modifiée qui correspond aux critères de basculement déclenchera un basculement vers l’origine secondaire.

  • Si vous modifiez le type d’origine et que l’OAC est activé, veillez à ce que le type d’origine dans originAccessControlConfig corresponde au nouveau type d’origine.

  • Vous ne pouvez pas utiliser la méthode updateRequestOrigin() pour mettre à jour les origines VPC. La demande échouera.

Demande

updateRequestOrigin({origin properties})

Les origin properties peuvent contenir les éléments suivants :

domainName (facultatif)

Nom de domaine de l’origine. Si cette valeur n’est pas fournie, le nom de domaine de l’origine associée est utilisé à la place.

Pour les origines personnalisées

Spécifiez un nom de domaine DNS, tel que www.example.com. Le nom de domaine ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. Le nom du domaine peut contenir jusqu’à 253 caractères.

Pour les origines S3

Spécifiez le nom de domaine DNS du compartiment Amazon S3, tel que amzn-s3-demo-bucket.s3.eu-west-1.amazonaws.com. Il peut comporter jusqu’à 128 caractères, qui doivent tous être en minuscules.

HostHeader (facultatif, pour les origines personnalisées autres que S3)

L'en-tête de l'hôte à utiliser lorsque vous envoyez la demande à l'origine. Si ce n'est pas le cas, la valeur du paramètre DomainName est utilisée. Si aucun en-tête d'hôte ou paramètre de nom de domaine n'est fourni, le nom de domaine de l'origine attribuée est utilisé ou l'en-tête de l'hôte de la demande entrante si la politique de transfert vers l'origine (FTO) inclut l'hôte. L'en-tête de l'hôte ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. L'en-tête de l'hôte peut comporter jusqu'à 253 caractères.

originPath (facultatif)

Chemin de répertoire à l’origine où la demande doit localiser le contenu. Ce chemin doit commencer par une barre oblique (/) mais ne doit pas se terminer par une barre oblique. Par exemple, il ne doit pas se terminer par example-path/. Si cette valeur n’est pas fournie, le chemin d’origine de l’origine associée est utilisé.

Pour les origines personnalisées

Le chemin d’accès doit être codé en URL et ne pas dépasser 255 caractères.

customHeaders (facultatif)

Vous pouvez inclure des en-têtes personnalisés dans la requête en spécifiant un nom et une valeur d'en-tête pour chacun d'eux. Le format est différent de celui des en-têtes de demande et de réponse dans la structure de l’événement. Utilisez la syntaxe de paire clé-valeur suivante :

{"key1": "value1", "key2": "value2", ...}

Vous ne pouvez pas ajouter d’en-têtes non autorisés, et un en-tête portant le même nom ne peut pas déjà être présent dans la demande entrante headers. Le nom de l’en-tête doit être en minuscules dans le code de votre fonction. Lorsque CloudFront Functions reconvertit l'objet d'événement en requête HTTP, la première lettre de chaque mot dans les noms d'en-tête est mise en majuscule et les mots sont séparés par un trait d'union.

Par exemple, si le code de votre fonction ajoute un en-tête nomméexample-header-name, le CloudFront convertit en en-tête Example-Header-Name dans la requête HTTP. Pour plus d’informations, consultez En-têtes personnalisés que CloudFront ne peut pas ajouter aux demandes d'origine et Restrictions sur les fonctions périphériques.

Si cette valeur n’est pas fournie, les en-têtes personnalisés de l’origine associée sont utilisés.

connectionAttempts (facultatif)

Le nombre de CloudFront tentatives de connexion à l'origine. La valeur minimale est 1 et la valeur maximale est 3. Si cette valeur n’est pas fournie, les tentatives de connexion provenant de l’origine attribuée sont utilisées.

originShield (facultatif)

Cela active ou met à jour CloudFront Origin Shield. L'utilisation d'Origin Shield permet de réduire la charge sur votre origine. Pour de plus amples informations, veuillez consulter Utiliser Amazon CloudFront Origin Shield. Si cette valeur n’est pas fournie, les paramètres Origin Shield de l’origine attribuée sont utilisés.

enabled (obligatoire)

Expression booléenne permettant d’activer ou de désactiver Origin Shield. Accepte la valeur true ou false.

region (obligatoire lorsqu’elle est activée)

Le Région AWS pour Origin Shield. Spécifiez l' Région AWS dont la latence est la plus faible par rapport à votre origine. Utilisez le code de région et non le nom de la région. Par exemple, utilisez us-east-2 pour spécifier la région USA Est (Ohio).

Lorsque vous activez CloudFront Origin Shield, vous devez Région AWS le spécifier. Pour obtenir la liste des Régions AWS disponibles et choisir la région la plus appropriée pour votre origine, consultez Choisissez la AWS région pour Origin Shield.

originAccessControlConfig (facultatif)

L’identifiant unique d’un contrôle d’accès d’origine (OAC) pour cette origine. Ceci n'est utilisé que lorsque l'origine prend en charge un CloudFront OAC, tel qu'Amazon S3, la URLs fonction Lambda et la MediaStore V2. MediaPackage Si cette valeur n’est pas fournie, les paramètres OAC de l’origine attribuée sont utilisés.

L’identité d’accès d’origine (OAI) héritée n’est pas prise en charge. Pour de plus amples informations, veuillez consulter Restriction de l’accès à une origine AWS.

enabled (obligatoire)

Expression booléenne permettant d’activer ou de désactiver l’OAC. Accepte la valeur true ou false.

signingBehavior (obligatoire si activé)

Spécifie les demandes CloudFront signées (ajoute des informations d'authentification à). Spécifiez always pour le cas d'utilisation le plus courant. Pour de plus amples informations, veuillez consulter Paramètres avancés pour le contrôle d'accès à l'origine.

Ce champ peut avoir l'une des valeurs suivantes :

  • always— CloudFront signe toutes les demandes d'origine, en remplaçant l'Authorizationen-tête de la demande du visualiseur s'il en existe une.

  • never— CloudFront ne signe aucune demande d'origine. Cette valeur désactive le contrôle d’accès d’origine pour l’origine.

  • no-override— Si la demande du lecteur ne contient pas l'Authorizationen-tête, CloudFront signe la demande d'origine. Si la demande du visualiseur contient l'Authorizationen-tête, CloudFront elle ne signe pas la demande d'origine et transmet à la place l'Authorizationen-tête de la demande du visualiseur.

    Avertissement

    Pour transmettre l’en-tête Authorization de la demande de l’utilisateur, vous devez l’ajouter à une politique de demande d’origine pour tous les comportements de cache qui utilisent les origines associées à ce contrôle d’accès d’origine. Pour de plus amples informations, veuillez consulter Contrôle des demandes d’origine à l’aide d’une stratégie.

signingProtocol (obligatoire si activé)

Protocole de signature de l'OAC, qui détermine la manière dont les demandes sont CloudFront signées (authentifiées). La seule valeur valide est sigv4.

originType (obligatoire si activé)

Le type d’origine de cet OAC. Les valeurs valides sont les suivantes : s3, mediapackagev2, mediastore et lambda.

timeouts (facultatif)

Les délais d'expiration que vous pouvez spécifier CloudFront doivent tenter d'attendre que les origines répondent ou envoient des données. Si cette valeur n’est pas fournie, les paramètres de délai d’attente de l’origine attribuée sont utilisés.

Note

Sauf indication contraire, ces délais prennent en charge les origines personnalisées et Amazon S3.

readTimeout (facultatif)

readTimeout s’applique aux deux valeurs suivantes :

  • Durée (en secondes) d' CloudFront attente d'une réponse après avoir transmis une demande à l'origine.

  • Durée (en secondes) d' CloudFront attente après réception d'un paquet de réponse de l'origine et avant de recevoir le paquet suivant.

Le délai minimum est de 1 seconde et le délai maximum est de 120 secondes. Pour de plus amples informations, veuillez consulter Délai de réponse.

responseCompletionTimeout (facultatif)

Durée (en secondes) pendant laquelle une demande provenant CloudFront de l'origine peut rester ouverte et attendre une réponse. Si la réponse complète n'est pas reçue de l'origine à ce moment-là, CloudFront met fin à la connexion.

La valeur de responseCompletionTimeout doit être supérieure ou égale à la valeur de readTimeout. Pour de plus amples informations, veuillez consulter Délai d’exécution de la réponse.

keepAliveTimeout (facultatif)

Ce délai s’applique uniquement aux origines personnalisées, et non aux origines Amazon S3. (Les configurations d’origine S3 ignoreront ces paramètres.)

keepAliveTimeoutSpécifie la durée pendant CloudFront laquelle vous devez essayer de maintenir la connexion à l'origine après avoir reçu le dernier paquet de la réponse. Le délai minimum est de 1 seconde et le délai maximum est de 120 secondes. Pour de plus amples informations, veuillez consulter Délai d’attente des connexions actives (origines personnalisées et VPC uniquement).

connectionTimeout (facultatif)

Le nombre de secondes d' CloudFront attente lorsque vous essayez d'établir une connexion avec l'origine. Le délai minimum est de 1 seconde et le délai maximum est de 10 secondes. Pour de plus amples informations, veuillez consulter Délai de connexion.

customOriginConfig (facultatif)

Utilisez customOriginConfig pour spécifier les paramètres de connexion des origines qui ne sont pas un compartiment Amazon S3. Il existe une exception : vous pouvez spécifier ces paramètres si le compartiment S3 est configuré avec un hébergement de site web statique. (Les autres types de configurations de compartiment S3 ignoreront ces paramètres.) Si customOriginConfig n’est pas renseigné, les paramètres de l’origine attribuée sont utilisés.

port (obligatoire)

Port HTTP CloudFront utilisé pour se connecter à l'origine. Spécifiez le port HTTP sur lequel l'origine personnalisée écoute.

protocol (obligatoire)

Spécifie le protocole (HTTP ou HTTPS) CloudFront utilisé pour se connecter à l'origine. Les valeurs valides sont les suivantes :

  • http— utilise CloudFront toujours le protocole HTTP pour se connecter à l'origine

  • https— utilise CloudFront toujours HTTPS pour se connecter à l'origine

sslProtocols (obligatoire)

Une liste qui indique le SSL/TLS protocole minimal à CloudFront utiliser lors de la connexion à votre point d'origine via HTTPS. Les valeurs valides sont les suivantes : SSLv3, TLSv1, TLSv1.1 et TLSv1.2. Pour de plus amples informations, veuillez consulter Minimum de protocole SSL d’origine.

ipAddressType (facultatif)

Spécifie le type d'adresse IP CloudFront utilisé pour se connecter à l'origine. Les valeurs valides sont ipv4, ipv6 et dualstack. La modification de ipAddressType n’est prise en charge que lorsque la propriété domainName est également modifiée.

sni (facultatif, pour les origines personnalisées autres que S3)

L'indication du nom du serveur (SNI) est une extension du protocole TLS (Transport Layer Security) par laquelle un client indique le nom d'hôte auquel il tente de se connecter au début du processus de prise de contact TLS. Cette valeur doit correspondre à un nom courant figurant sur un certificat TLS sur votre serveur d'origine. Dans le cas contraire, votre serveur d'origine risque de générer une erreur.

Si ce n'est pas le cas, la valeur du hostHeader paramètre est utilisée. Si l'en-tête de l'hôte n'est pas fourni, la valeur du domainName paramètre est utilisée.

Si aucun en-tête d'hôte ou paramètre de nom de domaine n'est fourni, le nom de domaine de l'origine attribuée est utilisé ou l'en-tête de l'hôte de la demande entrante si la politique de transfert vers l'origine (FTO) inclut l'hôte. Le SNI ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. Le SNI peut comporter jusqu'à 253 caractères.

allowedCertificateNames (facultatif, pour les origines personnalisées autres que S3)

Vous pouvez inclure une liste de noms de certificats valides à utiliser pour valider le domaine correspondant CloudFront au certificat TLS de votre serveur d'origine lors de la prise de contact TLS avec votre serveur d'origine. Ce champ attend un tableau de noms de domaine valides et peut inclure des domaines génériques, tels que*.example.com.

Vous pouvez spécifier jusqu'à 20 noms de certificats autorisés. Chaque nom de certificat peut comporter jusqu'à 64 caractères.

Exemple – mise à jour de l’origine de la demande Amazon S3

L’exemple suivant modifie l’origine de la demande de l’utilisateur pour la remplacer par un compartiment S3, active l’OAC et réinitialise les en-têtes personnalisés envoyés à l’origine.

cf.updateRequestOrigin({ "domainName" : "amzn-s3-demo-bucket-in-us-east-1.s3.us-east-1.amazonaws.com", "originAccessControlConfig": { "enabled": true, "signingBehavior": "always", "signingProtocol": "sigv4", "originType": "s3" }, // Empty object resets any header configured on the assigned origin "customHeaders": {} });
Exemple – mise à jour de l’origine de demande Application Load Balancer

L’exemple suivant modifie l’origine de la demande de l’utilisateur pour la remplacer par une origine Application Load Balancer et définit un en-tête personnalisé ainsi que des délais d’attente.

cf.updateRequestOrigin({ "domainName" : "example-1234567890.us-east-1.elb.amazonaws.com", "timeouts": { "readTimeout": 30, "connectionTimeout": 5 }, "customHeaders": { "x-stage": "production", "x-region": "us-east-1" } });
Exemple – mise à jour vers une origine avec Origin Shield activé

Dans l’exemple suivant, Origin Shield est activé sur l’origine de la distribution. Le code de fonction met à jour uniquement le nom de domaine utilisé pour l’origine et omet tous les autres paramètres facultatifs. Dans ce cas, Origin Shield continuera d’être utilisé avec le nom de domaine d’origine modifié, puisque les paramètres Origin Shield n’ont pas été mis à jour.

cf.updateRequestOrigin({ "domainName" : "www.example.com" });
Exemple — Met à jour l'en-tête de l'hôte, le SNI et les noms des certificats autorisés
Avertissement

Dans la plupart des cas d'utilisation, vous n'aurez pas besoin d'utiliser ce type de modification pour les demandes envoyées à votre origine. Ces paramètres ne doivent pas être utilisés à moins que vous ne compreniez l'impact de la modification de ces valeurs.

L'exemple suivant remplace le nom de domaine, l'en-tête de l'hôte, le SNI et les certificats autorisés sur la demande par l'origine.

cf.updateRequestOrigin({ "domainName": "www.example.com", "hostHeader": "test.example.com", "sni": "test.example.net", "allowedCertificateNames": ["*.example.com", "*.example.net"], });

selectRequestOriginById() méthode

Utilisez selectRequestOriginById() pour mettre à jour une origine existante en sélectionnant une autre origine déjà configurée dans votre distribution. Cette méthode utilise les mêmes paramètres que ceux définis par l’origine mise à jour.

Cette méthode accepte uniquement les origines déjà définies dans la même distribution que celle utilisée lors de l’exécution de la fonction. Les origines sont référencées par l’ID d’origine, qui est le nom d’origine que vous avez défini lors de la configuration de l’origine.

Si une origine VPC est configurée dans votre distribution, vous pouvez utiliser cette méthode pour mettre à jour votre origine vers votre origine VPC. Pour de plus amples informations, veuillez consulter Restriction de l’accès avec les origines de VPC.

Demande

cf.selectRequestOriginById(origin_id, {origin_overrides})

Dans l'exemple précédent, origin_id il s'agit d'une chaîne qui pointe vers le nom d'origine d'une origine dans la distribution qui exécute la fonction. Le origin_overrides paramètre peut contenir les éléments suivants :

HostHeader (facultatif, pour les origines personnalisées autres que S3)

L'en-tête de l'hôte à utiliser lorsque vous envoyez la demande à l'origine. Si ce n'est pas le cas, la valeur du domainName paramètre est utilisée.

Si aucun en-tête d'hôte ou paramètre de nom de domaine n'est fourni, le nom de domaine de l'origine attribuée est utilisé ou l'en-tête de l'hôte de la demande entrante si la politique de transfert vers l'origine (FTO) inclut l'hôte. L'en-tête de l'hôte ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. L'en-tête de l'hôte peut comporter jusqu'à 253 caractères.

sni (facultatif, pour les origines personnalisées autres que S3)

L'indication du nom du serveur (SNI) est une extension du protocole TLS (Transport Layer Security) par laquelle un client indique le nom d'hôte auquel il tente de se connecter au début du processus de prise de contact TLS. Cette valeur doit correspondre à un nom courant figurant sur un certificat TLS sur votre serveur d'origine. Dans le cas contraire, votre serveur d'origine risque de générer une erreur.

Si ce n'est pas le cas, la valeur du hostHeader paramètre est utilisée. Si l'en-tête de l'hôte n'est pas fourni, la valeur du domainName paramètre est utilisée.

Si aucun en-tête d'hôte ou paramètre de nom de domaine n'est fourni, le nom de domaine de l'origine attribuée est utilisé ou l'en-tête de l'hôte de la demande entrante si la politique de transfert vers l'origine (FTO) inclut l'hôte. Le SNI ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. Le SNI peut comporter jusqu'à 253 caractères.

allowedCertificateNames (facultatif, pour les origines personnalisées autres que S3)

Vous pouvez inclure une liste de noms de certificats valides à utiliser pour valider le domaine correspondant CloudFront au certificat TLS de votre serveur d'origine lors de la prise de contact TLS avec votre serveur d'origine. Ce champ attend un tableau de noms de domaine valides et peut inclure des domaines génériques, tels que*.example.com.

Vous pouvez spécifier jusqu'à 20 noms de certificats autorisés. Chaque nom de certificat peut comporter jusqu'à 64 caractères.

Demande

selectRequestOriginById(origin_id)

Dans l’exemple précédent, origin_id est une chaîne qui fait référence au nom de l’origine dans la distribution où la fonction s’exécute.

Exemple – sélection de l’origine de demande Amazon S3

L’exemple suivant sélectionne l’origine nommée amzn-s3-demo-bucket-in-us-east-1 dans la liste des origines associées à la distribution et applique les paramètres de configuration de l’origine amzn-s3-demo-bucket-in-us-east-1 à la demande.

cf.selectRequestOriginById("amzn-s3-demo-bucket-in-us-east-1");
Exemple – sélection de l’origine de demande Application Load Balancer

L’exemple suivant sélectionne une origine Application Load Balancer nommée myALB-prod dans la liste des origines associées à la distribution et applique les paramètres de configuration de l’origine myALB-prod à la demande.

cf.selectRequestOriginById("myALB-prod");
Exemple — Sélectionnez l'origine de la demande Application Load Balancer et remplacez l'en-tête de l'hôte

Comme dans l'exemple précédent, l'exemple suivant sélectionne une origine Application Load Balancer nommée myALB-prod dans la liste des origines associées à la distribution, et applique les paramètres de configuration de myALB-prod à la demande. Toutefois, cet exemple remplace la valeur de l'en-tête de l'hôte en utilisantorigin_overrides.

cf.overrideRequestOrigin("myALB-prod",{ "hostHeader" : "test.example.com" });

createRequestOriginMéthode Group ()

Utilisez createRequestOriginGroup() pour définir deux origines à utiliser comme groupe d’origines pour le basculement, dans les scénarios nécessitant une haute disponibilité.

Un groupe d’origine comprend deux origines (une origine principale et une origine secondaire), ainsi qu’un critère de basculement que vous spécifiez. Vous créez un groupe d'origine pour prendre en charge le basculement d'origine. CloudFront Lorsque vous créez ou mettez à jour un groupe d'origine à l'aide de cette méthode, vous pouvez spécifier le groupe d'origine au lieu d'une origine unique. CloudFront basculera de l'origine principale vers l'origine secondaire, en utilisant les critères de basculement.

Si une origine VPC est configurée dans votre distribution, vous pouvez utiliser cette méthode pour créer un groupe d’origines à l’aide de votre origine VPC. Pour de plus amples informations, veuillez consulter Restriction de l’accès avec les origines de VPC.

Demande

createRequestOriginGroup({origin_group_properties})

Dans les exemples précédents, origin_group_properties peut contenir les éléments suivants :

originIds (obligatoire)

Tableau de origin_ids, où chaque origin_id est une chaîne qui pointe vers le nom de l’origine dans la distribution exécutant la fonction. Vous devez fournir deux origines dans le tableau. La première origine de la liste est l’origine principale et la seconde sert d’origine secondaire à des fins de basculement.

OriginOverrides (facultatif)

Quelques paramètres avancés peuvent être remplacés à l'aide du {origin_overrides} paramètre. Les origin overrides peuvent contenir les éléments suivants :

HostHeader (facultatif, pour les origines personnalisées autres que S3)

L'en-tête de l'hôte à utiliser lorsque vous envoyez la demande à l'origine. Si ce n'est pas le cas, la valeur du domainName paramètre est utilisée.

Si aucun en-tête d'hôte ou paramètre de nom de domaine n'est fourni, le nom de domaine de l'origine attribuée est utilisé ou l'en-tête de l'hôte de la demande entrante si la politique de transfert vers l'origine (FTO) inclut l'hôte. L'en-tête de l'hôte ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. L'en-tête de l'hôte peut comporter jusqu'à 253 caractères.

sni (facultatif, pour les origines personnalisées autres que S3)

L'indication du nom du serveur (SNI) est une extension du protocole TLS (Transport Layer Security) par laquelle un client indique le nom d'hôte auquel il tente de se connecter au début du processus de prise de contact TLS. Cette valeur doit correspondre à un nom courant figurant sur un certificat TLS sur votre serveur d'origine, sinon celui-ci risque de générer une erreur.

Si ce n'est pas le cas, la valeur du hostHeader paramètre est utilisée. Si l'en-tête de l'hôte n'est pas fourni, la valeur du domainName paramètre est utilisée.

Si aucun en-tête d'hôte ou paramètre de nom de domaine n'est fourni, le nom de domaine de l'origine attribuée est utilisé ou l'en-tête de l'hôte de la demande entrante si la politique de transfert vers l'origine (FTO) inclut l'hôte. Le SNI ne peut pas inclure de deux-points (:) et ne peut pas être une adresse IP. Le SNI peut comporter jusqu'à 253 caractères.

allowedCertificateNames (facultatif, pour les origines personnalisées autres que S3)

Vous pouvez inclure une liste de noms de certificats valides à utiliser pour valider le domaine correspondant CloudFront au certificat TLS de votre serveur d'origine lors de la prise de contact TLS avec votre serveur d'origine. Ce champ attend un tableau de noms de domaine valides et peut inclure des domaines génériques, tels que*.example.com.

Vous pouvez spécifier jusqu'à 20 noms de certificats autorisés. Chaque nom de certificat peut comporter jusqu'à 64 caractères.

selectionCriteria (facultatif)

Sélectionnez si vous souhaitez utiliser les critères de basculement d’origine default ou appliquer la logique de basculement basée sur le media-quality-score. Les valeurs valides sont les suivantes :

  • default utilise les critères de basculement, en fonction des codes d’état spécifiés dans failoverCriteria. Si vous ne définissez pas selectionCriteria dans la fonction, default sera utilisé.

  • media-quality-score est utilisé lorsque la fonctionnalité de routage tenant compte de la qualité média est utilisée.

failoverCriteria (obligatoire)

Ensemble de codes d'état qui, lorsqu'ils sont renvoyés par l'origine principale, CloudFront déclenchent le basculement vers l'origine secondaire. Si vous remplacez un groupe d’origines existant, ce tableau remplacera tous les codes d’état de basculement définis dans la configuration d’origine du groupe d’origines.

Lorsque vous utilisez media-quality-scoreselectionCriteria, CloudFront tentera d'acheminer les demandes en fonction du niveau de qualité du média. Si l'origine sélectionnée renvoie un code d'erreur défini dans ce tableau, elle CloudFront basculera vers l'autre origine.

Exemple – création du groupe d’origines de la demande

L'exemple suivant crée un groupe d'origine pour une demande en utilisant l'origine IDs. Ces origines IDs proviennent de la configuration du groupe d'origine de la distribution utilisée pour exécuter cette fonction.

Vous pouvez éventuellement utiliser originOverrides pour remplacer les configurations du groupe d'origine pour snihostHeader, etallowedCertificateNames.

import cf from 'cloudfront'; function handler(event) { cf.createRequestOriginGroup({ "originIds": [ { "originId": "origin-1", "originOverrides": { "hostHeader": "hostHeader.example.com", "sni": "sni.example.com", "allowedCertificateNames": ["cert1.example.com", "cert2.example.com", "cert3.example.com"] } }, { "originId": "origin-2", "originOverrides": { "hostHeader": "hostHeader2.example.com", "sni": "sni2.example.com", "allowedCertificateNames": ["cert4.example.com", "cert5.example.com"] } } ], "failoverCriteria": { "statusCodes": [500] } }); event.request.headers['x-hookx'] = { value: 'origin-overrides' }; return event.request; }