AWS Backup for S3:

https://aws.amazon.com/blogs/storage/automate-and-centrally-manage-data-protection-for-amazon-s3-with-aws-backup/

AWS Backup for Amazon S3 is now generally available in all commercial AWS Regions where AWS Backup is available.

#Backup #S3

Reduce encryption costs by using S3 Bucket Keys on existing objects:

https://aws.amazon.com/blogs/storage/reduce-encryption-costs-by-using-amazon-s3-bucket-keys-on-existing-objects/

In this blog, we’ve walked through the steps to implement S3 Bucket Keys for objects with different KMS keys within same bucket. By doing so, we were able to significantly reduce request traffic from S3 to KMS, decreasing KMS costs by 80 percent.

#S3 #KMS

Официальный клиент для монтирования S3 бакета в файловую систему — Mountpoint for Amazon S3

https://aws.amazon.com/blogs/storage/the-inside-story-on-mountpoint-for-amazon-s3-a-high-performance-open-source-file-client/

Отличия от других клиентов:

1️⃣ Использует те же библиотеки, что и AWS SDK
2️⃣ Написан на Rust
3️⃣ Автонастройка как для S3

Репозиторий:

GitHub 🔗 https://github.com/awslabs/mountpoint-s3
Roadmap 🔗 https://github.com/orgs/awslabs/projects/84

p.s. Альфа версия, у меня не заработало на ARM 😐 .

#S3

​​The illustrated guide to S3 pre-signed URLs:

https://fourtheorem.com/the-illustrated-guide-to-s3-pre-signed-urls/

🔹 S3 pre-signed URLs are a great way to authorize operation on S3.
🔸 They are generally used to implement upload and download functionality.
🔹 The signature is created client-side, so you can sign anything (even actions you don’t even have the right to perform).
🔸 AWS will validate at request time whether the request itself is still valid and not forged, but also that the credentials used for signing the request are actually authorized to perform the given action.
🔹 There are two different methods to perform uploads: PUT and POST. POST is more complex but also much more flexible. POST is less used in the wild, but you should consider using it!
🔸 S3 pre-signed URLs are not the only option and they come with their own set of tradeoffs. Always evaluate what’s the best solution for the problem at hand.

#S3

Что такое S3 DSSE-KMS:

https://aws.amazon.com/blogs/aws/new-amazon-s3-dual-layer-server-side-encryption-with-keys-stored-in-aws-key-management-service-dsse-kms/

На текущий момент для S3 объектов доступно 4 типа шифрования:

1️⃣ Server-side encryption with S3 managed keys (SSE-S3)
2️⃣ Server-side encryption with KMS (SSE-KMS)
3️⃣ Server-side encryption with customer-provided encryption keys (SSE-C)
4️⃣ Dual-layer server-side encryption with keys stored in KMS (DSSE-KMS)

Если упростить, то это SSE-S3 + SSE-KMS/SSE-C в одном флаконе. То есть 4️⃣ = 1️⃣ + 2️⃣ или 3️⃣.

Если чуть более подробней, то стоит глянуть официальный ролик «Announcing Amazon S3 dual-layer server-side encryption (DSSE-KMS)»:

https://www.youtube.com/watch?v=VtpyPqYke-w

Где есть табличка сравнения типов.
К сожалению, нужно делать поправку на то, что табличка слишком маркетинговая, нужно будет сделать свою.

Если же есть желание разобраться подробней, то вот первоисточник — Data-at-Rest Capability Package V5.0:

https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/capability-packages/(U)%20Data-at-Rest%20Capability%20Package%20v5.0.pdf

В котором описано ужесточение требований к шифрованию. В нём, в отличие от документа четвёртой версии, появляется понятие "двухуровновой" защиты:

«Data-at-Rest (DAR) Capability Packages (CP) version 5.0 enables customers to implement two independent layers of encryption for the purpose of providing protection for stored information on the End User Device or DAR protected system, while in a powered off or unauthenticated state.
This CP takes lessons learned from proof-of-concept demonstrations that have implemented the Commercial National Security Algorithm Suite, modes of operation, standards, and protocols.
These demonstrations included a layered use of Commercial Off-the-Shelf products for the protection of classified information.»

Из которого следует, что одного слоя шифрования теперь недостаточно. То есть нельзя просто зашифровать весь диск/раздел/файл криптостойким алгоритмом. Нужно реализовать такой подход дважды (и обязательно с разными кредами).

Если сравнивать это с ноутбуком, то требуется иметь шифрованный диск и вводить пароль при старте компьютера. А после при доступу к нужному файлу/диску ещё раз вводить (другой) пароль.

