S3 RequestTimeout: Fix Stalled and Slow Uploads

Amazon S3 RequestTimeout means the socket connection did not make the expected read or write progress during the service timeout period. The fix is usually to keep your upload sending bytes reliably, switch large objects to multipart upload, and investigate proxy stalls or a wrongly declared Content-Length. The counterintuitive detail is that increasing your SDK read timeout cannot extend S3's own idle limit: the two clocks belong to different sides of the connection. Identify which side failed before changing timeouts.

Jake's phone shop has a nightly repair-photo backup that is too important to gamble on a single fragile connection. A 5 GiB file gets most of the way across his shared office link and stops with RequestTimeout. He needs an approach that makes each failed request smaller while preserving enough evidence to know whether the final backup really exists.

Jake: "If I waited longer, would the same huge upload eventually make it?"

Ethan: "Not if the data stream has stopped. Split the job into parts and find out why the connection goes quiet."

Recognize the RequestTimeout error before changing anything

You may see a stalled progress bar followed by a message about a socket connection that S3 did not read from or write to within its timeout period. That is the service-side RequestTimeout response, classified as HTTP 400. The word timeout does not identify which part of the network path stopped making progress, and it is not proof that S3 has lost your object.

For an SDK request, capture the actual service error code, HTTP status, request ID, and the operation that failed. A local socket timeout from your SDK can be raised without any S3 error response at all. This distinction is worth making before increasing any knob: a server-generated RequestTimeout and a client-generated ReadTimeoutError can look similar to the person watching the upload.

Try to determine whether the request was PutObject, UploadPart, or CompleteMultipartUpload. With a one-part upload, a failed attempt means the complete object was not established by that attempt. With multipart, completed parts may still exist under an upload ID while the object is not yet available as a completed object. With a failed completion call, you must inspect the resulting object instead of assuming success or failure from the interrupted response.

Start with the smallest reproducible comparison: upload a small known file using the high-level AWS CLI, then try a moderately sized file from the same machine and network. If small requests succeed and bigger ones stall, investigate sustained throughput, idle gaps, proxies, and multipart configuration. If everything fails immediately, inspect credentials, endpoint choice, DNS, and transport errors before tuning part sizes.

An error occurred (RequestTimeout) when calling the PutObject operation:
Your socket connection to the server was not read from or written to
within the timeout period.

Choose the cause using the failure pattern

If your upload fails at almost the same elapsed time on each attempt, look for a fixed timer in an SDK, HTTP client, gateway, VPN, or corporate proxy. A repeatable stop after a particular number of minutes is more suggestive of a local or intermediate timeout than of an unpredictable wireless outage. Compare the exact failure time against configured client limits rather than attributing the duration to S3.

If the failures appear only with large single PUT requests, move first to a managed multipart transfer. A single upload attempt creates a long continuous dependency on your connection. Multipart divides the file into independently retryable requests and gives the SDK a chance to retry a smaller failed part rather than repeating the entire object.

If every upload stalls only when the office VPN is active, suspect that transport path. Corporate HTTPS inspection, idle connection management, upstream proxies, and traffic controls can interrupt a long stream. A successful transfer through another authorized network provides useful diagnostic evidence but does not prove which office component is responsible.

If a hand-built uploader fails but the AWS CLI works on the same machine, inspect request construction. Check Content-Length, the number of bytes your stream actually emits, whether the request body can be replayed on retry, and whether a producer pauses after opening the connection. The signed request, body framing, and proxy behavior all matter.

Understand how long S3 waits without inventing a timeout value

You might reasonably ask for the exact number of seconds that S3 waits before returning RequestTimeout. The public S3 error definition describes a socket connection not read from or written to during the timeout period, but it does not establish one universal idle-time duration for every operation and connection path. Giving you a single number here would make troubleshooting less reliable, not more.

Time elapsed on your stopwatch can include DNS resolution, TCP establishment, TLS setup, proxy queues, body transmission, retries, and time spent waiting for an HTTP response. Some of those clocks are controlled by your client and some by network intermediaries. Record the request start time, first byte sent, last byte sent, last response byte, and failure time if your HTTP instrumentation can expose them.

For the AWS CLI, the global --cli-connect-timeout and --cli-read-timeout options describe client socket operations. They are not settings that increase S3's service-side idle allowance. Increasing them can help when the CLI itself aborts early, but will not fix a request whose body stream stops supplying bytes.

