A bucket is owned by the AWS account that created it. Each AWS account can own up to 100 buckets at a time. Bucket ownership is not transferable; however, if a bucket is empty, you can delete it. After a bucket is deleted, the name becomes available to reuse, but the name might not be available for you to reuse for various reasons. For example, some other account could create a bucket with that name. Note, too, that it might take some time before the name can be reused. So if you want to use the same bucket name, don't delete the bucket.
There is no limit to the number of objects that can be stored in a bucket and no difference in performance whether you use many buckets or just a few. You can store all of your objects in a single bucket, or you can organize them across several buckets.
You cannot create a bucket within another bucket.
The high-availability engineering of Amazon S3 is focused on get, put, list, and delete operations. Because bucket operations work against a centralized, global resource space, it is not appropriate to create or delete buckets on the high-availability code path of your application. It is better to create or delete buckets in a separate initialization or setup routine that you run less often.
If your application automatically creates buckets, choose a bucket naming scheme that is unlikely to cause naming conflicts. Ensure that your application logic will choose a different bucket name if a bucket name is already taken.
We recommend that all bucket names comply with DNS naming conventions. These conventions are enforced in all regions except for the US Standard region.
If you use the AWS management console, bucket names must be DNS compliant in all regions.
DNS-compliant bucket names allow customers to benefit from new features and operational improvements, as well as providing support for virtual-host style access to buckets. While the US Standard region currently allows non-compliant DNS bucket naming, we are moving to the same DNS-compliant bucket naming convention for the US Standard region in the coming months. This will ensure a single, consistent naming approach for Amazon S3 buckets. The rules for DNS-compliant bucket names are:
Bucket names must be at least 3 and no more than 63 characters long.
Bucket names must be a series of one or more labels. Adjacent labels are separated by a single period (.). Bucket names can contain lowercase letters, numbers, and hyphens. Each label must start and end with a lowercase letter or a number.
Bucket names must not be formatted as an IP address (e.g., 192.168.5.4).
When using virtual hosted–style buckets with SSL, the SSL wild card certificate only matches buckets that do not contain periods. To work around this, use HTTP or write your own certificate verification logic.
The following examples are valid bucket names:
The following examples are invalid bucket names:
|Invalid Bucket Name||Comment|
|Bucket name cannot start with a period (.).|
|Bucket name cannot end with a period (.).|
|There can be only one period between labels.|
The US Standard region currently allows more relaxed standards for bucket
naming, which can result in a bucket name that is not DNS-compliant. For
MyAWSBucket is a valid bucket name, even though it
contains uppercase letters. If you try to access this bucket by using a
http://MyAWSBucket.s3.amazonaws.com/yourobject), the URL
resolves to the bucket
myawsbucket and not the bucket
MyAWSBucket. In response, Amazon S3 will return a "bucket not found"
To avoid this problem, we recommend as a best practice that you always use DNS-compliant bucket names regardless of the region in which you create the bucket. For more information about virtual-hosted–style access to your buckets, see Virtual Hosting of Buckets.
The rules for bucket names in the US Standard region allow bucket names to be as long as 255 characters, and bucket names can contain any combination of uppercase letters, lowercase letters, numbers, periods (.), hyphens (-), and underscores (_).