SSE-S3 в этом сравнении — AWS за нас каждый раз вводил такой пароль "при старте компьютера". Это, так называемое, "шифрование для галочки", которое лишь защищает от того, что накопители враги вдруг выкрадут из датацентра, а там всё зашифровано. В терминах DAR CP v.5 это "outer layer" — внешний уровень защиты.

SSE-KMS или SSE-C при таком раскладе это внутренний уровень защиты ("inner layer").

Раньше можно было включить или SSE-S3 (который нонче по дефолту) или SSE-KMS/SSE-C. А с помощью DSSE-KMS включаются и работают (под капотом) сразу два уровня — все объекты шифруются дважды.

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

По стоимости DSSE-KMS получается дороже, чем SSE-KMS/SSE-C, так как S3 bucket keys (кэширование KMS ключей на уровне S3 бакета) для этого типа недоступно (как минимум, пока).

#S3 #security

Mountpoint for Amazon S3 + caching

https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint-usage.html#mountpoint-caching

mount-s3 some-bucket ~/mnt --cache /local/path

More examples:

https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#caching-configuration

#S3 #Mountpoint

​​📁stree — directory trees of S3

https://github.com/orangekame3/stree

#S3

Generate S3 presigned URL with S3 Transfer Acceleration

https://github.com/aws-samples/generate-s3-accelerate-presigned-url

▪️ APIGW
▪️ Lambda
▪️ Java 21
▪️ AWS SAM

#S3 #examples

It is not a bug, it is by design.

https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

Краткое изложение — автор статьи в результате экспериментов получил счёт на 1000+ долларов за пустой (!) приватный (!) S3 бакет.

Прочитав документацию, он обнаружил, что всё верно, так может быть. Мало того, техподдержка подтвердила: да, это предполагаемое поведение — владелец бакета платит за обращения к нему, включая те, что дают ошибку аутентификации. То есть в том числе от анонимных пользователей (читай "через интернет").

И это только сейчас заметили?!?

Нет, на моей памяти раз в несколько лет эта тема поднимается. Например, вот свежее обсуждение на Reddit (2024):

https://www.reddit.com/r/aws/comments/1cg7ce8/how_an_empty_private_s3_bucket_can_make_your_bill/

А вот она же трёхлетней давности (2021):

https://www.reddit.com/r/aws/comments/mwpuys/exploitable_hole_in_s3_requester_pays_bucket_to/

Вот обобщение в виде Denial-of-Wallet attacks (2020):

https://portswigger.net/daily-swig/denial-of-wallet-attacks-how-to-protect-against-costly-exploits-targeting-serverless-setups

S3 Requester Pays

Кто сдавал на сертификацию :) знают про существование такого режима и даже предполагают, что его недавно сделали как раз для борьбы с подобными проблемами.

Нет, это древняя фича (2008):

https://aws.amazon.com/blogs/aws/bits-for-sale-amazon-s3-requester-payment-model/

Но главное, она не защитит от подобной проблемы, так как:

Bucket owner is charged for the request under the following conditions:
• Request authentication fails (HTTP code 403).
• The request is anonymous (HTTP code 403).

Как же защититься от этого?!?

Ответ читайте в нашей популярной книжке "Никак".
◾ Можно генерировать длинные имена S3 бакетов из случайных символов (бесплатно)
◾ Использовать AWS Shield Advanced (3k$/month)
◾ Написать <что угодно> в S3 bucket policy — не поможет (см. Request authentication fails)
◾ Разрешить доступ только из своей VPC (см. предыдущий пункт)
◾ Добавить в Readme "Я тебя найду по айпи!!" (недорого)

В общем, рекомендация почитать книжку оказывается наиболее актуальной.

But why?!?

It is not a bug, it is by design.

S3 — очень старый сервис, некоторые даже думают, первый (в реальности первый SQS). Когда его придумывали, не было проблемы с приватностью (этого добра всегда есть и будет в on-premise варианте), была обратная проблема — сделать публичным. По дизайну сервис S3 и, главное, S3 API — публичные. Это нужно зафиксировать.

Все объекты в бакете можно сделать публичными с помощью S3 ACL. Да, именно того, что лишь год назад был по дефолту выключен.

Концепция VPC , а после и понятие "приватные бакеты", появились существенно позже, в 2011-м году. То есть важно отметить, это больше "маркетинговое" название, ибо by design сами бакеты публичные или могут таким стать, а также уникальные (всегда можно определить наличие такого, просто попытавшись создать и получив ошибку, что имя "занято").

Короче, невозможно полностью и бесплатно защититься от Denial-of-Wallet attacks по определению.

