> 1. Buckets is unnecessary concept. Why use it at all, when we have domain and path. That should be enough. Bucket is a very important concept in S3 buckets.

> 1. Buckets is unnecessary concept. Why use it at all, when we have domain and path. That should be enough. Bucket is a very important concept in S3 buckets. Because a S3 bucket is a container filled with S3 objects. A S3 object can have a fine-grained lifecycle policy defined and attached to them or can have one, all or a combination of the following: 1. S3 objects can be versioned. S3 object versioning is very useful is many scenarios, and the S3 bucket can automatically purge expired object versions for the user after a desired period of time with zero effort – it is defined in the object lifecycle policy. 2. S3 buckets are event-driven. A S3 bucket can be configured to emit an event when something happens to a S3 object in the bucket. There is no need to poll a S3 bucket for changes, for it can notify interested consumers via a new event. S3 buckets offer a rich set of events to choose from that cater for multiple use cases. S3 bucket events are a boon that also greatly simplifies the solution architecture, design and implementation. 3. S3 objects can be locked in governance or in compliance modes for a certain amount of time. Both are useful to prevent the accidental data loss or preclude nefarious attempts to corrupt/delete the important data. The compliance object lock is very useful to satisfy statutory compliance requirements when sharing the data with regulatory and government bodies. Object lock is applied at the S3 object version level and can also be lifted automatically via a defined lifecycle policy wth zero coding effort required. 4. S3 bucket can be set up to automatically replicate the data across multiple S3 buckets, either across different accounts or across regions. S3 buckets can be replicated in full or in part with zero extra coding required – replication rules are defined in the replication configuration. 5. S3 buckets also allow one to choose a storage class which is equivalent to the automatic data archival. > 2. Authentication is too convoluted. Signings, etc. Simple `Authorization` header should be enough. S3 buckets are often useful to share the data with external business partners, therefore the identity of the party accessing accessing the bucket is to be asserted first. Multiple business partners can be granted access to the same bucket either in its entirety, or the S3 bucket can be partitioned and the partner can only be granted access to that partition. Therefore proper authentication is important. > Basically I want to be able to use object storage with simple `fetch` and few lines of code. Without all that SDK nonsense. Then you are probably do not need a S3 bucket and can stand up your own HTTP server with a block storage attached to it or explore alternative solutions. S3 is a complete, feature rich software product that may or may not be suitable for one's needs. In most cases, though, it is very simple and easy to use and having to use the SDK is a non-existing problem.