| « PreviousNext » | |
   | Did this page help you? Yes | No | Tell us about it... |
Bucket Restrictions and Limitations
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, however the name might not be available for you to resuse for various reasons. For example, some other account can create a bucket with that name. So if you want to use the same bucket name, don't delete the bucket. Note that it might take some time before the name can be reused.
There is no limit to the number of objects that can be stored in a bucket and no variation 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 make bucket create or delete calls 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.
Note
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.
Note
If you are using Amazon DevPay, each of your customers can have up to 100 buckets for each Amazon DevPay product they use. For more information, see Using Amazon DevPay with Amazon S3.
Rules for Bucket Naming
In all regions except for the US Standard region a bucket name must comply with the following rules. These result in a DNS compliant bucket name.
Bucket names must be at least 3 and no more than 63 characters long
Bucket name must be a series of one or more labels separated by a period (.), where each label:
Must start with a lowercase letter or a number
Must end with a lowercase letter or a number
Can contain lowercase letters, numbers and dashes
Bucket names must not be formatted as an IP address (e.g., 192.168.5.4)
The following are examples of valid bucket names:
myawsbucketmy.aws.bucketmyawsbucket.1
The following are examples of invalid bucket names:
| Invalid Bucket Name | Comment |
|---|---|
.myawsbucket | Bucket name cannot start with a period (.). |
myawsbucket. | Bucket name cannot end with a period (.). |
my..examplebucket | There can only be one period between labels. |
The rules for bucket names in the US Standard region are similar but less restrictive:
Bucket names can be as long as 255 characters.
Bucket names can contain any combination of uppercase letters, lowercase letters, numbers, periods (.), dashes (-) and underscores (_)
These naming rules for US Standard region can result in a bucket name that is not
DNS-compliant. For example, MyAWSBucket, is a valid bucket name, with
uppercase letters in its name. If you try to access this bucket using a virtual
hosted-style request, 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
error. To avoid this problem, we recommend as a best practice that you always
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.
