--- cuppy_hub: aws cuppy_path: reference/s3/buckets-and-objects.md cuppy_section: docs cuppy_doc: JMR2-H9KZ cuppy_doc_uuid: 46a5f2ea-7d53-4b92-915a-972a496d605d cuppy_permalink: https://cuppy.io/aws/d/JMR2-H9KZ cuppy_version: 4 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/aws/docs/reference/s3/buckets-and-objects cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: c08268acafa350f607f79a74666acff69df35c0d6bc085a7d9893429750761a8 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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 `---an`, and the request sets the namespace: ``` aws s3api create-bucket --bucket ---an \ --bucket-namespace account-regional --region \ --create-bucket-configuration LocationConstraint= ``` (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 '' is wrong; expecting ''`. 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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.