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 montre comment faire.
Parmi les caractéristiques de sécurité de CloudFront figurent le cryptage au niveau du champ et la protection contre les attaques DDoS au niveau du réseau et de l’application.
Demander un certificat SSL personnalisé
Une partie de la configuration de votre distribution Cloudfront comprend l’application d’un certificat SSL personnalisé. Comme cette opération 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 connecté à votre compte AWS, recherchez « certificate manager » dans le champ de recherche de la barre de menu, puis cliquez sur Certificate Manager dans la rubrique Services.
Dans le Gestionnaire de certificats, cliquez sur Demander un certificat.
Sur la page suivante, sélectionnez Demander un certificat public et cliquez sur Suivant.
Remplissez le formulaire de demande de certificat public comme ceci :
- Noms de domaine : 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).
- Méthode de validation : choisissez la validation par e-mail ou par DNS pour votre certificat SSL. Si votre enregistrement de domaine ne dispose pas d’une protection de la vie privée qui masque vos coordonnées aux recherches WHOIS, ou si l’e-mail envoyé à l’adresse e-mail du proxy est transféré à votre adresse e-mail réelle, vous pouvez utiliser la méthode de validation par e-mail pour valider votre demande de certificat. 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 compléter la validation. Si vous ne pouvez pas recevoir d’e-mails à l’adresse indiquée dans les recherches WHOIS, vous devrez utiliser la méthode de validation DNS.
- Algorithme de clé : sélectionnez RSA 2048.
- Balises : ajoutez des balises optionnelles si nécessaire.
Cliquez sur Demander pour passer à l’étape de validation.
La section Domaines montre les détails 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 le DNS de votre domaine. Pour cet exemple, nous vous montrerons comment ajouter l’enregistrement CNAME dans le DNS de Kinsta. Si vous avez un fournisseur de DNS différent (il peut s’agir de votre registraire ou d’un autre hébergeur DNS, selon l’endroit où vous avez pointé les serveurs de noms de votre domaine), les étapes peuvent être légèrement différentes.
- Cliquez sur Gestion DNS puis sur Gérer pour le domaine auquel vous souhaitez ajouter un enregistrement DNS.
- Cliquez sur Ajouter un enregistrement DNS, sélectionnez l’onglet CNAME et procédez comme ceci :
- Nom d’hôte : utilisez le nom CNAME de CloudFront.
- Pointer vers : utilisez la valeur CNAME de CloudFront
- Cliquez sur Ajouter un enregistrement DNS.
Remarque : selon le réglage TTL de votre enregistrement DNS, la propagation de l’enregistrement DNS peut prendre de quelques minutes à quelques heures.
Une fois que l’enregistrement CNAME s’est propagé et a été validé, le statut du certificat SSL passe de En attente à Délivré.
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 dans le champ de recherche de la barre de menu, puis cliquez sur CloudFront dans la rubrique Services.
Dans Distributions, cliquez sur Créer une distribution.
Vous pouvez configurer les détails d’une nouvelle zone CloudFront sur la page Créer une distribution. Nous recommandons la configuration suivante pour une compatibilité maximale avec l’intégration Cloudflare de Kinsta :
Options de distribution
Sélectionnez Site web ou application unique.
Origine
Réglages d’origine recommandés :
- Domaine d’origine: Le domaine principal de votre site (dans notre exemple : brownbearcentral.com). CloudFront n’accepte pas d’adresse IP comme origine, vous devez donc utiliser le domaine primaire 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 minimale : TLSv1.2
Remarque : Kinsta utilise actuellement TLS v1.3 pour tous les certificats SSL, ce qui garantit une sécurité élevée et la compatibilité avec tous les principaux navigateurs. Puisque ce paramètre est la version minimale de TLS, TLS v1.2 est suffisant pour la compatibilité avec Kinsta. Si vous avez spécifiquement besoin de TLS v1.2, veuillez contacter notre équipe de support pour obtenir de l’aide.
- Chemin d’origine : laissez ce champ vide.
- Nom : vous pouvez saisir ici un nom personnalisé pour l’origine, 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 vous présentons ci-dessous.
Réglages recommandés pour la section Comportement du cache par défaut:
- Modèle de chemin : par défaut (*).
- Compresser les objets automatiquement : 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 du spectateur : 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 cache CloudFront
Dans la section Politique de cache, cliquez sur Créer une politique de cache. La page de création de la politique de cache s’ouvrira dans un nouvel onglet de votre navigateur.
Dans la section Détails, spécifiez 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 : Toutes
- Cookies : Tous
Dans la section Support de compression, sélectionnez Gzip et Brotli, puis cliquez sur Créer.
Fermez cet onglet du navigateur et revenez à l’onglet dans lequel 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 de demande d’origine CloudFront
Dans la section Politique de demande d’origine, cliquez sur Créer une politique de demande d’origine. La page Créer une politique de demande d’origine s’ouvrira dans un nouvel onglet de votre navigateur.
Dans la section Détails, spécifiez un nom (par exemple KinstaOriginPolicy) pour la politique de demande d’origine.
Dans la section Origin request settings, sélectionnez les éléments suivants :
- En-têtes : tous les en-têtes de la visionneuse
- Chaînes de requête: toutes
- Cookies : tous
Cliquez sur Créer pour finaliser la politique de requête.
Fermez cet onglet du navigateur et revenez à l’onglet dans lequel vous créez votre nouvelle distribution CloudFront.
Cliquez sur le bouton d’actualisation à côté de la liste déroulante Politique de demande d’origine 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 AWS Lambda serverless à différents déclencheurs dans le cycle de vie de la demande (par exemple, demande de spectateur, réponse du spectateur, demande d’origine, 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 dans lesquels 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 s’ils surviennent.
Pare-feu d’application web (WAF)
Sélectionnez l’option souhaitée. Si vous activez les protections de sécurité, cela entraîne un coût supplémentaire de la part d’AWS.
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.
- Nom de domaine alternatif : cliquez sur Ajouter un élément et indiquez le domaine personnalisé (le domaine principal de votre site sur 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é :- Legacy clients support : laissez cette option décochée/désactivée.
- Politique de sécurité : TLSv1.2_2021
- Versions HTTP prises en charge : HTTP/2
- IPv6 : activé
Journalisation standard
Ce réglage doit être désactivé.
Cliquez sur Créer une 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 paramètres d’origine. Il doit s’agir du domaine kinsta.cloud de votre site, et non de votre domaine réel.
Les modifications n’apparaissent pas sur votre site
Configurer votre site pour utiliser CloudFront crée une couche supplémentaire de cache qui devra être vidée à chaque fois que vous aurez besoin de vider le cache. Si vous avez du mal à 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 :
- Les extensions (le cas échéant)
- Les thèmes (le cas échéant)
- Le cache du site/serveur de Kinsta (à partir de MyKinsta ou de l’extension Kinsta MU)
- Cache chez CloudFront (Faites-le en invalidant les 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é la mitigation DDoS ou la détection des robots sur CloudFront et que vous ou un visiteur de votre site êtes bloqués de manière incorrecte, 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 Only dans les réglages de CloudFront Origin pour votre domaine.
Les redirections par 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 mise en 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 le 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 du cache par défaut sont définies sur GET, HEAD, OPTIONS, PUT, POST, PATCH, et DELETE.
Réglages avancés et compatibilité
Restreindre l’accès des visiteurs à l’aide d’URL et de cookies signés
Certaines options, telles que Restreindre l’accès aux fichiers sur des origines personnalisées, peuvent ne pas fonctionner car Cloudflare met toujours en cache les requêtes statiques.