И что, реально так всё плохо?

Нет. Стоит помнить — проблема была всегда. У AWS есть способы её детекта и разрешения, в том числе с помощью техподдержки. Случайно сгенерировать существенный биллинг непросто, т.к. это должны быть не миллионы. а миллиарды запросов. Плюс, конечно же, у вас обязательно должен быть настроен алерт на бюджет. :)

А как у других?

В Google:

Generally, you are not charged for operations that return 307, 4xx, or 5xx responses. The exception is 404 responses returned by buckets with Website Configuration enabled and the NotFoundPage property set to a public object in that bucket.

Итого, AWS есть, что улучшать. И публичное обсуждение старой архитектурной проблемы — отличный стимул.

#S3

Essential reading for understanding S3 buckets:

https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/

🔹 S3 buckets are the S3 API
🔸 ListObjects is not the only way to get object keys
🔹 Incomplete multipart uploads are Schrodinger’s objects
🔸 Multipart upload listings leak return principal ARNs
🔹 Access control lists can grant access based on email
🔸 Storage class is uploader’s choice
🔹 Pretty much everything is uploader’s choice
🔸 S3 will tell you the bucket owner if you ask nicely
🔹 Keys are case sensitive
🔸 More ways to make a bucket public

#S3

​​S3 как container registry вместо ECR — в 5-8 раз быстрее и в 4 раза дешевле!

https://ochagavia.nl/blog/using-s3-as-a-container-registry/

#S3 #ECR

Storage Browser for S3

Шёл 2024-й год. Не прошло и 20 лет спустя появления Amazon S3, как уже можно прямо в браузере ходить по S3!

https://github.com/aws-amplify/amplify-ui/issues/5731

Правда пока альфа-версия, но, глядишь, к юбилею успеют.

Хотя, вроде были варианты. Например, S3Fox:

https://aws.amazon.com/blogs/aws/s3fox_organizer/

Странно, в чём же прикол? Почему AWS потребовалось два десятка лет, чтобы придумать внешне обычный S3 просмотрщик?

Ох. Всё непросто. Дело в том, что у нас теперь новый, правильный S3. Точней, доступ к нему. Вы и не заметили, но это перепридуманный доступ к S3. Причём дважды.

AWS разработчикам пришлось всё переделать и при этом чтобы ничего не изменилось для старого и просто древнего кода.

А что ж так, зачем? Всё просто, две волшебные буквы — AI. В данном случае данные в виде Data Lake. Нужно иметь возможность задавать доступ к огромному количеству источников данных, где старый-привычный подход на базе IAM Roles и S3 Bucket policy не годится из-за ограничений и тупо неудобности.

Так были придуманы S3 Access Grants, которые были анонсированы на re:Invent 2023.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html

Реально полезное видео с этого реинвента:

https://www.youtube.com/watch?v=Ts-ZMBzGeh0

И AWS Blogs:

Часть 1 https://aws.amazon.com/blogs/storage/how-to-develop-a-user-facing-data-application-with-iam-identity-center-and-s3-access-grants/
Часть 2 https://aws.amazon.com/blogs/storage/how-to-develop-a-user-facing-data-application-with-iam-identity-center-and-s3-access-grants-part-2/

Кратко смысл следующий. Мы создаём S3 грант в аккаунте, с помощью которого юзер сможет получить доступ к S3 бакету или его префиксу. Юзер через условную Okta или MS Entra ID получает доступ с этим грантом через IAM Identity Center. В результате доступом к своим данным, разбросанным по аккаунтам и бакетам централизованно и при желании — извне Амазона.

Итого, что было раньше. Раньше были S3 ACL. Потом S3 Bucket Policy. Затем плюс IAM к ним. После S3 Access Points. И, на радость всем разработчикам AWS курсов, S3 Access Grants.

Важно отметить, что S3 Access Grants — нонче рекомендуемый способ предоставления доступа к данным в S3. Перевожу на понятный — все остальные "нерекомендованные". 😁

Причём тут Storage Browser for S3 вообще?

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

Помните эту вечную болячку и постоянный вопрос "как сделать листинг только тех бакетов, которые нужно" — никак, листинг s3:ListAllMyBuckets требует звёздочку в ресурсах.

И вот, наконец, ему на замену есть s3:ListCallerAccessGrants, который был нужен, чтобы реализовать Storage Browser for S3 — нам же нужно вывести всё, доступное пользователю.

https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_ListCallerAccessGrants.html

Итого, с помощью s3:ListCallerAccessGrants можно получить полный список доступных S3 бакетов и доступных только этому юзеру, где он не увидит имени сразу всех S3 бакетов в аккаунте.

