S3 Access Points - первый взгляд
Недавно появившиеся S3 Access Points стали попыткой начать избавляться от наследия S3 с её требованием к глобальной уникальности имени бакета (т.е. когда имя приходится каждый раз придумывать новое по каким-то паттернам, т.к. иначе получаем ошибку создания бакета).
Теперь же можно создавать и использовать условные "ссылки на бакет" - S3 Access Points. Такие ссылки имеют имя (например,
Технически попробовать просто - в S3 консоли переходите на вкладку S3 Access Points и создаёте endpoint с каким-то именем. Добавляете к нему #bucket_policy, как к обычному бакету, только в качестве ресурса нужно будет указать arn в виде (он указан на странице вашего Access Point):
"Resource": "arn:aws:s3:
Этот ресурс есть "ссылка на бакет" и к нему можно применять обычные команды #aws_cli (лишь с поправкой, что её придётся для этого обновить, иначе будет ругаться на имя бакета "Bucket name must match..."). Например, можно сделать привычный листинг
Однако в случае cross-account доступа крайне неудобно, т.к. приходится прописывать политики и на самом бакете и на каждой "ссылке" (Access Point). И #CRR (Cross-Region Replication) не работает для S3 Access Points.
И набор других особенностей и ограничений. Так что пока сырое, нужно учитывать данный момент.
Предположительный сценарий использования S3 Access Points - вы обрабатываете данные из одного (общего для всех, единственного) бакета, раздавая ссылки на него со своими политиками для каждого из окружений. Можно также как-то задействовать в Blue-Green сценариях и ещё какие-то специцифичные случаи.
В общем S3AP пополнили длинный список фич Амазона под названием "придумай зачем". Однако это шаг в правильном направлении и будучи допиленным, наверняка станет best practices, т.к. даёт дополнительную абстракцию, позволяя гибко управлять и избавляя от некоторых legacy ограничений.
#S3 #S3AP
Недавно появившиеся S3 Access Points стали попыткой начать избавляться от наследия S3 с её требованием к глобальной уникальности имени бакета (т.е. когда имя приходится каждый раз придумывать новое по каким-то паттернам, т.к. иначе получаем ошибку создания бакета).
Теперь же можно создавать и использовать условные "ссылки на бакет" - S3 Access Points. Такие ссылки имеют имя (например,
ext из примера), которое должно быть уникальным лишь в конкретном регионе и аккаунте. Что может быть удобным при использовании в мульти-аккаунт схеме, где одно приложение в одном аккаунте, значит можно спокойно использовать одинаковые имена (ссылки на бакет).Технически попробовать просто - в S3 консоли переходите на вкладку S3 Access Points и создаёте endpoint с каким-то именем. Добавляете к нему #bucket_policy, как к обычному бакету, только в качестве ресурса нужно будет указать arn в виде (он указан на странице вашего Access Point):
"Resource": "arn:aws:s3:
eu-west-1:896118698909:accesspoint/ext"Этот ресурс есть "ссылка на бакет" и к нему можно применять обычные команды #aws_cli (лишь с поправкой, что её придётся для этого обновить, иначе будет ругаться на имя бакета "Bucket name must match..."). Например, можно сделать привычный листинг
aws s3 ls arn_ссылки_на_бакет (на картинке). Однако в случае cross-account доступа крайне неудобно, т.к. приходится прописывать политики и на самом бакете и на каждой "ссылке" (Access Point). И #CRR (Cross-Region Replication) не работает для S3 Access Points.
И набор других особенностей и ограничений. Так что пока сырое, нужно учитывать данный момент.
Предположительный сценарий использования S3 Access Points - вы обрабатываете данные из одного (общего для всех, единственного) бакета, раздавая ссылки на него со своими политиками для каждого из окружений. Можно также как-то задействовать в Blue-Green сценариях и ещё какие-то специцифичные случаи.
В общем S3AP пополнили длинный список фич Амазона под названием "придумай зачем". Однако это шаг в правильном направлении и будучи допиленным, наверняка станет best practices, т.к. даёт дополнительную абстракцию, позволяя гибко управлять и избавляя от некоторых legacy ограничений.
#S3 #S3AP