Amazon AWS S3 bucket & object best practices
The following best practices/rules apply for naming buckets in Amazon S3.

S3: Simple Storage Service (Cloud Storage)
1. Bucket names must be between 3 and 63 characters long.2. Bucket names can consist only of lowercase letters, numbers, dots (.), and hyphens (-).3. Bucket names must begin and end with a letter or number.4. Bucket names must not be formatted as an IP address (for example, 192.168.5.4).5. Bucket names must not start with the prefix xn--.6. Bucket names must not end with the suffix -s3alias. This suffix is reserved for access point alias names. For more information, see Using a bucket-style alias for your access point.7. Bucket names must be unique within a partition. A partition is a grouping of Regions. AWS currently has three partitions: aws (Standard Regions), aws-cn (China Regions), and aws-us-gov (AWS GovCloud [US] Regions).8. Buckets used with Amazon S3 Transfer Acceleration can't have dots (.) in their names.Example
valid bucket names
docexamplebucket1
log-delivery-march-2020my-hosted-contentvalid but not recommended for uses other than static website hosting
docexamplewebsite.comwww.docexamplewebsite.commy.example.s3.bucketNot Valid bucket names
doc_example_bucket (contains underscores)DocExampleBucket (contains uppercase letters)doc-example-bucket- (ends with a hyphen)Folder / Object best practices
- Don’t use the sequential prefix.
Using a sequential prefix, such as timestamp or an alphabetical sequence, increases the likelihood that Amazon S3 will target a specific partition for a large number of your keys, overwhelming the I/O capacity of the partition
example:
Avoid this pattern
filename1.parquet
filename2.parquet
filename3.parquetorfilename_20210101.csv
filename_20210102.csvAdd random prefix, the easy way would be to generate HASH Keys and prefix them.
someprefix_filename1.parquet
anotherprexi_filename2.parquetor01012021_filename.csv
02012021_filename.csv2. Be consistent with the case. Choose all lowercase vs camelCase vs with underscores is a purely personal choice.
If it's a single term use lower case, if it's a multiword cameCase does make it easy to read.
Example:
rawdata -- single termareaweeklyrawdata -- makes it bit hard to readareaWeeklyRawdata -- Multi work, using camelCase makes it easier to read.Whichever standard is followed, it should be consistent across all objects.
