Amazon Cloudfront avec S3. Accès refusé

Si vous accédez à la racine de votre distribution CloudFront, vous devez définir un objet racine par défaut : http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html

Pour spécifier un objet racine par défaut en utilisant la console CloudFront :

• Connectez-vous à la console de gestion AWS et ouvrez la console Amazon CloudFront à l'adresse https://console.aws.amazon.com/cloudfront/.

• Dans la liste des distributions dans le volet supérieur, sélectionnez la distribution à mettre à jour.

• Dans le volet Détails de la distribution, sur l'onglet Général, cliquez sur Modifier.

• Dans la boîte de dialogue Modifier la distribution, dans le champ Objet racine par défaut, saisissez le nom du fichier de l'objet racine par défaut.

  Saisissez uniquement le nom de l'objet, par exemple, index.html. Ne pas mettre de / avant le nom de l'objet.

• Pour enregistrer vos modifications, cliquez sur Oui, Modifier.

Je viens d'avoir le même problème et bien que la réponse de Kousha résolve le problème pour index.html dans le chemin racine, mon problème était également avec les sous-répertoires car j'utilisais ceux-ci combinés avec index.html pour obtenir des "jolis urls" (example.com/something/ au lieu de "moche" example.com/something.html)

Partiellement, c'est aussi la faute d'Amazon, car lorsque vous configurez une distribution CloudFront, il vous proposera des buckets S3 à choisir, mais si vous en choisissez un, il utilisera l'URL du bucket plutôt que l'URL d'hébergement du site statique en tant que backend.

Donc pour résoudre le problème :

• Activez l'hébergement de site web statique pour le bucket
• Définissez le document Index (et peut-être Error) correctement
• Copiez l'URL Endpoint - vous pouvez le trouver à côté des paramètres ci-dessus - Elle devrait ressembler à quelque chose comme : .s3-website-.amazonaws.com
• Utilisez cette URL comme origine de la distribution CloudFront. (Cela rendra également le paramètre de Default Root Object de CF inutile, mais cela ne fait pas de mal de le définir de toute façon)

MISE À JOUR Jan '22 : vous pouvez également résoudre ce problème en laissant l'hébergement statique INACTIF et en ajoutant une fonction CloudFront pour ajouter index.html. Voir ce post sur SO pour plus d'informations. Cela vous permet d'utiliser un OAI et de garder le bucket privé.

J'ai eu le même problème que @Cezz, bien que la solution ne fonctionnerait pas dans mon cas.

Dès que l'hébergement de site Web statique est activé pour le bucket, cela signifie que les utilisateurs peuvent accéder au contenu soit via l'URL Cloudfront, soit via l'URL S3, ce qui n'est pas toujours souhaitable. Par exemple, dans mon cas, la distribution Cloudfront est SSL activé, et les utilisateurs ne devraient pas pouvoir y accéder via une connexion non-SSL.

La solution que j'ai trouvée était de :

• garder l'hébergement de site Web statique désactivé sur le bucket S3
• garder l'origine de la distribution Cloudfront comme un ID S3
• définir "Restrict Bucket Access" sur "Oui" (et pour plus de facilité, autoriser CloudFront à mettre à jour automatiquement la stratégie du bucket)
• dans "Error Pages", créer une réponse personnalisée, et mapper le code d'erreur "403: Interdit" à la page de réponse souhaitée, c'est-à-dire /index.html, avec un code de réponse de 200

Notez cependant que dans mon cas, je sers une application JavaScript d'une seule page où tous les chemins sont résolus par index.html. Si vous avez des chemins qui se résolvent à différents objets dans votre bucket S3, cela ne fonctionnera pas.

Dans mon cas, j'utilisais plusieurs origines avec des comportements "Modèle de chemin" ainsi qu'un chemin d'origine dans mon compartiment S3 :

Mauvaise configuration :

Comportement CloudFront : /images/* -> Mon-origine-S3

Mon-origine-S3 : Chemin d'origine : /images

Fichiers S3 : /images/my-image.jpg

Requête GET : /images/my-image.jpg -> 403

Ce qui se passait, c'est que la requête GET entière de CloudFront était envoyée à l'origine : /image/my-image.jpg précédée du chemin d'origine : /images, donc la requête vers S3 ressemblait à /images/images/my-image.jpg qui n'existe pas.

Solution

Supprimer le chemin d'origine.

Cela m'a permis d'accéder au compartiment avec une identité d'accès à l'origine et des autorisations de compartiment et des autorisations de fichier individuelles restreintes.

Dans mon cas, j'avais configuré Route 53 de manière incorrecte. J'avais créé un Alias sur mon domaine mais je l'avais pointé vers le compartiment S3 au lieu de la distribution CloudFront.

De plus, j'avais omis l'objet racine par défaut. La console pourrait vraiment être améliorée si elle ajoutait un peu d'information au texte du point d'interrogation sur les conséquences potentielles de son omission.