Amazon CloudFront

Amazon CloudFront est un réseau de diffusion de contenu sécurisé et programmable. Une fois que vous avez lancé votre site sur Kinsta, si vous souhaitez utiliser Amazon CloudFront au lieu du CDN de Kinsta, ce guide vous expose la marche à suivre.

Certaines des caractéristiques de sécurité de CloudFront comprennent le cryptage au niveau du champ et la protection contre les attaques DDoS au niveau du réseau et de la couche application.

Demander un certificat SSL personnalisé

Une partie de la configuration de votre distribution Cloudfront comprend l’application d’un certificat SSL personnalisé. Comme cela peut prendre de quelques minutes à plusieurs heures, nous vous recommandons de demander le certificat SSL personnalisé avant de commencer le processus de création d’une nouvelle distribution.

Si vous n’avez pas encore de compte AWS, vous pouvez en créer un ici. Une fois que vous vous êtes connecté à votre compte AWS, recherchez « certificate manager » à l’aide de la boîte de recherche dans la barre de menu, et cliquez sur Certificate Manager sous Services.

Cliquez sur Certificate Manager sous Services dans votre compte CloudFront
Cliquez sur Certificate Manager sous Services dans votre compte CloudFront.

Dans le Gestionnaire de certificats, cliquez sur le bouton Demander un certificat.

Cliquez sur le bouton Demander un certificat dans le gestionnaire de certificats AWS.
Cliquez sur le bouton Demander un certificat dans le gestionnaire de certificats AWS.

Sur la page suivante, sélectionnez Demander un certificat public et cliquez sur le bouton Demander un certificat.

Sélectionnez Demander un certificat public
Sélectionnez Demander un certificat public et cliquez sur le bouton Demander un certificat

Ajouter des noms de domaine

Dans le formulaire Demander un certificat, ajoutez votre domaine personnalisé (le domaine primaire de votre site chez Kinsta) à la liste des noms de domaine (si vous ajoutez un domaine racine, assurez-vous d’ajouter à la fois le domaine non-www et www ou ajoutez le domaine wildcard comme *.exemple.com), et cliquez sur Suivant.

Ajoutez votre domaine personnalisé à la demande de certificat SSL dans AWS Certificate Manager
Ajoutez votre domaine personnalisé à la demande de certificat SSL dans AWS Certificate Manager

Validation du domaine

Sur l’écran suivant, vous choisirez la validation par e-mail ou par DNS pour votre certificat SSL. Choisissez l’option qui vous convient le mieux.

Si l’enregistrement de votre domaine ne dispose pas d’une protection de confidentialité qui masque vos coordonnées aux recherches WHOIS, ou si les e-mails envoyés à l’adresse e-mail du proxy sont transférés à votre adresse e-mail réelle, vous pouvez utiliser la méthode de validation par e-mail pour valider votre demande de certificat.

Si vous ne pouvez pas recevoir d’e-mails à l’adresse indiquée dans les recherches WHOIS, vous devez utiliser la méthode de validation DNS.

Validation par e-mail

Sélectionnez Validation par e-mail et cliquez sur le bouton Suivant pour lancer la validation de l’e-mail.

Lancement de la validation d'e-mail pour le certificat SSL AWS
Lancement de la validation d’e-mail pour le certificat SSL AWS

Vous recevrez jusqu’à 8 e-mails pour chaque domaine que vous avez ajouté au certificat, et vous devrez agir sur au moins un e-mail pour chaque domaine afin de terminer la validation.

Validation DNS

Pour utiliser cette méthode, sélectionnez la méthode de validation DNS et cliquez sur le bouton Suivant.

Validation DNS du Gestionnaire de certificats Amazon pour un certificat SSL
Validation DNS du Gestionnaire de certificats Amazon pour un certificat SSL

Sur la page Ajouter des étiquettes, n’hésitez pas à ajouter quelques étiquettes facultatives si nécessaire, et cliquez sur Vérifier pour passer à l’étape suivante.

Vérifiez la demande de certificat SSL.
Vérifiez la demande de certificat SSL.

Sur la page Vérifier, cliquez sur le bouton Confirmer et demander pour passer à l’étape de validation.

Confirmez la demande de certificat SSL.
Confirmez la demande de certificat SSL.

