CloudFront + S3 Website: "Указанный ключ не существует", когда должен отображаться неявный индексный документ

Я только что установил статический веб-сайт в Amazon S3, который можно просмотреть здесь: http://www.rdegges.com.s3-website-us-east-1.amazonaws.com/

Если вы нажмете любую ссылку на статью, вы заметите следующую ошибку:

S3 Ошибка

S3 жалуется, что файл не существует. Теперь, вот что странно об этом - я использую CloudFront в своем домене. Поэтому, когда вы нажимаете ссылку на эту статью, она отправляет запрос CloudFront, который затем пытается извлечь файл из ведра S3.

Однако, если вы сразу заходите на тот же URL-адрес из S3, например: http://www.rdegges.com.s3-website-us-east-1.amazonaws.com/2015/building-a-heroku-addon-planning/, страница будет загружаться просто отлично.

Похоже, что здесь что-то теряется в переводе.

Кто-нибудь получил предложение о том, что я могу сделать, чтобы исправить мои настройки?

ОТВЕТЫ

Ответ 1

Я выйду на конечность и скажу, что указанный ключ технически не существует, поэтому сообщение об ошибке является технически точным, но не рассказывает всю историю. Это должно быть легко исправить.

S3-контейнеры имеют две конечные точки: "REST" и "веб-сайт". У них есть два разных набора функций. Конечная точка веб-сайта обеспечивает магическое разрешение индексных документов (например, index.html, который, по-видимому, и должен быть возвращен браузеру в приведенном вами примере), а конечные точки REST - нет.

Когда вы настраиваете CloudFront перед корзиной, используемой для размещения веб-сайтов, вы обычно не хотите настраивать источник как источник "S3", выбирая имя корзины из раскрывающегося списка; вместо этого вы хотите настроить его как "пользовательский" источник и использовать имя хоста конечной точки веб-сайта, как указано в консоли S3 (например, example-bucket.s3-website-us-east-1...), потому что в противном случае CloudFront Предполагается, что вы хотите, чтобы он использовал конечную точку REST для сегмента (который разрешает аутентификацию и закрытый контент, чего нет у конечной точки веб-сайта).

Важный

Не выбирайте название вашего ведра из списка, например, example.com.s3.amazonaws.com.

http://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-create-cfdist.html

Документация была реорганизована с тех пор, как на этот вопрос первоначально был дан ответ, поэтому показанное выше сообщение теперь появляется на одну страницу позже и было перефразировано, но суть та же. "Название корзины", по-видимому, относится к вариантам, показанным в раскрывающемся списке, что не является тем, что вам нужно.

Заметка

Обязательно укажите статическую конечную точку хостинга веб-сайта, а не имя корзины.

http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-cloudfront-walkthrough.html

Намек на то, что вы используете конечную точку REST для сегмента, заключается в том, что сообщение об ошибке не было бы в XML, если бы вы использовали конечную точку веб-сайта - конечная точка веб-сайта возвращает сообщения об ошибках в формате HTML, а не в формате XML.

