A bucket is owned by the AWS account (identified by AWS Access Key ID) 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, it can be deleted and its name can be reused.

	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.

To comply with Amazon S3 requirements, bucket names:

To conform with DNS requirements, we recommend following these additional guidelines when creating buckets:

Note

Buckets with names containing uppercase characters are not accessible using the virtual hosted-style request (e.g., http://yourbucket.s3.amazonaws.com/yourobject) If you create a bucket using <CreateBucketConfiguration>, you must follow the additional guidelines. If you create a bucket using <CreateBucketConfiguration>, applications that access your bucket must be able to handle 307 redirects. For more information, see Request Redirection and the REST API. When using virtual hosted-style buckets with SSL, the SSL wildcard certificate only matches buckets that do not contain periods. To work around this, use HTTP or write your own certificate verification logic.

There is no limit to the number of objects that can be stored in a bucket and no variation in performance when using many buckets or just a few. You can store all of your objects in a single bucket or organize them across several buckets.

Buckets cannot be nested, meaning buckets cannot be created within buckets.

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. Additionally, make sure your application has logic to choose a different bucket name if a bucket name is already taken.