URL для публичного ковша Amazon S3

У меня есть ведро Amazon S3, которое я публикую с такой политикой

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow Public Access to All Objects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket/*"
        }
    ]
}

Мое ведро теперь видно как http://bucket.s3-website-us-east-1.amazonaws.com/

Я вижу, что другие ссылаются на их ведро как http://s3-us-east-1.amazonaws.com/bucket/

Я бы предпочел второй URL, но он дает отказ в доступе.

Как я могу изменить свою политику, чтобы разрешить второй URL?

Ответ 1

Структура URL, на которую вы ссылаетесь, называется конечной точкой REST, в отличие от конечной точки веб-сайта.

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

Если ваше ведро действительно находится в регионе AWS-восток-1 AWS - который ранее упоминалась как "Стандарт США" в документации S3, но впоследствии был официально переименован в "Восточный регион США (штат Вирджиния)" - тогда http://s3-us-east-1.amazonaws.com/bucket/ не является правильной формой для этой конечной точки, хотя похоже, что это должно быть. Правильный формат для этого региона - это http://s3.amazonaws.com/bucket/ или http://s3-external-1.amazonaws.com/bucket/. & Sup1;

Формат, который вы используете, применим ко всем другим регионам S3, но не ~~US Standard~~ US East (N. Virginia) [us-east-1].

S3 теперь также имеет имена узлов конечной точки двойного стека для конечных точек REST, и в отличие от исходных имен хостов конечной точки имена их имеют согласованный формат по регионам, например s3.dualstack.us-east-1.amazonaws.com. Эти конечные точки поддерживают как подключение IPv4, так и IPv6 и разрешение DNS, но в остальном функционально эквивалентны существующим конечным точкам REST.

Если ваши разрешения и настройки настроены так, что конечная точка веб-сайта работает, то конечная точка REST также должна работать.

Однако... две конечные точки не имеют одинаковой функциональности.

Грубо говоря, конечная точка REST лучше подходит для доступа к машинам, а конечная точка веб-сайта лучше подходит для доступа человека, поскольку конечная точка веб-сайта предлагает дружественные сообщения об ошибках, индексные документы и перенаправления, в то время как конечная точка REST не " т. С другой стороны, конечная точка REST предлагает HTTPS и поддерживает подписанные URL-адреса, а конечная точка веб-сайта - нет.

Выберите подходящий тип конечной точки (REST или веб-сайт) для вашего приложения:

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

& ПОД1; s3-external-1.amazonaws.com упоминается как "конечная точка Северной Вирджинии" в отличие от "Глобальной конечной точки" s3.amazonaws.com. Неофициально можно было получить согласованность "после записи" для новых объектов в этом регионе, если было использовано имя хоста "s3-external-1" , поскольку это отправит вам подмножество возможных физических конечных точек, которые могут обеспечить эту функциональность. Такое поведение теперь официально поддерживается на этой конечной точке, поэтому, вероятно, это лучший выбор во многих приложениях. Раньше s3-external-2 упоминался как "конечная точка Тихого океана" для US-Standard, хотя теперь это CNAME в DNS для s3-external-1 поэтому s3-external-2 не имеет никакой цели, кроме обратной совместимости.