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.
Dans le Gestionnaire de certificats, cliquez sur le bouton Demander un certificat.
Sur la page suivante, 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.
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.
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.
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.
Sur la page Vérifier, cliquez sur le bouton Confirmer et demander pour passer à l’étape de validation.
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.
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.
- Cliquez sur DNS dans la colonne de navigation latérale gauche dans MyKinsta.
- Cliquez sur le lien Gérer pour le domaine auquel vous voulez ajouter un enregistrement DNS.
- Cliquez sur le bouton Ajouter un enregistrement DNS.
- 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.
Retournez à la page de validation de CloudFront et cliquez sur Continuer.
Une fois que l’enregistrement CNAME se propage et a été validé, le statut du certificat SSL passera de En attente à Émis.
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.
Ensuite, cliquez sur Créer 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.
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).
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.
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.
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.
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.
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.
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.
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é
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 :
- Extensions (le cas échéant)
- Thèmes (le cas échéant)
- Cache du site/serveur chez Kinsta (depuis MyKinsta ou le plugin Kinsta MU)
- Cache chez CloudFront (Faites-le en invalidant des objets. L’utilisation de /* pour le chemin de l’objet à invalider effacera tout le cache)
- 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.