For SDK applications, choose the timeout layer you actually need. Connection establishment and waiting for response data differ from the length of an entire transfer. Keep a finite overall policy for stalled jobs and an explicit retry budget, especially when a batch process must complete by a business deadline.

Jake: "Does a bigger timeout automatically mean a more reliable upload?"

Ethan: "No. If the stream stops feeding bytes, extending your own wait cannot make bytes appear."

Move large files to multipart instead of repeating the entire body

If the uploader still sends a multi-gigabyte object as one request, that is the first architecture decision to revisit. S3 multipart upload creates an upload ID, accepts numbered parts, and assembles the final object only when completion succeeds. It is particularly useful when a single long-lived request is vulnerable to temporary network interruption.

The high-level aws s3 cp command automatically chooses multipart transfers after its configured multipart threshold. As of October 2026, AWS CLI documentation lists an 8 MB default threshold and 8 MB default part size, and a default maximum concurrency of 10 for the classic transfer settings. Those are CLI defaults, not a server-side requirement that every SDK has to copy.

S3 multipart specifications allow up to 10,000 parts, with part sizes from 5 MiB to 5 GiB except the final part, which may be smaller. S3 increased the maximum supported object size to 50 TB in December 2025. Older explanations that identify 5 TB as the maximum size of all S3 objects are outdated; a 5 GB file in this example is well within the current multipart limits.

For extremely large objects, select a chunk size that keeps the number of parts below the limit and fits your memory and retry constraints. Very small parts mean more requests and coordination; huge parts mean each failed attempt may need to resend more bytes. A middle-ground size that keeps each part manageable usually beats either extreme on an unreliable connection.

aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 64MB
aws configure set default.s3.max_concurrent_requests 4
aws s3 cp ./archive.bin s3://amzn-s3-demo-bucket/backups/archive.bin

Tune the three AWS CLI transfer settings independently

If you are using aws s3 cp, change the S3 transfer settings rather than relying exclusively on global socket timeouts. multipart_threshold is the file size at which a high-level transfer switches to multipart. multipart_chunksize determines how much object data goes into each multipart part. max_concurrent_requests limits the number of operations that can run in parallel.

On a slow upstream connection, increasing concurrency can make a bad situation worse. Several simultaneous uploads may compete for the same constrained bandwidth, which can increase stalls and proxy pressure. Start with four concurrent operations for the worked example, compare against two and eight, and keep the setting that makes reliable progress rather than the one that simply launches the most requests.

For a 5 GiB file with 64 MiB parts, the transfer has 80 parts before accounting for other overhead. If one part fails, the transfer manager can retry that part instead of sending all 5 GiB again. A 64 MiB part also provides a natural unit for observing per-request duration and throughput on the path.

Keep in mind that AWS CLI transfer implementations can differ, including CRT-based transfer behavior. The three classic settings are documented for the CLI S3 transfer configuration, but certain transfer-client paths may handle some settings differently. Confirm which CLI version and transfer client you are using before assuming an exact concurrency value was honored.

aws s3 cp ./archive.bin s3://amzn-s3-demo-bucket/backups/archive.bin \
  --cli-connect-timeout 30 --cli-read-timeout 120

Worked example: recover a 5 GiB upload that keeps stalling

Imagine Jake has a 5 GiB archive of repair photographs for his phone shop, and he needs an overnight backup in S3. A basic uploader sends the whole archive in one operation across a shared office connection. The upload runs for a while, then reports RequestTimeout. That is a realistic diagnostic setup, not evidence that this particular network has been measured or that the problem has one universal cause.

Ethan first has Jake save the original local file and check the destination key. The repair archive is 5 GiB, or 5,368,709,120 bytes. With 64 MiB parts, it divides cleanly into 80 parts. At an illustrative 8 MiB per second of usable upstream bandwidth, raw transfer time would be about 640 seconds before protocol overhead, throttling, retries, or contention; it is not a prediction for his office network.

They set the CLI multipart threshold to 64 MB, the chunk size to 64 MB, and concurrency to four. This configuration does not magically repair broken Wi-Fi. It reduces the amount of data each failed part must resend and bounds the number of simultaneous uploads on the shared link. If there is a severe proxy limitation, the proxy still needs fixing.

After the upload command completes, they use head-object to examine the destination key and its ContentLength. If the size matches 5,368,709,120 bytes, the object exists with the expected number of bytes; for stronger integrity checks they also compare an appropriate checksum instead of assuming the multipart ETag is always the object MD5. If the upload fails, they inspect incomplete multipart uploads before deciding whether to retry, resume explicitly, or abort.

aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 64MB
aws configure set default.s3.max_concurrent_requests 4
aws s3 cp ./repair-archive.bin s3://amzn-s3-demo-bucket/backups/repair-archive.bin
aws s3api head-object --bucket amzn-s3-demo-bucket \
  --key backups/repair-archive.bin --query ContentLength

Separate a real S3 error from a boto3 ReadTimeoutError

If you write the uploader in Python, inspect the exception class rather than treating every timeout as the same failure. A botocore ReadTimeoutError is raised by the client side while waiting on an established connection. An S3 ClientError containing the RequestTimeout code is an HTTP error response from the S3 service.

The difference changes what you tune. Raising read_timeout in botocore can change when your Python HTTP client gives up waiting for bytes, but it does not extend a service idle timeout. Switching to upload_file can add managed multipart uploads and retries that a hand-built put_object operation lacks.

For a managed transfer, use TransferConfig to select multipart_threshold, multipart_chunksize, and max_concurrency. For the underlying client, use botocore.config.Config with connect_timeout, read_timeout, and a retry configuration such as mode standard and total_max_attempts. The total attempt count includes the initial attempt, which prevents off-by-one surprises when interpreting retry budgets.

Use sensible values based on expected per-part transfer time. A socket read timeout is not the same as a guaranteed total wall-clock deadline for a multi-part managed transfer. Monitor elapsed transfer time at your job level and keep evidence about which part or operation failed.

import boto3
from boto3.s3.transfer import TransferConfig
from botocore.config import Config

s3 = boto3.client('s3', config=Config(
    connect_timeout=20,
    read_timeout=120,
    retries={'mode': 'standard', 'total_max_attempts': 4}
))
transfer = TransferConfig(
    multipart_threshold=64 * 1024 * 1024,
    multipart_chunksize=64 * 1024 * 1024,
    max_concurrency=4
)
s3.upload_file('repair-archive.bin', 'amzn-s3-demo-bucket',
               'backups/repair-archive.bin', Config=transfer)

Jake: "Do I need to send the entire backup again when one part fails?"

Ethan: "With multipart, a transfer manager can retry the failed part rather than starting with the whole object."

Configure JavaScript SDK v3 with request timeouts and multipart upload

If your app uses the AWS SDK for JavaScript v3, the Node.js HTTP handler exposes connectionTimeout and socketTimeout settings. connectionTimeout applies while establishing a connection, whereas socketTimeout concerns socket activity during a request. Neither setting is a guarantee that a remote proxy will keep your upload open indefinitely.

The S3Client also accepts maxAttempts for SDK retries. Repeated requests need replayable bodies; a stream that has already been consumed may not be safe to retry as-is. For a local file or another rewindable source, prefer the high-level @aws-sdk/lib-storage Upload helper when you want multipart behavior rather than manually splitting each part.

Choose queueSize to limit concurrent parts and partSize to control each part. The Upload helper handles multipart orchestration, but your application still needs to wait for the returned promise and handle failures. Treat any object with sensitive content carefully in logs, and keep request authentication material out of your diagnostics.

If a corporate proxy is in the path, configure the appropriate approved proxy agent in your HTTP client and confirm its keep-alive and streaming behavior. A timeout change can mask symptoms without fixing a proxy that buffers or interrupts long request bodies. Compare upload behavior with the CLI from the same environment to narrow the problem.

import { S3Client } from '@aws-sdk/client-s3';
import { NodeHttpHandler } from '@smithy/node-http-handler';
import { Upload } from '@aws-sdk/lib-storage';
import { createReadStream } from 'node:fs';

const client = new S3Client({
  region: 'us-east-1', maxAttempts: 4,
  requestHandler: new NodeHttpHandler({
    connectionTimeout: 20000, socketTimeout: 120000
  })
});
const upload = new Upload({
  client,
  params: { Bucket: 'amzn-s3-demo-bucket',
    Key: 'backups/repair-archive.bin',
    Body: createReadStream('./repair-archive.bin') },
  queueSize: 4, partSize: 64 * 1024 * 1024
});
await upload.done();

Set Java SDK v2 API and socket timeouts without confusing them

If you are using AWS SDK for Java 2.x, distinguish API call timeout from API call attempt timeout. An API call timeout covers the operation across retry attempts, while an attempt timeout constrains a single try. Neither is identical to an HTTP connection timeout or socket timeout.