Это победа!

P.S. Жаль нет больше в AWS Василия Пантюхина. И эти титанические усилия на стороне AWS остаются не раскрытыми. А тут такая драма, нет, остросюжетный детектив, сериал, что угодно, а видно почти никому. Полезешь копаться, а там и пасхалки, и респауны, и шкафы со скелетами на каждом уровне.

#S3

AWS replacement for CodeCommit — git-remote-s3

https://github.com/awslabs/git-remote-s3

• git remote helper to use S3 as a serverless Git server
• git-lfs custom transfer to push LFS files

#CodeCommit #git #S3

Вы хотели S3 бакетов? Да пожалуйста!

https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-s3-up-1-million-buckets-per-aws-account

2006: 100
2015: 100 - 1000
2022: 1000 - 10 000
2024-11: 10 000 - 1 000 000

#S3

🆕 AWS Transfer Family web apps

https://aws.amazon.com/blogs/aws/announcing-aws-transfer-family-web-apps-for-fully-managed-amazon-s3-file-transfers/

Если вы не смогли поставить себе какой-нибудь Cyberduck для работы с данными в S3, то теперь можно настроить UI доступ к S3 с помощью AWS Transfer Family web apps. За каких-то 360$ в месяц за приложение.

#Transfer_Family #S3

Storage Browser for Amazon S3

https://www.youtube.com/watch?v=UBpX8hCpLAY

AWS Blog:

https://aws.amazon.com/blogs/aws/connect-users-to-data-through-your-apps-with-storage-browser-for-amazon-s3/

#S3

🆕 S3 Tables = S3 buckets для аналитики

https://aws.amazon.com/blogs/aws/new-amazon-s3-tables-storage-optimized-for-analytics-workloads/

По сравнению с возможностью сделать на S3 buckets всё то же самое, S3 Tables обещает:

🔹 up to 3x faster query performance
🔸 up to 10x more transactions per second

И это весьма серьёзное отличие для прожорливых аналитических запросов.

А что с ценой? Отличия по самому хранению минимальные — где-то +5% по сравнению с S3 buckets. Если включить сжатие (S3 Tables compaction), то добавится ещё десяток-другой процентов, что вполне адекватно.

С ходу S3 Tables имеют интеграцию с Athena, Redshift, EMR, Glue Data Catalog и QuickSight.

Итого, нужно брать. С учётом важности работы с данными сейчас, S3 Tables теперь базовый элемент инфраструктуры.

Мои очередные сожаления (поздравления) всевозможным курсам — переделывать (и продавать).

#S3

Deep dive on Amazon S3

https://www.youtube.com/watch?v=NXehLy7IiPM

S3:

🔸400 trillion objects amounting to exabytes of data
🔹150 million requests per second daily
🔸200 billion event notifications
🔹1 petabyte per second of traffic worldwide at peak

🔸tens of millions of hard drives, 20 terabytes each
🔹storage rack is about 1000 disks, 20 petabytes each

#S3 #video

AWS поломал поддержку S3 со всеми сторонними S3-совместимыми инструментами.

В январе 2025-го года прилетело такое обновление AWS SDK:

https://github.com/aws/aws-sdk-go-v2/blob/release-2025-01-15/service/s3/CHANGELOG.md#v1730-2025-01-15

В нём появились два параметра:

AWS_REQUEST_CHECKSUM_CALCULATION
AWS_RESPONSE_CHECKSUM_VALIDATION

Они как бы должны быть опциональными, но нет.

Поэтому, если у вас что-то не собирается, вы повторяете какой-то туториал, где всё красиво, а у вас лезут ошибки, то придётся страдать добавьте в ~/.aws/config переменные:

request_checksum_calculation=when_required
response_checksum_validation=when_required

Либо через экспорт:

export AWS_REQUEST_CHECKSUM_CALCULATION=when_required
export AWS_RESPONSE_CHECKSUM_CALCULATION=when_required

В качестве альтернативы, просто пиньте версию до этого обновления, например, AWS CLI 2.23.0.

#S3

Логи Lambda теперь дешевле

https://aws.amazon.com/blogs/compute/aws-lambda-introduces-tiered-pricing-for-amazon-cloudwatch-logs-and-additional-logging-destinations/

Если у вас их было очень много (терабайты - но зачем?), то экономия существенная.

Возможность слать логи в S3 выглядит привлекательно, но как понимаю, это в довесок к CloudWatch, а не вместо — экономия лишь на хранении (а основной расход - ingestion).

#Lambda #CloudWatch #S3