Sur la page suivante, cliquez sur l’icône de la flèche à côté de votre nom de domaine personnalisé pour afficher les détails du CNAME pour la validation. Vous devrez créer un enregistrement CNAME pour votre domaine personnalisé avec ces détails.

Détails de l'enregistrement CNAME pour la validation du domaine.
Détails de l’enregistrement CNAME pour la validation du domaine.

Pour ajouter ce nouvel enregistrement CNAME, connectez-vous à l’endroit où vous gérez les DNS de votre domaine. Pour cet exemple, nous allons vous montrer comment ajouter l’enregistrement CNAME dans le DNS de Kinsta. Si vous avez un fournisseur DNS différent (il peut s’agir de votre registraire ou d’un autre hôte DNS, selon l’endroit où vous avez pointé les serveurs de noms de votre domaine), les étapes peuvent être un peu différentes.

  1. Cliquez sur DNS dans la colonne de navigation latérale gauche dans MyKinsta.
  2. Cliquez sur le lien Gérer pour le domaine auquel vous voulez ajouter un enregistrement DNS.
  3. Cliquez sur le bouton Ajouter un enregistrement DNS.
  4. Cliquez sur l’onglet CNAME et ajoutez le nom d’hôte (tout ce qui précède votre domaine personnalisé dans le champ Nom de CloudFront) et Poiner verso (Valeur de CloudFront). Cliquez sur le bouton Ajouter un enregistrement DNS pour enregistrer votre nouvel enregistrement CNAME.

Remarque : selon le paramètre TTL de votre enregistrement DNS, la propagation de l’enregistrement DNS peut prendre de quelques minutes à quelques heures.

Ajouter un enregistrement CNAME pour la validation SSL AWS
Ajouter un enregistrement CNAME pour la validation SSL AWS

Retournez à la page de validation de CloudFront et cliquez sur Continuer.

Continuez la validation DNS.
Continuez la validation DNS.

Une fois que l’enregistrement CNAME se propage et a été validé, le statut du certificat SSL passera de En attente à Émis.

Certificat SSL émis dans Amazon Certificate Manager.
Certificat SSL émis dans Amazon Certificate Manager.

Votre nouveau certificat SSL est prêt à être utilisé avec votre nouvelle distribution CloudFront, et vous pouvez commencer à le configurer maintenant.

Configurer et déployer la zone CloudFront

L’étape suivante consiste à configurer et déployer une zone CloudFront. Dans votre compte AWS, recherchez CloudFront à l’aide de la boîte de recherche dans la barre de menu, et cliquez sur CloudFront sous Services.

Sélectionnez CloudFront sous Services dans AWS.
Sélectionnez CloudFront sous Services dans AWS.

Ensuite, cliquez sur Créer une distribution CloudFront.

Créez une distribution CloudFront.
Créez une distribution CloudFront.

Vous pouvez configurer les détails d’une nouvelle zone CloudFront sur la page Créer une distribution. Nous recommandons la configuration ci-dessous pour une compatibilité maximale avec l’intégration Cloudflare de Kinsta.

Origine

Réglages d’origine recommandés :

  • Domaine d’origine : Le domaine kinsta.cloud de votre site (dans notre exemple ici : monsupersite.kinsta.cloud). CloudFront n’accepte pas une adresse IP comme origine, vous devez donc utiliser le domaine kinsta.cloud de votre site dans ce champ.
    Les 3 champs suivants apparaissent une fois que vous avez saisi votre domaine d’origine :
    • Protocole : HTTPS uniquement
    • Port HTTPS : 443
    • Protocole SSL d’origine minimum : TLSv1
  • Chemin d’origine : Laissez ce champ vide.
  • Nom (facultatif) : Vous pouvez saisir un nom personnalisé pour l’origine ici, mais ce n’est pas obligatoire.
  • Activer le bouclier d’origine : Non.
Réglages d'origine recommandés pour la distribution CloudFront.
Réglages d’origine recommandés pour la distribution CloudFront.

Comportement du cache par défaut

Lors de la configuration des réglages de comportement du cache, vous devrez créer deux politiques CloudFront : la politique de cache et la politique de requête, que nous avons décrites pour vous ci-dessous.

