What is optimal setting for multipart_threshold and mutilpart_chunksize while doing S3 multipart upload

There is no single optimal setting. The optimal values are dependent on a number of factors, including the latency and available bandwidth between the system where aws-cli is running and the S3 region in question, the amount of CPU and network capacity on the machine, and the size of the objects.

For some scenarios, no significant difference in overall performance is likely, regardless of configuration.

Perhaps more important than either of the parameters you asked about, is max_concurrent_requests. This defaults to 10.

I have a 100 Mbit/s connection to the Internet and am 80 ms away from the most distant S3 region that I use heavily. Anecdotally, I can tell you that I can upload to this region at about 5 Mbit/s per part, so by default my best case performance with default settings would be about 50 Mbit/s (5 Mbit/s × max_concurrent_requests -- your mileage may vary greatly, 5 Mbit/s is for illustration purposes only).

If I increase max_concurrent_requests I will increase my net transfer speed approximately linearly, until I max out a resource (most likely, my 100 Mbit/s connection). However, increasing max_concurrent_requests beyond total_upload_size ÷ multipart_chunksize would result in no further gains. If I increase max_concurrent_requests to a ridiculously large value, I'll saturate my connection beyond reliability, and packet drops will cause errors, retries, retransmission, and other inefficencies -- thus there are diminishing returns on how much I can increase this and have it be beneficial.

Independently, jncreasing multipart_chunksize will tend to improve my performance and decreasing it will degrade this, but only by small degrees, because I'll spend proportionally less or more time in housekeeping compared to actually transmitting data -- so a larger multipart_chunksize will be better if my connection is fast and clean. It will be worse if my connection is slow and error-prone. Multipart uploads can recover from failed part-uploads, but the minimum retransmission unit after a hard failure is multipart_chunksize -- So a larger value increases the amount I have to retransmit, in order to recover from hard errors. (This refers to part requests that fail entirely, not TCP retransmission, which are of course much smaller.)

There is a clear interaction among total_object_size, max_concurrent_requests, and multipart_chunksize.

The least "interesting" parameter is multipart_threshold, which is the object size at which the multipart mechanism is even engaged: objects smaller than multipart_threshold will not use multipart. On a fast, clean connection, increasing this value may be advisable, but beyond some threshold, larger values will mean slower transfers, because it will mean we don't use the paralellelism allowed by multipart.

For a 2 TB file, any value of multipart_chunksize below 200 MB will have no meaning, because multipart requires that a single file be uploaded in not more than 10,000 distinct parts, and 200 MB × 10,000 is 2 TB. Smaller values may actually be invalid and result in an error, unless aws-cli silently overrides your specification and uses a larger value, because the 10,000 part maximum is imposed by the S3 service, itself. Untested.

For a 2 TB file, multipart_threshold has no impact, because multipart is mandatory for objects exceeding 5 GB total size.

For a 2 TB file, max_concurrent_requests should be set as high as your connection can sustain, for optimal throughput. You will need a mechanism to monitor your bandwidth usage in order to titrate this to an optimal value.