Это меня озадачило. Я могу понять, почему идентификатор учетной записи является глобальным, но почему имена bucket?
Не имеет смысла иметь что-то вроде: https://accountID.storageservice.com/bucketName
Что будет содержать пространства имен под идентификатором учетной записи.
Что мне не хватает, почему эти явно элитные архитекторы решили обрабатывать имена ковша таким образом?
"Пространство имен ведра является глобальным - подобно именам доменов"
Это более чем случайно.
Причина кажется достаточно простой: ковши и их объекты могут быть доступны через пользовательское имя хоста, которое совпадает с именем ведра... и ведро может опционально размещать весь статический веб-сайт - при этом S3 автоматически отображает запросы из входящего заголовка Host: в ведро с тем же именем.
В S3 эти варианты URL ссылаются на один и тот же объект "foo.txt" в ведро "bucket.example.com". Первый работает с включенным статическим хостингом и требует DNS CNAME (или Alias в маршруте 53) или DNS CNAME, указывающий на региональную конечную точку REST; другие не требуют настройки:
http://bucket.example.com/foo.txt
http://bucket.example.com.s3.amazonaws.com/foo.txt
http://bucket.example.com.s3[-region].amazonaws.com/foo.txt
http://s3[-region].amazonaws.com/bucket.example.com/foo.txt
Если службе хранилища объектов требуется простой механизм для разрешения заголовка Host: в HTTP-входящем запросе в имя ведра, пространство имен имен ведра также должно быть глобальным. Что-то еще, похоже, значительно усложнит реализацию.
Для того чтобы имена хостов отображались в именах ковша, что-то должно быть глобально уникальным, поскольку, очевидно, ни одно из двух ведерков не могло ответить на одно и то же имя хоста. Ограничение, применяемое к самому имени ведра, не оставляет места для двусмысленности.
Также кажется вероятным, что многие потенциальные клиенты не хотели бы, чтобы их учетная запись была идентифицирована в именах ведра.
Конечно, вы всегда можете добавить свой идентификатор учетной записи или любую случайную строку в нужное имя ведра, например. jozxyqk-payroll, jozxyqk-staff, если желаемое имя ковша недоступно.
Чем больше я пью, тем выше концепция ниже имеет смысл, поэтому я поднял ее из комментария к принятому ответу на ее собственную сущность:
Дополнительная мысль, которая случайно появилась в моей голове сегодня вечером:
Учитывая возможность использования общих имен узлов, которые предоставляют различные службы хранилища объектов, можно легко скрыть свою корпоративную (или другую) идентификацию в качестве владельца любого данного ресурса данных.
Итак, пусть Black Hat Corp размещает ресурс данных в http://s3.amazonaws.com/obscure-bucket-name/something-to-be-dissassociated.txt.
Было бы очень сложно любому неправительственному субъекту определить, кто является владельцем этого ресурса без сотрудничества с поставщиком хранилища объектов.
Не гнусный по дизайну, просто объективный прагматизм.
И, возможно, удар блеска архитекторов этой парадигмы