Limits and errors
The per-upload size limit and multipart guidance, what happens when a bucket is full or the capacity pool is exhausted, common causes of 403 AccessDenied, and the S3 error codes you will see.
Current limits
| Limit | Value |
|---|---|
| Single upload part | 95 MB (larger objects use multipart) |
| Object size | Effectively unbounded via multipart, within your bucket capacity |
| Addressing | Path-style only |
| Public access | None: every request must be signed with your keys |
Large objects and the 95 MB part limit
A single upload request is capped at 95 MB by the edge. That is a limit on one HTTP request, not on how large an object can be:
- Every S3 SDK, plus
aws s3 cp,rclone, andmc, automatically switches to a multipart upload for large objects, splitting them into parts under the limit and reassembling them server-side. You rarely think about it. - Only if you force a single-part PUT above 95 MB (some hand-rolled
uploads do) will the edge reject it with
413. The fix is to let your tool do a multipart upload, or set a part size at or below 95 MB.
When a bucket is full
Your bucket's booked capacity is a hard quota. When stored data reaches it, further writes are rejected until you free space (delete objects) or request more capacity via a support ticket. Reads and deletes keep working, so you can always recover space.
When the capacity pool is exhausted
Buckets book capacity from a finite regional pool. If the pool is momentarily out of room when you try to create a bucket (or ask for more capacity), the request fails with an insufficient capacity message. It is not an error in your setup: choose a smaller capacity, retry later, or open a support ticket if you need a large allocation.
Why you get 403 AccessDenied
AccessDenied is the most common error, and it almost always means the request
was signed but not allowed. The usual causes:
- Wrong or mistyped key or secret. Re-copy both from the dashboard.
- A regenerated key. Regenerating invalidates the previous secret immediately; update the app with the new one. See access keys.
- Another tenant's bucket. Credentials reach only your own buckets; targeting a bucket you do not own is denied.
- The short bucket name. Use the full prefixed name
(
t...-<name>) shown in the dashboard, not the short name you typed (using the wrong name usually surfaces as404 NoSuchBucket).
S3 error codes
Because the service is S3-compatible, your client already understands these standard error codes:
| HTTP | Code | What it means / what to do |
|---|---|---|
400 | InvalidRequest | Malformed request, for example a bad multipart part. Let your SDK build the request. |
403 | AccessDenied | Key wrong, regenerated, or aimed at a bucket you do not own. See the causes above. |
403 | SignatureDoesNotMatch | The secret is wrong, or the client clock is badly skewed. Re-copy the secret; sync the clock. |
403 | InvalidAccessKeyId | The access key is unknown or retired. Re-copy it, or regenerate the pair. |
404 | NoSuchBucket | Bucket name is wrong. Use the full prefixed name from the dashboard. |
404 | NoSuchKey | The object key does not exist in this bucket. Check the path. |
409 | BucketAlreadyOwnedByYou | You already have a bucket by that name. Reuse it. |
413 | EntityTooLarge | A single upload part exceeded 95 MB. Use a multipart upload. |
503 | SlowDown | Too many requests too fast. Back off and retry; the official SDKs retry automatically. |
Reads never expose another tenant
Isolation is enforced at the storage layer, not just in the dashboard. Even a
correct, live key cannot list or read a bucket outside your account, it gets
403 AccessDenied. Your data is only ever reachable with your own keys.