Paramètres recommandés pour la section Comportement par défaut du cache:

  • Modèle de chemin : Par défaut.
  • Compresser automatiquement les objets : Oui.
  • Politique de protocole de visualisation : Rediriger HTTP vers HTTPS.
  • Méthodes HTTP autorisées : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE.
  • Restreindre l’accès au visualiseur : Non.
  • Clé de cache et demandes d’origine : Politique de mise en cache et politique de demande d’origine.
    • Politique de cache : Sélectionnez votre nouvelle politique de cache personnalisée (voir les étapes de création ci-dessous).
    • Politique de demande d’origine : Sélectionnez votre nouvelle politique de demande d’origine personnalisée (voir les étapes de création ci-dessous).
Réglages recommandés pour le comportement du cache pour la distribution CloudFront.
Réglages recommandés pour le comportement du cache pour la distribution CloudFront.

Comment créer une politique de mise en cache CloudFront

Dans la section Politique de mise en cache, cliquez sur Créer une politique. Cela lancera la page de création de la politique de mise en cache dans un nouvel onglet de votre navigateur.

Créer une politique de cache dans CloudFront
Créer une politique de cache dans CloudFront

Dans la section Détails, indiquez un nom (par exemple, KinstaCachePolicy) pour la politique de cache.
Dans la section Réglages TTL, utilisez les réglages suivants :

  • TTL minimum : 0
  • TTL maximum : 31536000
  • TTL par défaut : 86400

Dans la section Réglages de la clé de cache, utilisez les réglages suivants :

  • En-têtes : Aucun
  • Chaînes de requête : Tous
  • Cookies : Tous

Dans la section Support de compression, cochez Gzip et Brotli, puis appuyez sur le bouton Créer.

Réglages de politique de cache recommandés dans CloudFront.
Réglages de politique de cache recommandés dans CloudFront.

Fermez cet onglet du navigateur et revenez à l’onglet où vous créez votre nouvelle distribution CloudFront.

Cliquez sur le bouton d’actualisation à côté de la liste déroulante de la politique de cache et sélectionnez votre nouvelle politique de cache personnalisée dans la liste déroulante.

Sélectionnez votre politique de cache personnalisée.
Sélectionnez votre politique de cache personnalisée.

Comment créer une politique d’origine de requête CloudFront

Dans la section Politique d’origine de requête, cliquez sur Créer une politique. Cela lancera la page Créer une politique d’origine de requête dans un nouvel onglet de votre navigateur.

Créer une politique de demande d'origine dans CloudFront.
Créer une politique de demande d’origine dans CloudFront.

Dans la section Détails, indiquez un nom (par exemple, KinstaOriginPolicy) pour la politique d’origine de requête.

Dans la section Paramètres d’origine de requête, sélectionnez les éléments suivants :

  • En-têtes : Tous les en-têtes de visualisation
  • Chaînes de requête : Toutes
  • Cookies : Tous

Cliquez sur le bouton Créer pour finaliser la politique d’origine de requête.

Réglages de la politique d'origine de requête de CloudFront.
Réglages de la politique d’origine de requête de CloudFront.

Fermez cet onglet du navigateur et revenez à l’onglet où vous créez votre nouvelle distribution CloudFront.

Cliquez sur le bouton d’actualisation à côté de la liste déroulante Politique d’origine de requête et sélectionnez votre nouvelle politique de demande d’origine personnalisée dans la liste déroulante.

Sélectionnez votre politique de demande d'origine personnalisée dans la liste déroulante Politique d'origine de requête.
Sélectionnez votre politique de demande d’origine personnalisée dans la liste déroulante Politique d’origine de requête.

Associations de fonctions

Nous vous recommandons de ne pas définir d’associations de fonctions. Celles-ci vous permettent d’affecter des fonctions serverless AWS Lambda à différents déclencheurs dans le cycle de vie de la requête (par exemple, demande de visualisation, réponse de visualisation, origine de requête, etc.)

Bien qu’il soit possible d’utiliser des associations de fonctions parallèlement au CDN de Kinsta, il peut y avoir certains scénarios où une fonction Lambda peut entrer en conflit avec le CDN de Kinsta. Si vous souhaitez utiliser des fonctions Lambda personnalisées sur votre site, nous vous recommandons de travailler avec un développeur pour résoudre les problèmes éventuels.

Réglages