You can configure a synchronous S3Client with ClientOverrideConfiguration and the Apache HTTP client. Use finite timeouts that make sense for each part, and set an overall deadline large enough to include reasonable retries. For example, a two-minute overall API limit cannot accommodate three two-minute attempts.

For large files, S3 Transfer Manager or a suitable multipart facility is usually more appropriate than a single synchronous putObject. The sample client below focuses on timeout controls, not on claiming that synchronous putObject itself automatically resumes failed parts. Keep that distinction visible when turning sample configuration into production code.

If a retry repeats a multipart part, completion still requires the final ordered part numbers and ETags. Use a maintained transfer manager where possible so your application does not have to reinvent retry bookkeeping. Treat connection pool exhaustion separately from slow socket reads if many uploads share one client.

import java.time.Duration;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.core.client.config.ClientOverrideConfiguration;
import software.amazon.awssdk.http.apache.ApacheHttpClient;

S3Client s3 = S3Client.builder()
  .overrideConfiguration(ClientOverrideConfiguration.builder()
      .apiCallTimeout(Duration.ofMinutes(5))
      .apiCallAttemptTimeout(Duration.ofMinutes(2))
      .build())
  .httpClientBuilder(ApacheHttpClient.builder()
      .connectionTimeout(Duration.ofSeconds(20))
      .socketTimeout(Duration.ofSeconds(90)))
  .build();

Find the Content-Length mismatch in custom requests

If you hand-build an HTTP PUT to S3, inspect Content-Length as soon as the CLI succeeds but your client fails. An HTTP request that declares more bytes than its stream actually supplies leaves the receiver waiting for bytes that are not coming. That failure can resemble a stalled connection, especially if the stream completes early and the client leaves the connection open.

For example, consider a generator that promises 10,485,760 bytes but emits only 10,000,000. The difference is 485,760 bytes, and the declared length does not describe the body actually transmitted. You cannot trust a guessed Content-Length from an uncompressed source after an on-the-fly transformation changes the byte count.

The inverse mismatch is also a problem: a body that exceeds the declared length can be truncated, rejected, or interpreted incorrectly depending on the HTTP client and server handling. Some libraries calculate correct request framing automatically, which is another reason to prefer maintained SDKs over a homegrown uploader.

For a custom client, instrument a counting stream so you can compare the number of bytes read from the source with the number the HTTP library attempts to send. Recreate the request with a fixed file to remove live-stream variability. Keep an eye on redirects and signed headers because altering a signed request after signing can introduce a separate authorization error.

Declared Content-Length: 10485760
Actual bytes produced:   10000000
Shortfall:                 485760

# Prefer a maintained SDK that sets request framing correctly.
# If building your own body stream, count every emitted byte.

Investigate corporate proxies, VPNs, and idle sockets

If uploads fail only from an office network, find out whether the request crosses an HTTPS inspection proxy, an authenticated gateway, or a VPN tunnel. These components can buffer payloads, enforce idle connection timers, or terminate slow streams. You may not be able to change those policies yourself, but you can collect a useful comparison for the network team.

Compare a small S3 upload and a multipart upload from the same host using the same credentials, then compare an approved alternate network. Record the exact timestamps, file sizes, chosen S3 Region, transfer concurrency, and whether the proxy was in use. Ask the network administrator about long-lived outbound HTTPS requests and upload-body streaming rather than vaguely saying S3 is slow.

A proxy may also change the failure message. If the proxy closes the TCP connection before S3 replies, your SDK can report a connection reset or read timeout instead of S3 RequestTimeout. If S3 receives a partial or stalled body and responds, you may see the service error. Both outcomes can have the same upstream network root cause.

Keep TLS verification enabled and use the organization-approved trust configuration. Disabling certificate checks is not a sound timeout fix. If you need to exclude a proxy for an approved endpoint, coordinate with network and security administrators and assess whether a direct route is permitted.

Jake: "The progress bar reached the end. Is that proof the backup exists?"

Ethan: "Check completion and the destination object. A progress bar is not an integrity check."

Use Transfer Acceleration only when distance is the real problem

If clients are geographically far from the bucket and the internet path is the limiting factor, S3 Transfer Acceleration may help. It routes supported uploads through an accelerated endpoint and is aimed at long-distance transfers. It is not a general cure for a stalled request body, incorrect Content-Length, or a corporate proxy that interrupts every upload.

