S3 Intelligent-Tiering — отмена ограничений для маленьких файлов (меньше 128КБ) и минимального срока хранения 30 дней:

https://aws.amazon.com/blogs/aws/amazon-s3-intelligent-tiering-further-automating-cost-savings-for-short-lived-and-small-objects/

To date, S3 Intelligent-Tiering was intended for objects larger than 128 KB stored for a minimum of 30 days. As of today, monitoring and automation charges will no longer be collected for objects smaller than 128 KB — this includes both new and already existing objects in the S3 Intelligent-Tiering storage class. Additionally, objects deleted, transitioned, or overwritten within 30 days will no longer accrue prorated charges.

Полезное изменение, которое делает S3 Intelligent-Tiering существенно более эффективным, т.к. снимает одну из самых популярных причин, что часто делало просто невыгодным его использование.

#S3

​​Amazon S3 Multi-Region Access Points:

https://aws.amazon.com/blogs/aws/s3-multi-region-access-points-accelerate-performance-availability/

This S3 feature that allows you to define global endpoints that span buckets in multiple AWS Regions. With S3 Multi-Region Access Points, you can build multi-region applications with the same simple architecture used in a single region.

Крутая фича, мультирегиональности продолжают шириться и множиться (и это хорошо). Правда, понятно, это небесплатно:

When you use an S3 Multi-Region Access Point to route requests within the AWS global network, you pay a data routing cost of $0.0033 per GB processed, in addition to the standard charges for S3 requests, storage, data transfer, and replication. If your applications access the S3 Multi-Region Access Point over the internet, you’re also charged an internet acceleration cost per GB. This cost depends on the transfer type (upload or download) and whether the client and the bucket are in the same or different locations.

Обзорное видео по S3 Multi-Region Access Points:

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

#S3

S3 security — Top 10 best practices:

https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-data-in-amazon-s3/

1️⃣ Block public S3 buckets at the organization level
2️⃣ Use bucket policies to verify all access granted is restricted and specific
3️⃣ Ensure that any identity-based policies don’t use wildcard actions
4️⃣ Enable S3 protection in GuardDuty to detect suspicious activities
5️⃣ Use Macie to scan for sensitive data outside of designated areas
6️⃣ Encrypt your data in S3
7️⃣ Protect data in S3 from accidental deletion using S3 Versioning and S3 Object Lock
8️⃣ Enable logging for S3 using CloudTrail and S3 server access logging
9️⃣ Backup your data in S3
🔟 Monitor S3 using Security Hub and CloudWatch Logs

#S3 #security #best_practices

​​Визуальный вариант SSE-S3 шифрования для Amazon S3.

#security #S3 #пятничное

Меньше месяца до re:Invent 2021. Можно (нужно) делать прогнозы.

Amazon S3 - прогнозы

🔸 Глобальная S3 файловая система

Тренд на "мультирегиональность всего" для S3 в этом году уже вылился в фичу Amazon S3 Multi-Region Access Points. Что круто, хотя, понятно, и за (дополнительные) деньги.

Но что дальше? Что на счёт глобальной рапределённой глобальной файловой системы на базе S3?

Есть популярная s3fs, а недавно Яндекс выкатил сильно улучшенную по производительности GeeseFS на Go, полностью совместимую с Amazon S3. Чем ответит AWS?

🔸 S3 bucket Backup

Дальше, обещали бэкап для S3 бакетов — я ведь помню (потому что записываю)! 😁 Где он, спрашивается?! Давайте уже, сколько ж можно.

🔸 S3 bucket name - проблема уникальности

В прошлом году порешали, наконец, консистентность, которая с момента создания S3 создавала столько сложных вопросов при сдаче на AWS сертификацию.

Другая такая же застарелая проблема - уникальность имени бакетов. Уже есть и средства для решения (S3 Access Points), и прямо реальная очевидность проблемы в виде S3 Bucket Namesquatting, когда команде из AWS Security пришлось просить Ian Mckay вернуть им нужные для работы имена.

Можно ожидать её решения. Нужно закрывать столь застарелый technical debt.

===

А у вас какие прогнозы на re:Invent (и просто пожелания) по фичам для Amazon S3?

#S3 #reInvent

Как раз в продолжение темы предыдущего поста - советы по мультирегиональной репликация S3:

https://aws.amazon.com/blogs/storage/ten-tips-for-multi-tenant-multi-region-object-replication-in-amazon-s3/

This blog summarized the challenges ISV customers face when building a durable, scalable, and highly available data storage layer for their multi-tenant, multi-Region applications. Examples include the need to replicate data within and between AWS Regions and to reduce undifferentiated heavy lifting. 

#S3

​​AWS Backup для S3:

https://aws.amazon.com/blogs/aws/preview-aws-backup-adds-support-for-amazon-s3/

Добавление в ресурсы для бэкапа (Resource assignment) происходит обычным образом – перечислением конкретных (Include specific resources types), либо добавлением тэгов. При выборе через консоль конкретных бакетов, в списке будут лишь бакеты текущего региона.

Восстановить можно весь S3 бакет целиком, либо отдельные объекты. В какой-то конкретный бакет или создать новый. Можно изменить шифрование – использовать или нет.

Есть следующие опции восстановления:

• Restore time — point-in-time вариант восстановления за последние 35 дней
• Restore type — целиком бакет или выборочные файлы
• Restore destination — тот же (текущий) бакет, другой или создать новый в процессе восстановления
• Restored object encryption — восстанавливать с шифрованием или без, тем же ключом (по умолчанию) или другим

Пока это лишь preview и пока это лишь в регионе US West (Oregon) Region only.

#Backup #S3

​​S3 ACL отправили на пенсию (наконец-то):

https://aws.amazon.com/blogs/aws/new-simplify-access-management-for-data-stored-in-amazon-s3/

В прошлом году сначал разобрались с застарелой проблемой "чей же объект в бакете?" S3 Object Ownership. Сразу после добили, наконец, Strong Read-After-Write Consistency. Пришло время разобраться, "кто в бакете хозяин" — древние S3 ACL или новомодные (ага, уже 10 лет как!) IAM и S3 Bucket Policy.

И вот мощь S3 Object Ownership теперь выросла до возможности полностью игнорировать давно устаревшие S3 ACL. В результате теперь при создании бакета функционал S3 ACL по умолчанию выключен!

Жаль, конечно, что такое нельзя сделать с существующими бакетами, но то и понятно. В любом случае S3 ACL disabled сделает S3 бакеты безопаснее и проще в работе, т.к. не будет требовать знаний, как работал доступ к объектам в S3 15 лет назад.

В прошлом году спрашивал у Василия Пантюхина, когда же, наконец, задеприкейтят S3 ACL. И тут такой подарок под Новый Год. Низкий поклон команде Amazon S3 до самого бакета! 😀

#S3

​​S3 console — generating a presigned URL:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html#ShareObjectPreSignedURLConsole

The credentials that you can use to create a presigned URL include:

🔸 IAM instance profile: Valid up to 6 hours

🔸 STS: Valid up to 36 hours when signed with permanent credentials, such as the credentials of the AWS account root user or an IAM user

🔸 IAM user: Valid up to 7 days when using AWS Signature Version 4

#S3 #AWS_Console

​​S3 Replication vs AWS Datasync vs S3 Batch Operations vs S3 CopyObject API:

https://aws.amazon.com/blogs/storage/considering-four-different-replication-options-for-data-in-amazon-s3/

#S3