Создайте новый источник для дистрибутива CloudFront, как описано, затем измените поведение для отправки запросов новому источнику, затем отправьте запрос аннулирования кэша CloudFront для /* и вы должны быть установлены.

Смотрите также:

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff

End две конечные точки. Технически их больше двух, поскольку все сегменты имеют как минимум два возможных имени хоста конечной точки REST... но есть два типа конечных точек. Контейнеры также имеют дополнительную конечную точку ускорения передачи, которая использует пограничную сеть AWS (та же инфраструктура, которая поддерживает CloudFront) для более быстрой/оптимизированной передачи, особенно из географических мест, более удаленных от региона, в котором осуществляется подготовка сегмента, но без использования кэша CloudFront. Эта конечная точка выглядит как https://example-bucket.s3-accelerate.amazonaws.com если вы ее активируете, и за большинство запросов взимается дополнительная плата за использование, поскольку вы используете больше сети AWS и меньше общедоступного Интернета. Но это различие в закулисном развертывании конечной точки, а не в поведении конечной точки. Конечная точка ускорения передачи по-прежнему является конечной точкой REST, поэтому, как и другие конечные точки REST, она не имеет функций размещения веб-сайтов. CloudFront не позволит вам использовать конечную точку ускорения для имени домена-источника, потому что это не имело бы смысла - если бы такая конфигурация была разрешена, запросы и ответы могли бы дважды проходить через пограничную сеть AWS и увеличивать задержки и затраты без предоставление какой-либо выгоды.

Ответ 2

Обнаружена такая же проблема и как я решил, что это было в настройках источника CloudFront, чтобы установить доменное имя происхождения в <website bucket>.s3-website-us-west-2.amazonaws.com

В CloudFront Generate Settings убедитесь, что index.html является основным корневым объектом.

В S3 обязательно используйте это ведро для размещения выбранного веб-сайта и установите index.html как индексный документ.

Ответ 3

Cloudfront хорош, но если его просто для постановки, вы можете заставить его работать только с s3.

на статических конфигурациях сайта s3, убедитесь, что вы указали "index.html" в индексном документе, а также в документе с ошибкой. см. снимок.

enter image description here

Ответ 4

См. Документацию AWS о том, как использовать CloudFront для обслуживания статического веб-сайта, размещенного на S3 через https.

Расшифровка контента ниже для удобства (или в случае, если ссылка когда-либо испортится).

  1. Используйте консоль Amazon S3 для создания корзины и включения статического хостинга веб-сайтов в корзине.

  2. В диалоговом окне статического хостинга веб-сайтов скопируйте конечную точку вашего сегмента без начального http://. Формат похож на имя сегмента .s3-website-region.amazonaws.com. Вам понадобится конечная точка в этом формате для последующего шага.

  3. Добавьте политику сегментов, которая разрешает открытый доступ для чтения к группе, которую вы создали.

  4. Создайте веб-дистрибутив CloudFront. Обязательно настройте следующее:

    • В поле " Имя домена источника" введите конечную точку, скопированную на шаге 2.
    • Для Разрешенных методов HTTP выберите GET, HEAD, OPTIONS.
    • В качестве альтернативных доменных имен (CNAME) введите CNAME, которую вы хотите использовать для своего веб-сайта.

  5. Если вы не хотите использовать SSL (HTTPS) для своего сайта, перейдите к следующему шагу. Если вы хотите использовать SSL для своего веб-сайта, вы можете выбрать Запрос или Импортировать сертификат с помощью ACM, чтобы запросить сертификат. Для получения дополнительной информации см. Использование альтернативных доменных имен и HTTPS.

  6. Выберите Создать рассылку.

  7. Обновите записи DNS для своего домена, чтобы они указывали CNAME вашего веб-сайта на доменное имя дистрибутива CloudFront. Вы можете найти свое доменное имя в консоли CloudFront в формате, аналогичном d1234abcd.cloudfront.net.

  8. Дождитесь распространения изменений DNS и истечения срока действия предыдущих записей DNS.

Ответ 5

У меня также была похожая проблема, я следовал за этими шагами, которые решили эту проблему

ШАГИ:

->go to CloudFront Distributions 
->click the ID
->after Clicking Id you will find different categories like General, Origins and Origin Groups .
->Click the Origins and Origin Groups
->Click the checkbox  of your s3 bucket and click edit
->under grand read Permissions on Bucket click "Yes, Update bucket policy"

Этот шаг решил мою проблему.

Ответ 6

У меня возникла эта проблема, когда я пытался включить имя bucket в мой перенаправление route53 для клиента, чтобы упростить его действие, например:

https://0832234.signin.aws.amazon.com/console/s3/?bucket=clientbucket.com

Нажав на "Все ковши" и вернувшись в ведро клиентов/или удалив ведро с URL-адреса, сделал трюк, теперь я могу загрузить и открыть файлы.