S3 EntityTooLarge: The 5 GB Wall, Not the 50 TB Limit

EntityTooLarge: Your proposed upload exceeds the maximum allowed size rarely means your file is too big for S3 to store. Objects can now reach 50 TB, so the 5 TB number that most guides still quote went stale on December 2, 2025. The wall you actually hit is smaller: one upload request tops out at 5 GB, so a 6 GB file sent in one piece fails while the same file sent as a multipart upload goes through. Use multipart, keep every part between 5 MiB and 5 GiB, and stay at or under 10,000 parts.

Jake found out on a Saturday. The backup script for his shop's counter-camera footage had been calling aws s3api put-object every night. After a busy week of phone-case sales the footage file had grown to 7 GB, and three nights of backups had failed with the error above while nobody was reading the log. The recorder's disk picked that same weekend to start clicking. A customer dispute over a returned phone is settled by that footage, and it was sitting on exactly one dying disk.

Ethan explained it in thirty seconds. “A single upload request is one parcel through the mail slot,” he said. “The slot takes up to 5 GB. Anything heavier has to travel in numbered boxes, and S3 assembles the boxes on the other side. That is a multipart upload. The command you used only knows how to push parcels through the slot.”

Which EntityTooLarge do you have? Start with the operation name

S3 uses one error code for several different mistakes, so the fix depends on which call failed. Your tool almost always prints the call name. In the AWS CLI it looks like An error occurred (EntityTooLarge) when calling the PutObject operation: Your proposed upload exceeds the maximum allowed size. The words between “calling the” and “operation” are the part that matters. If your tool hides them, run the command again with --debug and read the request lines.

One more clue: S3 returns EntityTooLarge as an HTTP 400 Bad Request. If what you got back was a 413, something in front of S3 (a proxy, a load balancer, an API layer you put in the middle) answered before S3 did, and this post is not about that error.

If the table did not settle it, answer three questions in order. The first “yes” is your cause.

1. Is the failing file bigger than 5 GB, and is it going up in one request? That is Cause 1. A presigned PUT URL, s3api put-object and a plain SDK put call all land here.
2. Is the file small, and does it fail only from a web page? Look at the size cap in the signed policy (Cause 4).
3. Are you already using multipart? Then divide the file size by your part size. More than 10,000 means Cause 6. A single part over 5 GiB means Cause 2.

The S3 upload limits as of September 30, 2026

Keep this table open while you debug. Every number in it belongs to a request, a part or an object, not to your account or your Region, so there is no dial in your account to turn. You change your upload method instead.

Two things in that table surprise people. First, 50 TB and 48.8 TiB are the same ceiling described two ways: 10,000 parts times 5 GiB is 50,000 GiB, which is about 48.83 TiB. Second, the multipart path is the only way past 5 GB, so “can S3 hold my file?” and “can my tool send it?” are two separate questions. S3 can hold almost anything you own. Your tool decides whether it arrives.

The last two rows are settings on your machine, not S3 rules. They decide when your CLI stops sending one parcel and starts sending boxes.

Cause 1: one PutObject request over 5 GB

