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

s3-migrate — migrating objects between S3-compatible storage buckets.

https://github.com/lmammino/s3-migrate

Cases:

▫️ copy an entire bucket from an account to another, and you need two different set of credentials for the source and destination accounts.
▫️ migrate objects from an S3-compatible service to another, such as from DigitalOcean Spaces to AWS S3 or vice versa.

Features:

▪️ Supports different AWS accounts, regions, and even S3-compatible services (it uses the AWS SDK under the hood but with the right configuration it should theoretically work with any S3-compatible service such as DigitalOcean Spaces, MinIO, Cloudflare R2, Backblaze B2, etc.)
▪️ Uses Node.js streams for efficient transfers (Data is transfered directly from the source to the destination without buffering the entire object in memory)
▪️ Allows stopping and resuming with a local SQLite database
▪️ Graceful shutdown on Ctrl+C
▪️ Configurable concurrency level and chunk size for memory / performance tuning
▪️ Progress bar and ETA for the copy process

⚠️ Currently intended for a one-off migration, not to keep 2 buckets in sync.

#S3

Монтируем S3 в систему автоматически через fstab:

s3://my-s3/ /mnt/s3 mount-s3 _netdev,nosuid,nodev,nofail,rw 0 0

https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#automatically-mounting-an-s3-bucket-at-boot

#S3

По-настоящему дешёвое векторное хранилище — S3 Vectors 🎉

https://aws.amazon.com/blogs/aws/introducing-amazon-s3-vectors-first-cloud-storage-with-native-vector-support-at-scale/

#S3