Строго говоря, нет технической причины, по которой пространство имен корзины должно было быть глобальным. На самом деле, технически это не вполне настолько глобально, как может предположить большинство людей, потому что S3 имеет три отдельных раздела, которые полностью изолированы друг от друга и не разделяют одно и то же глобальное пространство имен сегмента через границы раздела - это разделы aws (глобальная коллекция регионов, которые большинство людей знают как "AWS"), aws-us-gov (US GovCloud) и aws-cn (изолированные регионы Пекин и Нинся).
Таким образом, все могло бы быть разработано по-разному, независимо от региона, но сейчас это не имеет значения, потому что укоренилось глобальное пространство имен.
Но почему?
Конкретные c причины глобального пространство имен публично не заявлено, но почти наверняка связано с развитием сервиса, обратной совместимостью и простотой освоения новых регионов.
S3 - один из старейших сервисов AWS, старше даже EC2. Они почти наверняка не предвидели, насколько большим он станет.
Первоначально пространство имен было глобальным по необходимости, поскольку не было нескольких регионов. У S3 была одна логическая область (называемая «Стандарт США» в течение длительного времени), которая фактически состояла из по крайней мере двух физических областей, в или около нас - восток-1 и нас - запад-2. Вы не знали или не заботились о том, в какой физический регион отправлялась каждая загрузка, потому что они реплицировались туда-сюда, прозрачно, и разрешение DNS на основе задержек автоматически давало конечную точку с наименьшей задержкой. Многие пользователи никогда не знали этой детали.
Вы могли бы даже явно переопределить автоматическую c географическую маршрутизацию загрузки DNS и amd на восток, используя конечную точку s3-external-1.amazonaws.com, или на запад, используя конечную точку s3-external-2.amazonaws.com, но ваш объект вскоре будет доступен с любой конечной точки.
До этого момента S3 не предлагал немедленной согласованности чтения-после-записи для новых объектов, поскольку это было бы нецелесообразно в первичной / первичной, циклической среде репликации который существовал в более ранние дни.
В конце концов, S3 запустился в других AWS регионах, когда они подключились, но они разработали его так, чтобы корзина в любом регионе была доступна как ${bucket}.s3.amazonaws.com. При этом DNS использовался для направления запроса в правильный регион на основе имени сегмента в имени хоста, а S3 поддерживал сопоставления DNS. *.s3.amazonaws.com был (и остается) записью с подстановочными знаками, которая указывала все на «S3 US Standard», но S3 создаст CNAME для вашего сегмента, который отвергнет подстановочный знак и автоматически укажет на правильную область, через несколько минут после создания сегмента. До этого S3 возвращал бы временное перенаправление HTTP. Это, очевидно, требует глобального пространства имен корзины. Это все еще работает для всех, кроме самых новых регионов.
Но почему они так поступили? В конце концов, примерно в то же время S3 также ввел конечные точки в стиле ${bucket}.s3-${region}.amazonaws.com ¹, которые фактически являются записями DNS с подстановочными знаками: *.s3-${region}.amazonaws.com направляет непосредственно к региональной конечной точке S3 для каждой области S3 и является отзывчивой (но непригодной) конечной точкой даже для несуществующих ведер. Если вы создаете контейнер в us-east-2 и отправляете запрос на этот контейнер в конечную точку eu-west-1, S3 в eu-west-1 выдаст ошибку, сообщающую, что вам нужно отправить запрос нам -east-2.
Кроме того, примерно в это же время они тихо отбросили всю репликацию восток / запад, а затем переименовали в US Standard в то, что в действительности было на тот момент - us-east-1. (Подкрепляя аргумент «обратной совместимости», s3-external-1 и s3-external-2 по-прежнему являются действительными конечными точками, но они оба указывают на одно и то же место в us-east-1.)
Итак почему пространство имен корзины остается глобальным? Единственный действительно правильный ответ, который может дать посторонний, это «потому что именно это и решили сделать».
Но, возможно, одним из факторов было то, что AWS хотел сохранить совместимость с существующим программным обеспечением, которое использовало ${bucket}.s3.amazonaws.com, чтобы клиенты могли развертывать сегменты в других регионах без изменений кода. В старые времена Signature Version 2 (и более ранних версий) код, подписавший запросы, не должен был знать регион конечной точки API. Для подписи версии 4 требуется знание области конечной точки, чтобы сгенерировать действительную подпись, потому что ключ подписи получен на основе даты, региона и службы ... но ранее это было не так, так что вы могли просто бросить корзину имя и код клиента не нуждались в региональной осведомленности - или даже в том, что у S3 даже были регионы - чтобы работать с корзиной в любом регионе.
AWS хорошо известен своей практикой сохранения в обратном направлении совместимость. Они делают это настолько последовательно, что иногда появляются некоторые смущающие ошибки проектирования, которые остаются нефиксированными, потому что их исправление может нарушить работающий код .²
Другая проблема - виртуальный хостинг блоков. Еще до того, как HTTPS был принят как необязательный, было принято размещать контент ststi c, указывая ваше CNAME на конечную точку S3. Если вы укажете www.example.com на S3, он будет доставлять содержимое из корзины с точным именем www.example.com. Вы все еще можете сделать это, но это больше не полезно, поскольку не поддерживает HTTPS. Для размещения содержимого c S3 с HTTPS вы используете CloudFront перед корзиной. Поскольку CloudFront переписывает заголовок Host, имя корзины может быть любым. Вы можете спросить, почему вы не можете просто указать www.example.com CNAME на имя хоста конечной точки вашего сегмента, но HTTP и DNS работают на очень разных уровнях, и это просто не работает таким образом. (Если вы сомневаетесь в этом утверждении, попробуйте указать CNAME из домена, которым вы управляете, значение www.google.com.. Вы не обнаружите, что ваш домен обслуживает домашнюю страницу Google; вместо этого вы увидите сообщение об ошибке, поскольку сервер Google будет только убедитесь, что он получил запрос на www.example.com, и не обращайте внимания на тот факт, что на него указывает промежуточный CNAME.) Виртуальный хост для сегментов требует либо глобального пространства имен сегмента (таким образом, Host заголовок точно соответствует сегменту) или полностью отдельной базе данных сопоставления имен хостов с именами сегментов ... и зачем это делать, когда у вас уже есть установленное глобальное пространство имен сегментов?
¹ Обратите внимание, что - после s3 в этих конечных точках в конечном итоге было заменено гораздо более логичным ., но эти старые конечные точки все еще работают.
² два примера, которые приходят на ум: (1) неправильное пропускание S3 Vary: Origin заголовок ответа, когда запрос не-CORS поступает в корзину с поддержкой CORS (я утверждал, что без успеха признайте, что это можно исправить, не ломая ничего, но безрезультатно); (2) Откровенно некорректная обработка S3 символа + в ключе объекта в API, где служба интерпретирует + как значение %20 (пробел), поэтому, если вы хотите, чтобы браузер загружал по ссылке на /foo+bar Вы должны загрузить его как /foo{space}bar.