Transfer Acceleration applies to eligible general purpose buckets and requires a DNS-compliant bucket name without periods. The bucket must have acceleration enabled before the accelerated endpoint is used. AWS provides a speed comparison tool, which gives you a better basis for choosing the feature than assuming it always wins.

In the S3 console, open the general purpose bucket, choose Properties, edit Transfer acceleration, enable it, and save. For the CLI, use put-bucket-accelerate-configuration to enable the bucket and set use_accelerate_endpoint for the profile sending uploads. Compare actual transfer results with and without acceleration on a representative file.

Acceleration can add transfer charges beyond ordinary S3 request and storage charges, with rates depending on traffic direction and geography. Use the applicable current S3 pricing page for your Regions and traffic pattern rather than relying on a universal price. If your client is already close to the bucket, a well-tuned multipart transfer may provide the better value.

aws s3api put-bucket-accelerate-configuration \
  --bucket amzn-s3-demo-bucket \
  --accelerate-configuration Status=Enabled
aws configure set default.s3.use_accelerate_endpoint true

Resume multipart parts only when the upload ID still exists

If a multipart job fails after uploading some parts, S3 can retain those parts while the multipart upload remains open. That does not mean the complete object exists. To resume a manual multipart upload, retain the upload ID, inspect the uploaded part numbers and ETags, upload missing or replacement parts, and send a complete request with the correct ordered list.

The CLI high-level aws s3 cp command manages transfers, but it does not offer a simple universal resume-the-old-upload-ID switch that reconstructs every interrupted run. Re-running the command may start a new multipart upload. For controlled resumption across restarts, write durable checkpointing around the multipart APIs or use a transfer tool that explicitly supports that lifecycle.

Use list-multipart-uploads to discover unfinished uploads, and list-parts with the precise upload ID to inspect completed parts. Remember that part listings may be paginated, so the first response may not contain every part. Track part numbers and ETags from successful UploadPart responses because they are needed for completion.

When an upload is no longer useful, abort it to release the storage used by its parts. An incomplete multipart upload can continue to incur part-storage charges until completed or aborted. On ordinary general purpose buckets, consider a lifecycle AbortIncompleteMultipartUpload rule as a safety net for forgotten uploads.

aws s3api list-multipart-uploads --bucket amzn-s3-demo-bucket
aws s3api list-parts --bucket amzn-s3-demo-bucket \
  --key backups/repair-archive.bin --upload-id YOUR_UPLOAD_ID
aws s3api abort-multipart-upload --bucket amzn-s3-demo-bucket \
  --key backups/repair-archive.bin --upload-id YOUR_UPLOAD_ID

Determine whether a partial object was actually written

If RequestTimeout appears during PutObject, inspect the destination with HeadObject before making assumptions. A successful single PUT creates a complete object, while an interrupted PUT attempt does not expose a half-written object as a completed new object. A previously existing object under the same key can still be present, so its existence alone does not prove the new upload succeeded.

If you are using multipart, uploaded parts remain separate and are not yet a normal completed object. The object is assembled on CompleteMultipartUpload. If the response to that final operation is lost, your client may not know whether completion succeeded, so check the key and any outstanding multipart upload state before deciding what to do.

Object versioning complicates what you see under a reused key. A HeadObject response can refer to a current object version, while a failed replacement attempt leaves an older version available. Where versioning matters, inspect the returned version ID and compare metadata or checksums associated with the upload you intended.

For integrity, compare source and destination lengths and an appropriate checksum. Multipart ETags should not automatically be treated as the MD5 of the whole file, especially with modern checksum and encryption choices. If uncertainty remains, use an explicit checksum workflow supported by your transfer client and S3 API.

aws s3api head-object --bucket amzn-s3-demo-bucket \
  --key backups/repair-archive.bin
aws s3api list-multipart-uploads --bucket amzn-s3-demo-bucket

Balance speed, retry cost, and incomplete-part storage

If you increase parallel uploads, watch not just the progress bar but also retries and request volume. Multipart is more resilient to failed transfers, yet each part is a separate request. Excessive concurrency can saturate the client, compete with other office traffic, or stress a proxy that was already struggling.

For Jake's 5 GiB example, 80 chunks of 64 MiB mean a failed part may require resending about 64 MiB instead of the whole file. That is a transfer-volume comparison, not a claim that every failure saves exactly that many bytes. Actual transfer cost also depends on retries, partial bytes already sent, and the network path.