Configuration recommandée pour la section Réglages :

  • Classe de prix : Sélectionnez les régions CloudFront que vous souhaitez utiliser avec votre site.
  • AWS WAF Web ACL : Si vous devez créer une ACL avec des règles de pare-feu personnalisées, nous vous recommandons de travailler avec un expert AWS pour éviter les conflits avec le CDN de Kinsta.
  • Nom de domaine alternatif : Cliquez sur Ajouter un élément et spécifiez le domaine personnalisé (le domaine primaire de votre site chez Kinsta).
  • Certificat SSL personnalisé : Sélectionnez le certificat SSL personnalisé que vous avez créé au début de ce tutoriel.
    Vous verrez quelques options supplémentaires après avoir sélectionné le certificat SSL personnalisé :
    • Prise en charge des clients hérités : Laissez cette option non cochée/désactivée.
    • Politique de sécurité : TLSv1.2_2021
  • Versions HTTP prises en charge : HTTP/2
  • Journalisation standard : Désactivée
  • IPv6 : Activé
Enregistrez les réglages les paramètres de distribution pour créer votre nouvelle zone CloudFront.
Enregistrez les réglages les paramètres de distribution pour créer votre nouvelle zone CloudFront.

Cliquez sur le bouton Créer la distribution pour terminer la création de votre nouvelle zone CloudFront.

Dépannage des problèmes courants de CloudFront

Erreurs 502

Si vous voyez des erreurs 502 sur votre site après avoir créé votre distribution CloudFront, vérifiez à nouveau le domaine d’origine dans vos réglages d’origine. Il doit s’agir du domaine kinsta.cloud de votre site, et non de votre domaine réel.

Les modifications ne s’affichent pas sur votre site

La configuration de votre site pour utiliser CloudFront crée une couche supplémentaire de mise en cache qui devra être effacée à chaque fois que vous devrez vider le cache. Si vous avez des difficultés à voir les changements sur votre site ou si une extension ne se comporte pas comme prévu après l’installation ou la réinstallation, assurez-vous de vider le cache à tous les niveaux, y compris :

  1. Extensions (le cas échéant)
  2. Thèmes (le cas échéant)
  3. Cache du site/serveur chez Kinsta (depuis MyKinsta ou le plugin Kinsta MU)
  4. Cache chez CloudFront (Faites-le en invalidant des objets. L’utilisation de /* pour le chemin de l’objet à invalider effacera tout le cache)
  5. Cache du navigateur

Adresse IP bloquée par un faux positif

Si vous avez activé l’atténuation DDoS ou la détection des robots sur CloudFront et que vous ou un visiteur de votre site êtes bloqué à tort, cela peut être dû à un faux positif. Dans ce cas, vous devrez travailler avec le support AWS et le support Kinsta pour déterminer l’endroit où le blocage se produit.

Boucles de redirection HTTP-HTTPS

Si des boucles de redirection HTTP vers HTTPS se produisent, assurez-vous que le protocole est défini sur HTTPS uniquement dans les réglages de votre origine CloudFront pour votre domaine.

Les redirections de géolocalisation IP ne fonctionnent pas correctement

Page Cache, qui est activé par défaut sur CloudFront, peut interférer avec les redirections de géolocalisation IP que vous avez définies sur Kinsta. Si cela se produit, vous devrez désactiver la mise en cache chez CloudFront ou configurer votre politique de cache pour ne mettre en cache que les fichiers qui ne sont pas spécifiques à un emplacement. Si vous rencontrez des problèmes pour configurer cela, nous vous recommandons de travailler avec un développeur pour configurer votre politique de cache personnalisée.

Impossible de se connecter au tableau de bord de WordPress

La connexion ne fonctionnera pas sans support POST. D’autres fonctionnalités du site web peuvent également être affectées. Assurez-vous que les méthodes HTTP autorisées sous Comportement par défaut du cache sont définies sur : GET, HEAD, OPTIONS, PUT, POST, PATCH, et DELETE.

Réglages avancés et compatibilité

Restreindre l’accès des spectateurs avec des URL signées et des cookies signés

Certaines options, telles que Restreindre l’accès aux fichiers sur les origines personnalisées, peuvent ne pas fonctionner car Cloudflare mettra toujours en cache les requêtes statiques.

Cet article vous a été utile ?