Meilleure façon de gérer le site Web Cloudfront/S3 avec www redirigé vers le domaine nu

Question

J'ai un site Web que je voudrais que la version préfixée www rediriger vers le domaine nu.

Après avoir cherché différentes solutions, j'ai trouvé ce sujet fermé ici avec cette réponse qui semble fonctionner à merveille: https://stackoverflow.com/a/42869783/8406990

Cependant, j'ai un problème où, si je mets à jour l'objet racine « index/html » dans mon S3, il peut prendre un jour avant que Cloudfront ne serve la nouvelle version. J'ai même manuellement invalidé le fichier, et tandis que cela met à jour le fichier "index.html" correctement, Cloudfront sert toujours l'ancien.

Pour mieux expliquer, si je tape: http://mywebsite.com/index.html, il servira la nouvelle version. Mais si je tape http://mywebsite.com/, il sert l'ancien index.html. Je suis allé de l'avant et ajouté "index.html" dans la propriété d'objet racine par défaut de ma distribution Cloudfront (pour le domaine nu), et il a immédiatement fonctionné comme je le voulais. Taper juste dans le domaine (sans ajouter /index.html) a retourné la nouvelle version. Cependant, ceci est en contraste avec la réponse dans le thread que je viens de lier, qui indique explicitement NE PAS définir un "objet racine par défaut" lorsque vous utilisez deux distributions pour effectuer la redirection. J'espérais acquérir une meilleure compréhension de cet "objet racine par défaut", et s'il y avait une meilleure façon de s'assurer que l'objet racine met à jour la version en cache correctement?

Merci.

Answer 1

Si vous avez vraiment mis index.html/ comme objet racine par défaut et votre distribution CloudFront pointe vers le point final d'hébergement de site Web du seau et cela a fonctionné, alors vous étiez presque certainement servirez un objet dans votre seau appelé index. html/qui apparaîtrait dans votre compartiment en tant que dossier, ou un objet nommé index.html dans un dossier nommé index.html. La barre oblique ne fait pas partie de la nouveauté. Cela pourrait expliquer le comportement étrange. Mais cela pourrait aussi être une faute de frappe dans votre question. Il est important de noter que CloudFront a pour objectif de minimiser les requêtes vers le serveur principal et de conserver les copies mises en cache dans des emplacements géographiquement proches de ceux où elles sont fréquemment demandées. La mise à jour d'un objet dans S3 n'est pas conçu pour mettre à jour ce que CloudFront sert immédiatement, sauf si vous l'avez configuré pour le faire. Une façon de le faire est de définir (par exemple) Cache-Control: public, max-age=600 sur les métadonnées de l'objet lorsque vous l'enregistrez dans S3. Cela indiquerait à CloudFront de ne jamais diffuser une copie en cache de l'objet obtenu à partir de S3 il y a plus de 600 secondes (10 minutes). Si vous ne le définissez pas, CloudFront ne reviendra pas par défaut pendant 24 heures (le «TTL par défaut»).

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

Cela ne fonctionne que dans un sens - il dit CloudFront combien de temps il est permis de conserver une copie en cache sans vérifier les mises à jour. Il ne dit pas à CloudFront que doit attendre aussi longtemps avant de vérifier. Les objets qui sont rarement demandés peuvent être libérés par CloudFront avant leur expiration. La requête suivante extrait une nouvelle copie de S3.

Si vous devez effacer immédiatement un objet du cache de CloudFront, cela s'appelle un cache invalidation. Ceux-ci sont facturés 0 $.005 pour chaque chemin (pas tous les fichier) que vous demandez être invalidé, mais les 1 000 premiers par mois par compte AWS sont facturés à 0,00 $. Vous pouvez invalider tous vos fichiers en demandant une invalidation pour /*. Cela laisse S3 intacte, mais CloudFront rejette tout ce qu'il cache avant la demande d'invalidation.

L'objet racine par défaut est une fonctionnalité héritée qui n'est plus généralement nécessaire depuis que S3 a introduit des compartiments d'hébergement de sites Web statiques. Avant cela - et encore, si vous pointez CloudFront sur le point de terminaison REST pour le bucket - quelqu'un frappant la racine de votre site Web verrait une liste de tous vos objets. Évidemment, c'est presque toujours indésirable, donc l'objet racine par défaut vous a permis de remplacer une page différente à la racine du site. Avec l'hébergement statique dans S3, vous avez des documents d'index, qui fonctionnent dans n'importe quel "répertoire" de votre site, rendant l'option CloudFront - qui ne fonctionne qu'à la racine du site, pas n'importe où un document d'index est disponible. Il est donc relativement rare d'utiliser cette fonctionnalité, maintenant.