Incomplete parts stored in S3 can be billable until their upload is completed or aborted. A file that fails each evening can leave several unfinished upload IDs if the client does not clean up. Review list-multipart-uploads and apply a lifecycle cleanup policy on eligible general purpose buckets so that failed uploads stop quietly accumulating storage costs.

When estimating a production budget, include ordinary S3 PUT and multipart-related requests, any transfer acceleration surcharge, incomplete part storage, and operational monitoring. Rates vary and can change; check the current pricing for the relevant Region rather than calculating a charge from an old screenshot. Improving reliability usually saves more trouble than chasing the absolute smallest part size.

Jake: "Could unfinished parts cost me money even though I cannot see a finished object?"

Ethan: "Yes. Complete or abort them, and use lifecycle cleanup where it is supported."

Work systematically when the first multipart fix still fails

If a multipart upload with four concurrent requests still times out, raising concurrency to twenty is the wrong next move. First reduce it to one or two and determine whether individual parts become reliable. This separates a bandwidth saturation problem from a connection that fails no matter how gently you send data.

Next compare a different part size, such as 16 MiB versus 64 MiB, while holding concurrency constant. Small parts finish sooner but create more HTTP operations. Large parts reduce per-part overhead but may be more vulnerable to a persistent slow link. Measure both successful throughput and failure rate rather than measuring peak speed alone.

Inspect local disk reads, CPU use, container memory pressure, and the source stream. An application can appear to have a network issue when it actually stops feeding the HTTP body because the file producer is blocked. For generated data, verify the producer keeps writing and that any Content-Length matches the final byte stream.

Finally compare a supported AWS CLI upload, a simple SDK upload, and your application in the same environment. If the CLI succeeds while the app fails, focus on custom request construction and client configuration. If all three fail only on one network, bring request IDs, timing, and network comparison data to the responsible administrator or AWS Support.

Collect useful evidence before contacting AWS Support

If your upload still fails after you have isolated a reproducible case, collect the full error including the S3 request ID and extended request ID when present. Include the operation name, AWS Region, approximate timestamp with timezone, object size, client and SDK version, and whether a proxy or VPN was used. Mask sensitive request details, and keep credentials out of the case entirely.

Describe the exact reproduction sequence, such as a 5 GiB high-level CLI upload with 64 MiB parts and four concurrent requests that fails on an approved office connection but succeeds on another approved route. A support engineer can act on an observable comparison more effectively than the statement that uploads sometimes hang.

If the failing request is generated by custom HTTP code, provide the request framing details without exposing signing secrets. Include the declared Content-Length, actual body bytes emitted, and whether the same source can be replayed. If the failure happens on CompleteMultipartUpload, include the upload ID and completion timing because the final object might already exist.

A support case cannot eliminate packet loss on your corporate network or prove a transfer completed without the required evidence. Use your own HeadObject, checksum, and multipart state checks to establish what S3 contains. Once the object is available and your client returns a successful result, update your runbook with the configuration that made the transfer dependable.

Build a reliable upload policy before the next large backup

If nightly backups are important to your business, make multipart transfer the standard large-object path rather than an emergency setting. Pick a moderate initial part size and concurrency, use bounded retries, and record failures with enough context to distinguish client timeouts from S3 RequestTimeout responses.

Validate upload completion before deleting or rotating the local source. A progress bar reaching its end is not a substitute for a successful completion response and destination verification. When your object supports explicit checksums, include those checks in the workflow and keep the source until the desired integrity condition is met.

Keep the upload endpoint, bucket Region, client SDK versions, and proxy routing documented. Unexpected changes to any of those can alter behavior even when your application code stays the same. Test a representative file after network or runtime upgrades, especially if transfer reliability is part of a recovery objective.

Make incomplete multipart cleanup part of operations, too. A failure should create an alert and a follow-up action, not an abandoned billable upload left indefinitely. That discipline lets your team distinguish a one-time connectivity hiccup from a persistent upload-path problem and protects the next backup window.

Check the Region, endpoint, and upload route

Your upload may travel through a regional S3 endpoint, a gateway or interface endpoint, a NAT route, or a corporate proxy. Compare the actual route with the bucket Region and the client configuration. A wrong Region can introduce redirects or an error that is different from RequestTimeout, especially when a custom uploader cannot replay its body after a redirect. Use the exact returned error rather than grouping every failed request into one timeout category.

A quick CLI comparison helps establish whether the endpoint and credentials can transfer data at all. Upload a small disposable object from the same host, then repeat with a larger stable file. If one path works and another stalls, record the difference in endpoint, network route, and request size. This is more useful than repeatedly changing unrelated S3 bucket settings.