This is the one behind most searches for this error. A PutObject call (S3's name for “store this file in one shot”) sends the whole file in a single request, and a single request can carry up to 5 GB. A 4.9 GB file passes. A 5.1 GB file gets EntityTooLarge. The bytes never get partway in; the request is refused.

The trap is that several friendly-looking tools are really one PutObject underneath:

• The low-level CLI command. aws s3api put-object maps straight to the single request. It never switches to multipart.
• A presigned PUT URL. A presigned URL is a web address with a signature baked in, so someone without AWS credentials can upload to one exact key. A presigned PUT is still one PUT request, so it still stops at 5 GB.
• Hand-written code. A script that reads a file and calls the SDK's plain put method, or a curl command with -T, sends one request.
• Backup and sync software configured with a part size that is too large or with multipart turned off.

The high-level command is the opposite. aws s3 cp and aws s3 sync switch to multipart automatically when a file reaches the threshold, which defaults to 8 MB. So the same 7 GB file that dies under s3api put-object uploads fine under s3 cp.

aws s3api put-object --bucket amzn-s3-demo-bucket --key footage/week-38.mp4 --body week-38.mp4
# An error occurred (EntityTooLarge) when calling the PutObject operation: Your proposed upload exceeds the maximum allowed size

aws s3 cp week-38.mp4 s3://amzn-s3-demo-bucket/footage/week-38.mp4

Ethan had an opinion about this, and he is not shy with opinions. “s3api is a scalpel. You wanted a shovel. Use it when you need one exact API call with exact flags, and use s3 cp when you just want the file to arrive.”

Jake pushed back the way he does. “So why does s3api even exist if it can't do a big file?” Ethan shrugged. “It can. You just have to do the boxes yourself. There is a section for that further down, and I would only read it if s3 cp is not an option for you.”

When the data comes from a pipe, not a file

Backups often stream: a database dump piped straight into S3 so no temporary file is written. The CLI can do that with a dash as the source, and here the size is unknown when the upload starts. For a stream over 50 GB you must tell the CLI the expected size in bytes, or the upload can fail once it runs out of parts.

mysqldump shopdb | gzip | aws s3 cp - s3://amzn-s3-demo-bucket/db/shopdb.sql.gz --expected-size 54760833024

That number is 51 GiB written out in bytes. Use your own best estimate, and round up. High is harmless; too low breaks the upload.

Cause 2: a single part over 5 GiB (UploadPart)

If the failing call is UploadPart, you already found multipart, and you are one step short of using it correctly. A part is one numbered box in the shipment, and each box has its own size limit: at least 5 MiB (except the last box) and at most 5 GiB.

The classic version of this mistake is a manual script that splits a 60 GB file into four pieces of 15 GB each. Four parts sounds tidy, but each piece is three times the 5 GiB ceiling, so the first upload-part call fails with EntityTooLarge. The fix is more, smaller parts. Sixty GB in 1 GiB parts is 60 parts, comfortably under 10,000.

Very large parts have a second cost that people miss. When the AWS Common Runtime (CRT, AWS's faster C-based transfer engine) uploads from a memory stream, it holds each part in memory, up to 5 GB per part. A handful of parts in flight at once with huge part sizes can eat a small server's RAM before any error appears. Bigger parts are not automatically better; they are just fewer.

The opposite mistake has its own error. A non-final part smaller than 5 MB makes the completing step fail with EntityTooSmall, the mirror image of this error. Both are in the failure-mode table further down.

Cause 3: copying or moving an object over 5 GB

People hit this one after the upload already worked. You have a 12 GB object in S3, you want it in another bucket or under a new name, and the copy fails. The message often reads as an InvalidRequest about the copy source being too large, which is why a search for EntityTooLarge misses it. CopyObject is a single request that copies a source of up to 5 GB. Bigger sources need a multipart copy, built from a call named UploadPartCopy that copies slices of the source inside S3 without downloading anything to your machine.

A move is a copy followed by a delete, and a rename works the same way, so renaming a large object or changing its storage class or encryption from the console counts too. The console can copy objects below 5 GB. Above that, use the CLI or an SDK.

aws s3 cp s3://amzn-s3-demo-bucket/footage/week-38.mp4 s3://amzn-s3-demo-archive/footage/week-38.mp4
aws s3 mv s3://amzn-s3-demo-bucket/footage/week-38.mp4 s3://amzn-s3-demo-bucket/archive/week-38.mp4

The high-level s3 cp and s3 mv commands switch to multipart operations for copies too, once the object reaches the threshold. If you call the low-level copy-object command directly, you are back to the 5 GB single-request rule.

A few details are worth knowing before you run a big copy:

• Use multipart for the copy, not the console, if you care about how the object was built. An object uploaded in parts keeps its performance benefit only if you copy it with multipart through the CLI or an SDK, not through the console.
• The CRT transfer client does not do S3-to-S3 copies. If you have turned it on, the CLI falls back to the classic client for copies, so do not be surprised when the CRT settings do nothing there.
• Copies between Regions are billed. There is no data transfer charge for a copy inside one Region, but a copy between Regions is charged at the rates on the S3 pricing page.
• Thousands of big objects? A batch job that calls a Lambda function to copy each large object is a known pattern, with one catch: Lambda has a 15-minute time limit, and a very large cross-Region copy may not finish inside it.

Cause 4: a browser upload with a size cap in its policy

This is the cause the shortest guides skip, and it explains the most confusing version of the problem: small files work, a 300 MB file fails, and nothing on the server is anywhere near 5 GB.

When a web page lets visitors upload straight to S3 with an HTML form, your server signs a POST policy, a small JSON document that lists the rules for that one upload. One of the rules can be content-length-range, the smallest and largest file size the policy allows. A policy that allows 1 MiB to 10 MiB looks like this:

["content-length-range", 1048576, 10485760]

A file outside that range is refused, on the small side and on the large side. If somebody set the maximum years ago to fit the photos people uploaded then, larger files will be turned away no matter how much room S3 has. Ethan called it the most honest error in the post. “Somebody wrote that number in 2019, when a big upload meant a photo of a cracked screen. It is doing exactly what it was told.”

How to confirm this is your cause:

1. Find the code that builds the policy. Look for the string content-length-range.
2. Read the second number. It is the maximum, in bytes.
3. Compare it to the failing file, in bytes. If the file is bigger, that is your answer.

The fix is to raise the maximum where the policy is generated, then deploy. Nothing changes in S3 or in your bucket settings. Keep in mind that a form POST is still one request, so a very large file needs a different design: give the browser a multipart upload to drive instead of a single form. A separate, neighboring error appears if the fields in your form that come before the file are too large: MaxPostPreDataLengthExceededError. That one is about the form, not the file.

Cause 5: the 5 TB ceiling that no longer exists

Here is the popular advice that is wrong: “The maximum S3 object size is 5 TB, so split anything bigger.” It was true until December 1, 2025. On December 2, 2025 the maximum object size became 50 TB, a tenfold increase, for all storage classes and all S3 features. It covers every Region except the AWS GovCloud (US) Regions.

Stale copies of the old number are everywhere: older blog posts, wiki pages, comments inside your own code, validation checks in libraries and in-house tools, and sample programs. Some published code samples, including ones in the official SDK code library, still tell you to use “the multipart upload API (5TB max)” when they catch this error. If your app prints a 5 TB message when S3 returns EntityTooLarge, that sentence was typed by a person years ago. It is not S3 talking. The only real reasons a very large upload fails are the two limits from the table: a part over 5 GiB, or more than 10,000 parts.

To go past 5 TB, use the S3 Transfer Manager in the Java v1 and v2 SDKs, in the Python SDK or in the AWS CLI, with the latest CRT for the best performance. Take that list seriously: a tool that predates the change may plan its parts around the old ceiling, and a tool that does not use the transfer manager may not plan its parts at all.

Here is what a big object looks like in part-size terms. Suppose you have a 6 TiB file, which is 6,291,456 MiB. Ten thousand parts is the most you can have, so each part must be at least 6,291,456 divided by 10,000, which is about 629.15 MiB. Round up to a friendly number such as 640 MiB and you get 9,831 parts. Nothing in that plan is close to the 5 GiB part ceiling, and nothing needs a special S3 setting. It only needs a client that picks part sizes on purpose.

Cause 6: too many parts, and the chunk size math

The last limit is the one that gets you when a file is huge and your part size is small. A multipart upload can have at most 10,000 parts, numbered 1 to 10,000. Multiply your part size by 10,000 and you have the biggest file that part size can carry.

The rule fits on one line: number of parts = file size divided by part size, rounded up, and it must be 10,000 or fewer. Turn it around and you get the smallest part size that works: file size divided by 10,000.

I treated MB and MiB as the same thing in that table. None of the yes/no answers change if you use decimal MB.

The friendly news: the AWS CLI does this math for you. If the part size you configure does not fit within S3's multipart limits, the CLI adjusts it to a valid value on its own. So a plain aws s3 cp of a 100 GiB file with the default 8 MB part size does not fail on the parts limit. Where you get burned is anywhere that does not adjust for you: a hand-written script, a tool with a fixed part size, or a stream whose size the CLI cannot see, which is why the --expected-size flag exists.

Here is a sensible rule of thumb for tuning: for files above 1 GB, raise the part size to somewhere between 16 and 64 MB while keeping the total under 10,000 parts, and raise concurrent requests to something in the range of 20 to 50 on a fast connection with enough memory. Treat those as starting points: bigger parts mean fewer requests, smaller parts mean less to resend when a connection drops.

The console route, step by step

If your file is 160 GB or less and you are sitting at a browser, the console is the least effort. You do not choose part sizes; the console handles that. The catch is the 160 GB ceiling and the fact that a browser tab is a fragile place to run a very long transfer.

1. Sign in to the AWS Management Console and open the Amazon S3 console.
2. In the left navigation pane, choose Buckets.
3. In the Buckets list, choose the name of the bucket you want to upload to.
4. Choose Upload.
5. In the Upload window, drag and drop the file, or choose Add file, pick the file and choose Open.
6. If you need a different storage class, encryption setting, tags or metadata, expand Properties and set them now, because changing them later makes a new copy of the object.
7. Choose Upload, wait for the success message on the Upload: status page, and choose Exit.

If the file is larger than 160 GB, the console will not take it. Move on to the CLI. Console browsing and uploading produce normal S3 requests, billed at the usual rates.

The CLI route, step by step

For a server, a script or anything over 160 GB, the CLI is the right tool. Jake's bucket, by the way, is named after his shop cat. Ethan pointed out that the cat has better uptime than the recorder. Everything below uses the placeholder name amzn-s3-demo-bucket; swap in your own.

1. Update the CLI first. Version 1 of the AWS CLI entered maintenance mode on July 15, 2026 and reaches end of support on July 15, 2027. The settings below come from the version 2 reference, so if aws --version shows 1.x, install version 2 before you tune anything.
2. Use the high-level command. aws s3 cp for one file, aws s3 sync for a folder. They decide on multipart by themselves once a file reaches the threshold.

   aws s3 cp week-38.mp4 s3://amzn-s3-demo-bucket/footage/week-38.mp4

3. See what your CLI currently uses. If nothing prints, you are on the defaults: 8 MB threshold, 8 MB part size, 10 concurrent requests.

   aws configure get default.s3.multipart_threshold
   aws configure get default.s3.multipart_chunksize
   aws configure get default.s3.max_concurrent_requests

4. Raise the part size for big files. Bigger parts mean fewer requests. Keep the total part count under 10,000.

   aws configure set default.s3.multipart_chunksize 64MB
   aws configure set default.s3.max_concurrent_requests 20

5. Optionally switch to the CRT-based transfer client for large uploads on a fast connection. When it is on, the CLI ignores the max_queue_size and max_bandwidth settings, and you steer throughput with target_bandwidth instead. You can see whether it is active by looking for CRT lines in the debug output.

   aws configure set default.s3.preferred_transfer_client crt
   aws s3 cp large-file.zip s3://amzn-s3-demo-bucket/ --debug 2>&1 | grep -i crt

6. Check the result. Listing the key confirms the object exists and shows its size.

   aws s3 ls s3://amzn-s3-demo-bucket/footage/ --human-readable

You do not need the CRT client to fix this error. The CLI picks it automatically only on certain Linux EC2 instance types and families, and otherwise uses the classic Python-based client. Two limits are worth remembering: the CRT client cannot do S3-to-S3 copies, and it is skipped for streamed uploads from a pipe when a machine qualifies only by instance family. When a setting is not supported by the client in use, the CLI prints a warning naming what it ignored. Read those warnings.

Ethan's opinion, in one line: “Get the plain aws s3 cp working first. Tune after the file is safe.”

One setting can quietly sabotage all of this: a custom --endpoint-url. If your profile or your script overrides the endpoint, the CLI is talking to that address, not to Amazon S3. Everything in this post is about Amazon S3 itself. A NAS gateway, a self-hosted object store or another provider's S3-compatible service has its own limits, and its EntityTooLarge means whatever that vendor decided.

The manual route: s3api multipart, one call at a time

You would do this by hand when a tool gives you only raw API access, when you are learning how the pieces fit together, or when you are diagnosing a failure at a specific part. A multipart upload is three steps: start it, upload the parts, and complete it. Here is the same job with every call visible.

1. Cut the file into parts that follow the rules: 5 MiB to 5 GiB each, 10,000 or fewer in total. On Linux, split -b 1G week-38.mp4 part- makes 1 GiB pieces named part-aa, part-ab and so on.
2. Start the upload and save the upload ID, the unique identifier S3 returns for this multipart upload. Every later call needs it. You are expected to specify a checksum type when you initiate, so run aws s3api create-multipart-upload help to see the checksum options your CLI version offers.

   aws s3api create-multipart-upload --bucket amzn-s3-demo-bucket --key footage/week-38.mp4

3. Upload each part with its own part number, and write down the ETag (a fingerprint string S3 returns for each stored part) that comes back. Your part list must be in ascending order. Uploading a new part with a number you already used overwrites the old one.

   aws s3api upload-part --bucket amzn-s3-demo-bucket --key footage/week-38.mp4 --part-number 1 --body part-aa --upload-id YOUR_UPLOAD_ID

4. Write the parts file. A JSON file called parts.json that lists every part number with its ETag, in order. Build it from the responses you saved yourself. Do not build it from a list-parts response, because the listing leaves out parts that have not finished uploading.

   {"Parts": [
     {"ETag": "etag-of-part-1", "PartNumber": 1},
     {"ETag": "etag-of-part-2", "PartNumber": 2}
   ]}

5. Complete the upload. S3 stitches the parts together in part-number order and creates the object.

   aws s3api complete-multipart-upload --bucket amzn-s3-demo-bucket --key footage/week-38.mp4 --upload-id YOUR_UPLOAD_ID --multipart-upload file://parts.json

6. If it goes wrong, stop the upload. An unfinished multipart upload keeps its parts, and you keep paying for them. Abort it with aws s3api abort-multipart-upload using the same bucket, key and upload ID.

If you use checksums, part numbers must be consecutive and start at 1. Try to complete an upload with gaps in the numbering and S3 returns an HTTP 500 error rather than a helpful message. Without checksums, gaps are allowed (1, 5 and 14 is a legal set), but I would still number your parts 1, 2, 3 and never think about it again.

Here is the table of neighbors: the other errors you can hit in the same steps, and what each one means.

Fixing it in code: use the SDK's transfer manager

If the failing call lives in your application, do not rebuild the CLI by hand. Every major SDK ships a high-level uploader that decides on multipart, splits the data, uploads parts in parallel and completes the upload. The names differ by language, and the idea is the same everywhere:

• Java: the S3 Transfer Manager, ideally on top of the CRT-based S3 client, which performs a multipart upload transparently when the content is over a threshold.
• JavaScript: the Upload class from @aws-sdk/lib-storage, called with an S3 client and the body.
• Go: the upload manager, which breaks large data into parts and uploads them concurrently.
• PHP: the MultipartUploader class.
• Python and the CLI: the S3 Transfer Manager, which is also what you need for files beyond 5 TB.

Swap the one-shot put call for the uploader and pass it a file or a stream. Keep three things in mind while you do:

1. Choose the part size on purpose for huge inputs. Divide the expected size by 10,000 and round up to get the floor. A streaming source with an unknown length is the usual reason a good uploader still runs out of parts.
2. Watch memory when uploading from a stream. With CRT, a memory stream is buffered part by part, up to 5 GB per part. Uploading from disk avoids most of that, because CRT switches to direct disk streaming for large objects.
3. Handle failure by aborting. If the program crashes mid-upload, the parts stay behind. Put an abort in your error path, and put the lifecycle rule from the cleanup section on the bucket as a safety net.

Jake asked whether he should hire a developer to “fix the script.” Ethan laughed. “It is a one-line change: put-object becomes cp. Save the developer for the customer who wanted last Tuesday's invoice yesterday.”

What a big upload costs: a worked example with real numbers

Prices in this post are US East (N. Virginia) unless I say otherwise, and they are the ones on the S3 pricing page as of September 30, 2026. S3 counts storage in binary gigabytes, where 1 GB is 2 to the 30th power bytes, so I will write GiB when I do the arithmetic to keep it honest.

Say Jake adds four cameras next quarter and his weekly full backup grows to 200 GiB. That is 204,800 MiB. Here is what the upload looks like.

Read the table from the top. With the default part size, this file would need 25,600 parts, and the CLI would quietly bump the part size to fit. With 64 MiB parts you get 3,200 parts and 3,202 requests. For scale, a 100 GB upload in 100 MB parts is 1,002 requests: one to start, 1,000 parts, one to finish.

The last two rows are optional. S3 Transfer Acceleration is a paid feature that routes your upload through a nearby AWS edge location for a faster path over long distances. It costs $0.04 per GB when the edge is in the United States, Europe or Japan, and $0.08 per GB at any other edge, on top of the normal charges. The upload itself is not charged: data coming in from the internet is free. And if S3 decides acceleration would not be faster for a given transfer, you are not charged for the acceleration on that transfer.

Bills are not only about bytes that arrive, though. Bytes that do not arrive can cost too:

Two comforts are worth knowing. Stopping a multipart upload deletes the parts, and you are not billed for them afterward. There are also no early-delete charges for removing incomplete multipart uploads, whatever the storage class. So the cleanup below costs nothing and only saves money.

Leftover parts: find them, abort them, stop them coming back

After you fix the upload method, do this once. The old failed attempts may still be sitting in the bucket as unfinished uploads.

Find what is in progress

aws s3api list-multipart-uploads --bucket amzn-s3-demo-bucket --query 'Uploads[].[Key,UploadId,Initiated]' --output text

Each request returns at most 1,000 uploads. If your bucket has more, repeat until the list comes back empty. To look inside one upload, aws s3api list-parts with the same bucket, key and upload ID shows what has landed so far, 1,000 parts per response.

Abort the ones you do not need

aws s3api abort-multipart-upload --bucket amzn-s3-demo-bucket --key footage/week-38.mp4 --upload-id YOUR_UPLOAD_ID

Stop an upload only after all its part uploads have finished. Part uploads in flight when you abort can still succeed or fail afterward, and once an upload is stopped you cannot upload a part to it again. To be certain you freed everything, wait until nothing is still sending, abort, then list again.

Make the bucket clean up after itself

A lifecycle rule is a standing instruction on a bucket that S3 carries out on a schedule with no server of yours involved. The AbortIncompleteMultipartUpload action stops any multipart upload that is not completed within a number of days after it started, and S3 deletes the parts. It applies to uploads that already exist as well as future ones. It never touches a completed upload, and it never deletes objects. The example rule uses 7 days. Pick a number longer than your slowest legitimate upload.

In the console:

1. Open the S3 console, choose Buckets, and choose your bucket.
2. Choose the Management tab, then Create lifecycle rule.
3. Enter a rule name, then pick the scope: the whole bucket (and check the acknowledgment box) or a prefix.
4. Under Lifecycle rule actions, select Delete expired object delete markers or incomplete multipart uploads, then select Delete incomplete multipart uploads.
5. Enter the number of days, for example 7, and choose Create rule.

With the CLI, save this as lifecycle.json:

{
    "Rules": [
        {
            "ID": "abort-stale-multipart",
            "Status": "Enabled",
            "Filter": { "Prefix": "" },
            "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
        }
    ]
}

aws s3api put-bucket-lifecycle-configuration --bucket amzn-s3-demo-bucket --lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle --bucket amzn-s3-demo-bucket

My own advice: run the get-bucket-lifecycle command before the put, and if the bucket already has rules, add the new rule to that file instead of sending a file that contains only the new one. The command applies the configuration you hand it, and a rule you forgot about should not disappear because of a cleanup rule.

If you want a one-time sweep of every unfinished upload in a bucket, this loop lists them and aborts each. Read the warning under it first.

aws s3api list-multipart-uploads --bucket amzn-s3-demo-bucket --query 'Uploads[].[Key,UploadId]' --output text | while read -r KEY UPLOAD_ID; do
  aws s3api abort-multipart-upload --bucket amzn-s3-demo-bucket --key "$KEY" --upload-id "$UPLOAD_ID"
done

Region, account and permission edge cases

These are the cases where the same command works on one machine and not another. None changes the size limits; they change whether your upload can finish.

Which Regions get 50 TB

All AWS Regions except the AWS GovCloud (US) Regions. If you run in GovCloud, see the warning in Cause 5.

Cross-account and who is allowed to do what

A multipart upload is several calls, so it needs several permissions, and the one people forget is the permission to clean up after themselves. Cross-account uploads add a wrinkle: the bucket owner has to let the person who started the upload keep going. Ethan keeps this table taped inside his desk drawer.

Missing permissions do not produce EntityTooLarge; they produce access errors. They matter here because a fix that works for your admin account can fail for the role that actually runs the job. KMS is AWS Key Management Service, and SSE-KMS means the bucket encrypts each object with a key you control. IAM is the permission system that decides which user or role may call which S3 action.

Directory buckets and S3 Express One Zone

Directory buckets, which hold objects in the S3 Express One Zone storage class, have their own page on using multipart uploads. Read it before you carry general-purpose advice over to them.

Two uploads to the same key

Starting a second multipart upload for a key while the first is still open is legal. In a bucket with versioning turned on, the upload that started most recently is the one that becomes the current version, even if it finishes before the other. In a bucket without versioning, another request that arrives between the initiate and the complete can take precedence. A Lambda that only misbehaves at month-end, when the accountant's export overlaps the nightly job, is the usual way to meet this in real life.

Checksums and older SDKs

If you use an older SDK and your uploaded object has no checksum specified, S3 uses the CRC-64/NVME algorithm. If you supply a full-object checksum and it does not match what S3 computes, the request fails with BadDigest. Neither changes a size limit.

When nothing works: what to gather before you open a support case

If you have switched to multipart, the parts fit the limits and the error persists, the cause is in your setup rather than in the size rules. Work this list before you write to anyone. It is also what a support engineer will ask for.

1. The exact error text and the operation name. Copy it, do not retype it. EntityTooLarge on PutObject and EntityTooLarge on UploadPart lead to different answers.
2. The full response your tool logged, including the request ID values inside it and the time it happened.
3. The command or code that ran, with secrets removed, and its version (aws --version or the SDK version).
4. The file size in bytes, the part size you used and the arithmetic for how many parts that makes.
5. Region, bucket name, key and storage class. Say whether the bucket is a general purpose bucket or a directory bucket.
6. Your CLI config from the three aws configure get commands above, and whether --endpoint-url is set anywhere.
7. A debug run of one failing attempt with --debug, trimmed to the failing request and its response.
8. The listing of in-progress uploads for the bucket, so anyone helping can tell whether stale uploads are involved.

Here is what I cannot do for you, and what support can and cannot do. I cannot see your account, so I cannot tell whether your bucket is in a GovCloud partition or behind a proxy that rewrites requests. Support can read the request trail on the S3 side, tell you which limit a specific request hit, and confirm behavior for your Region. The size numbers on the multipart limits page are what your client has to fit inside, and I do not know of anything a case can do to change them. If somebody else owns the bucket and will not adjust the bucket policy, and the failure is a permission error, you are not getting in from your side.

If your bucket or account is managed by an organization, ask the owner whether a policy is blocking multipart actions such as aborting uploads. A service control policy or a VPC endpoint policy can deny a call that your own IAM policy allows.

Questions people actually type

What does EntityTooLarge mean in S3?

S3 refused a request because something in it was bigger than allowed: a single upload over 5 GB, a part over 5 GiB, a copy source over 5 GB, or a file over the size cap in a browser-upload policy. It comes back as an HTTP 400. Read the operation name in the message to see which one you hit.

What is the maximum file size you can upload to S3 in 2026?

The maximum object size is 50 TB, in all Regions except the AWS GovCloud (US) Regions, since December 2, 2025. Anything over 5 GB must go up as a multipart upload. The S3 console takes one file up to 160 GB. The multipart limits page lists the ceiling as 48.8 TiB.

Why do I get EntityTooLarge when my file is under 5 TB?

Because 5 TB is not the limit that stopped you. A single upload request maxes out at 5 GB, so a 6 GB file sent in one piece fails. Switch to multipart upload. The old 5 TB object ceiling was raised to 50 TB on December 2, 2025.

How do I fix Your proposed upload exceeds the maximum allowed size with the AWS CLI?

Use aws s3 cp instead of aws s3api put-object. The high-level command switches to multipart automatically above 8 MB. For a piped stream over 50 GB, add --expected-size with the size in bytes. If aws --version shows 1.x, move to version 2 first.

What is the S3 multipart upload threshold?

Multipart is the right tool from about 100 MB and the only way past 5 GB. The AWS CLI switches at 8 MB by default, through the multipart_threshold setting. Multipart works for objects from 5 MB up to the maximum object size. Other tools ship their own defaults.

What is the maximum part size for S3 multipart upload?

5 GiB. The minimum is 5 MiB for every part except the last, which has no minimum. A part over 5 GiB fails with EntityTooLarge on UploadPart, and a part other than the last that is under the minimum fails with EntityTooSmall when you complete the upload.

How many parts can an S3 multipart upload have?

10,000, numbered 1 to 10,000. Divide your file size by 10,000 to find the smallest part size that fits. Ten thousand parts of 5 GiB each is the 48.8 TiB ceiling. The AWS CLI raises its part size on its own when the configured size would not fit.

Why does aws s3 cp work for big files but put-object fails?

aws s3api put-object sends one PutObject request, which is capped at 5 GB. aws s3 cp is the high-level command, and it switches to multipart once a file reaches the threshold, 8 MB by default. Same bucket, different method.

How do I upload a file larger than 160 GB to S3?

Not through the console, whose limit is 160 GB per file. Use the AWS CLI, an AWS SDK or the REST API with multipart upload. For objects beyond 5 TB, use the S3 Transfer Manager in the Java, Python or CLI tools, with the latest CRT.

EntityTooLarge is still happening after I turned on multipart, what now?

Read the operation name. If it is UploadPart, one part is over 5 GiB, so use more and smaller parts. If the file is huge, the upload may be running out of parts, so raise the part size. If a message insists the maximum is 5 TB, that text is stale, not S3.

How do I copy an S3 object larger than 5 GB?

Use a multipart copy. A single copy request stops at 5 GB, and many clients report the failure as an InvalidRequest about the copy source. aws s3 cp and aws s3 mv between S3 locations switch to multipart for you once the object reaches the threshold, and the SDKs use the UploadPartCopy call. The console copies only objects under 5 GB. For bulk jobs, S3 Batch Operations with a Lambda function is a known route.

How do I set a maximum upload size for presigned POST uploads?

Add a content-length-range condition to the POST policy. It holds the minimum and maximum size in bytes, for example 1048576 and 10485760 for 1 to 10 MiB. If large files fail, raise the maximum in the code that generates the policy.

Do incomplete multipart uploads cost money?

Yes. S3 keeps uploaded parts and bills for their storage until you complete or stop the upload, and nothing expires them on its own. A lifecycle rule with AbortIncompleteMultipartUpload deletes them after the number of days you set, with no early-delete charge.

How do I find and delete incomplete multipart uploads in S3?

List them with aws s3api list-multipart-uploads --bucket your-bucket, then stop each one with aws s3api abort-multipart-upload using its key and upload ID. To automate it, add a lifecycle rule in the Management tab and choose Delete incomplete multipart uploads.

Why do I get EntityTooSmall on CompleteMultipartUpload?

A part other than the last one is under the 5 MB minimum. Rebuild the upload with larger parts, or with fewer parts, so every part except the final one reaches at least 5 MiB. The last part has no minimum size.

Is the S3 5 TB limit really gone, and does 50 TB apply in GovCloud?

The 5 TB limit is gone in all Regions except the AWS GovCloud (US) Regions. Since December 2, 2025 the maximum is 50 TB in every other Region. In GovCloud the increase does not apply, so keep 5 TB as your working assumption until you see a higher number for your partition.

If you are reading this with a red error in one window and a nervous backup in the other, take a breath: your data is not too big for S3, and the fix is almost always a one-line change in how it gets there. Jake did two things the following Monday. He swapped put-object for cp, and he bought a second disk for the recorder. The mail slot is still 5 GB wide; his footage just does not travel through it anymore. If you hit a case this page does not cover, tell me and I will add it.

Revision note. Written September 30, 2026, with the 50 TB ceiling in place. If a backup failed quietly for days while you were busy running a business, that's a very ordinary way to meet this error.