Buckets and objects

Bucket names are global within a partition and permanent; objects are strongly consistent; large objects go through multipart upload. These facts are stable. The adjustable numbers (buckets per account and so on) are quotas: read them live.

Bucket names

• 3–63 characters: lowercase letters, digits, . and -; start and end with a letter or digit; no ..; not an IP address.
• Reserved prefixes: xn--, sthree-, amzn-s3-demo-. Reserved suffixes: -s3alias, --ol-s3, .mrap, --x-s3 (directory buckets), --table-s3 (S3 Tables); -an only in the account regional namespace.
• Avoid dots: names with periods cannot use virtual-hosted HTTPS without your own certificate validation, and cannot use Transfer Acceleration. (Static website hosting, which is HTTP-only, is the exception.)
• A bucket's name and Region cannot be changed. Do not put sensitive information in a name: it appears in URLs.

Shared namespace and name reuse

General purpose buckets share one namespace per partition (aws, aws-cn, aws-us-gov, aws-eusc). Once you delete a bucket, another account can create the same name and receive requests meant for yours. To retire a bucket safely, empty it and keep it.

Account regional namespace

You can instead create buckets in a namespace only your account can use, so the name can never be taken by another account. The name must end with -<account-id>-<region>-an, and the request sets the namespace:

aws s3api create-bucket --bucket <prefix>-<account-id>-<region>-an \
  --bucket-namespace account-regional --region <region> \
  --create-bucket-configuration LocationConstraint=<region>

(HTTP header: x-amz-bucket-namespace: account-regional.) These buckets support the same features.

Consistency

S3 is strongly consistent for all objects in all Regions, at no extra cost: after a successful write, overwrite or delete, subsequent reads and listings return the new state; changes to metadata, tags and ACLs are also strongly consistent. Code that sleeps or retries to wait for eventual consistency (a common pattern before December 2020) is unnecessary.

Size limits

Item	Limit
Maximum object size	48.8 TiB (announced as 50 TB, December 2025; previously 5 TB)
Multipart parts per upload	10,000 (part numbers 1–10,000)
Part size	5 MiB – 5 GiB; the last part has no minimum
Parts per ListParts / uploads per ListMultipartUploads response	1,000
CopyObject in one request	objects up to 5 GB; larger needs multipart copy

AWS suggests multipart upload once objects reach about 100 MB. The largest single-request PUT was not stated in the sources read; treat 5 GB, the part-size ceiling, as the working limit and use multipart above it (UNVERIFIED as a PUT limit).

Regions and addressing

Every bucket lives in one Region; send requests to that Region.

• Wrong Region endpoint → PermanentRedirect (301). In the AWS SDK for JavaScript v3, followRegionRedirects: true on the client follows it, at the cost of an extra round trip; use it only when you cannot know the Region in advance.
• Signed for the wrong Region → AuthorizationHeaderMalformed: … the region '<x>' is wrong; expecting '<y>'. Requests to the global endpoint s3.amazonaws.com must be signed for us-east-1. If both endpoint and region are set on an SDK client, the endpoint wins.
• BucketAlreadyOwnedByYou (409) on create is returned in every Region except us-east-1.

Checksums on by default (SDKs since December 2024)

Current SDKs and the CLI compute a CRC checksum on every upload and validate it on download: the JavaScript v3 SDK uses CRC32 and CLI v2 uses CRC64NVME. S3 stores the checksum with the object. Both behaviours default to WHEN_SUPPORTED. Set WHEN_REQUIRED with request_checksum_calculation / response_checksum_validation in ~/.aws/config, or the AWS_REQUEST_CHECKSUM_CALCULATION / AWS_RESPONSE_CHECKSUM_VALIDATION environment variables, or the client options, to compute them only where an operation requires it. That is the usual fix when the same code talks to an S3-compatible store that rejects the new checksum headers (patterns/alternatives/s3-compatible-storage.md).

Newer capabilities to know about

• S3 Files (April 2026): NFS v4.1 access to a general purpose bucket from EC2, ECS/EKS (including Fargate) and Lambda. File-system changes reach the bucket within minutes; bucket changes usually appear in seconds but can take a minute or more. File permissions come from POSIX UID/GID stored as object metadata. Do not assume an object written through S3 Files is visible to an S3 reader immediately.
• 0-day transitions (July 2026): lifecycle rules can move objects to S3 Standard-IA or One Zone-IA on the day they are created. Whether minimum storage-duration charges still apply was not stated; check pricing before relying on it.