For EC2-based uploaders, inspect the VPC routing used to reach S3. A private endpoint and a public internet path may behave differently because the networks differ, not because S3 applies an identical timeout to every path. Check route tables, endpoint policy, DNS resolution, and how traffic exits the environment, using the network team where necessary.

When a request fails only across a long-distance route, benchmark multipart upload first and then consider Transfer Acceleration if the bucket is eligible. Keep the comparison fair by using the same file, client, and concurrency configuration. A faster peak result is not as useful as a transfer that finishes reliably every evening.

Instrument the source stream and preserve safe diagnostics

If the connection stays open while an application generates its body, a stalled producer can look like a slow network. Measure when your application reads source bytes, when it supplies bytes to the HTTP client, and when the service returns a response. Those timestamps help identify a long pause before any bytes were available versus a stall after a sustained upload period.

The AWS CLI --debug flag can reveal the sequence of API attempts and retry decisions. Handle those logs as sensitive operational data because request URLs, headers, and credentials-related information may appear. Collect only what is needed, restrict access, and sanitize debug output before submitting it to a third party or support ticket.

For a custom uploader, record its declared Content-Length and count the bytes its producer actually emitted. Also document whether it can recreate the same body for a retry. If the source is a generated stream that changes on each request, the retry may send different bytes or none at all. A stable file or rewindable source makes the failure easier to isolate.

Make the comparison reproducible with one known source file and a fixed destination key in a controlled testing bucket. Capture the operation name, HTTP status, S3 request ID if available, SDK version, and the client-side duration. These details let your team distinguish a repeated proxy cutoff from random packet loss without exposing the file contents.

Follow an orderly console and CLI recovery checklist

If you start in the S3 console, navigate to the destination bucket and look for the object key you expected. A visible object indicates that some completed object exists, but it could be an older version or an earlier upload. Inspect metadata and size rather than treating any matching name as proof that the latest attempt succeeded.

Next, run the AWS CLI from the same host and credential profile as the failing application. Confirm the account, Region, and destination bucket, then try a small test transfer. After that works, try the large file with managed multipart. Compare results with low and moderate concurrency, keeping the part size consistent between comparisons.

If an upload fails, use HeadObject to inspect completed object state and ListMultipartUploads to identify unfinished work. Keep track of upload IDs before trying again. If a manual multipart upload remains valid, recover its uploaded part information; if the work is abandoned, abort it so incomplete parts stop accruing storage charges.

Finally, compare an approved alternate network if the office proxy remains suspect. Put the results in a short incident note: file size, client type, operation, elapsed time, timeout class, and whether the same upload worked through another route. This gives an administrator or AWS Support a concrete troubleshooting path.

1. Identify whether the error came from S3 or the client.
2. Compare small and large transfers from the same route.
3. Move large transfers to managed multipart with modest concurrency.
4. Inspect completed objects and outstanding upload IDs before retrying.

Make retries reliable rather than unlimited

When the failure is transient, a finite retry budget helps an upload complete without having an operator restart it manually. Retries are useful when each request is small enough to replay and the source is still available. They are not a cure for a permanently invalid Content-Length or a generator that stops writing bytes for good.

A failed single-part PutObject may be retried, but a retry to the same key can replace an existing object if the request succeeds and your configuration permits replacement. With multipart, repeated UploadPart operations are scoped to an upload ID and part number. CompleteMultipartUpload is the critical final step, so check actual object state after an ambiguous completion response.

Think about the cost of retries on a 5 GiB source. Sending the complete file again after every interruption consumes far more upload bandwidth than repeating one 64 MiB part. That is an illustrative comparison, not a guaranteed performance result: the amount resent depends on where the request failed and on the transfer client.

Keep a cleanup decision attached to every failed multipart upload. Either recover it using retained state or abort it when no longer needed. A lifecycle rule for incomplete multipart uploads can provide a backstop in supported general purpose buckets, but the application should still manage its own successful completions and failures.

1. Confirm the input can be replayed without changing its bytes.
2. Set finite request and retry limits with clear ownership of timeouts.
3. Verify the completed object before removing the source.
4. Complete or abort each abandoned multipart upload.

Frequently asked questions about S3 RequestTimeout

What does S3 RequestTimeout mean?

