Un développeur héberge un site web statique dans un compartiment S3 servi via CloudFront en utilisant le contrôle d'accès à l'origine (OAC) afin que le compartiment ne soit pas public. Les utilisateurs peuvent accéder à des URL de fichiers explicites (par exemple, /products/index.html) mais reçoivent une erreur lorsqu'ils demandent des URL de répertoires (par exemple, /products/). Sans rendre le compartiment S3 public, comment les requêtes de répertoire peuvent-elles être servies de manière à renvoyer le fichier d'index par défaut ?

La création d'une fonction CloudFront viewer-request est la solution la plus appropriée car elle permet de réécrire l'URL avant que CloudFront ne mette en cache la requête ou ne la transmette à l'origine. Cette fonction peut détecter les requêtes de répertoire (se terminant par un slash) et ajouter automatiquement index.html à l'URL, garantissant ainsi que le fichier d'index par défaut est servi sans exposer le compartiment S3. Modifier l'objet racine par défaut de la distribution CloudFront en index.html ne fonctionne que pour la racine de la distribution (par exemple, example.com/), pas pour les sous-répertoires (par exemple, example.com/products/). Activer l'hébergement de site web statique S3 et modifier l'origine CloudFront vers le point de terminaison du site web S3 est une solution viable, mais elle nécessite de rendre le compartiment S3 public, ce que la question cherche à éviter. De plus, l'OAC est conçu pour fonctionner avec des compartiments S3 privés. Configurer une réponse d'erreur personnalisée pour 404 ne gère pas le cas où l'utilisateur demande un répertoire et s'attend à un fichier d'index. Cela ne ferait que rediriger toutes les erreurs 404 vers index.html, ce qui n'est pas le comportement souhaité.