S3 received a request whose socket did not make the expected read or write progress within its timeout period. The service identifies this as RequestTimeout and HTTP 400. Investigate stalled body transfer, network intermediaries, and request construction rather than treating it as a bucket permission error.

How long does S3 wait before RequestTimeout?

The public S3 error definition does not provide a universal idle duration for all RequestTimeout cases. Your measured duration may include SDK and proxy timers. Record operation timing and inspect the configured client limits instead of assuming one fixed number.

Is S3 RequestTimeout the same as a boto3 ReadTimeoutError?

No. RequestTimeout is an S3 service error response, while ReadTimeoutError is a client-side transport exception. Increasing botocore read_timeout changes client waiting behavior but does not change the service idle limit.

Why does a 5 GB S3 upload keep timing out?

A long single PUT can be sensitive to connection stalls, especially over an unstable or proxied link. Use a managed multipart transfer and tune part size and concurrency. Also inspect whether the request body pauses or has incorrect framing.

When does AWS CLI use multipart upload automatically?

The documented default threshold for high-level aws s3 transfer commands is 8 MB, with an 8 MB default part size. The actual behavior can also depend on your CLI transfer client. You can configure multipart_threshold and multipart_chunksize.

How do I change multipart_chunksize in AWS CLI?

Set the profile setting with aws configure set default.s3.multipart_chunksize 64MB, substituting a suitable size. The high-level aws s3 transfer commands use this setting for the classic multipart transfer path. Review the upload results before assuming bigger parts are better.

Should I increase max_concurrent_requests to stop timeouts?

Not necessarily. More parallel operations can overload an already constrained network or proxy. Compare a modest value such as four with smaller and larger settings, and optimize for successful throughput.

Why does the upload fail only behind a corporate proxy?

A proxy or VPN may buffer the request body, close idle connections, or impose traffic controls that interrupt a sustained upload. Compare approved network paths with the same file and credentials. Ask the network team to inspect long-running outbound HTTPS uploads.

Can incorrect Content-Length cause S3 RequestTimeout?

A custom uploader that declares more bytes than it transmits can leave the receiver waiting for missing content. Count actual bytes and compare them with the request framing. Prefer SDK-managed uploads when possible.

Does RequestTimeout mean my S3 object is partly written?

A failed single PUT does not expose a half-completed new object. In multipart upload, uploaded parts can persist without a completed object until CompleteMultipartUpload succeeds. Inspect HeadObject and outstanding multipart uploads to distinguish these cases.

Can I resume a failed S3 multipart upload?

If its upload ID still exists, a custom multipart client can list uploaded parts, send missing parts, and complete with the required part numbers and ETags. A fresh aws s3 cp command does not necessarily resume the previous upload ID. Keep checkpoints if restartable upload is a requirement.

How do I find and abort incomplete S3 uploads?

Use list-multipart-uploads to discover in-progress work and list-parts to inspect a specific upload ID. Abort an unwanted upload with abort-multipart-upload. For eligible general purpose buckets, a lifecycle AbortIncompleteMultipartUpload rule can provide cleanup.

Will increasing --cli-read-timeout fix RequestTimeout?

It helps only when the AWS CLI is the side giving up while waiting for socket data. It does not increase S3 service-side idle handling. Confirm which side emitted the error first.

Does S3 Transfer Acceleration prevent upload timeouts?

It may improve long-distance upload performance for eligible general purpose buckets, but does not fix a broken proxy or mismatched Content-Length. Enable it and compare measured results against the normal endpoint. Additional charges may apply.

How many parts can an S3 multipart upload contain?

Multipart upload supports up to 10,000 parts. Except for the final part, each must be at least 5 MiB; individual parts can be up to 5 GiB. Choose a chunk size that stays within those limits.

Is the S3 object size limit still 5 TB?

No. S3 raised its maximum supported object size to 50 TB in December 2025. Large-object workflows need suitable multipart-capable tooling. The limit does not imply every older transfer client automatically supports that size.

Jake can now distinguish a network problem from an SDK timeout, protect an unfinished multipart upload from becoming a forgotten bill, and check the object before calling the backup complete. Your fix should be just as concrete: narrow the failure, tune a multipart transfer for the actual connection, and verify what S3 contains. If the behavior changes with a proxy or network path, involve the people who control that path and take the relevant request IDs with you.

Revision note. Written October 15, 2026, with the 8 MB CLI defaults and the 50 TB object ceiling of December 2025 in place. Slow and steady wins the race, and for a 5 GiB upload that means smaller parts, not a longer clock.