ReadTimeoutError: Read timed out. (read timeout=15)

What it means

There are two clocks on any HTTP request, and confusing them sends you to fix the wrong thing. The connect timeout governs establishing the connection; when it expires you get ETIMEDOUT or a connect error, and the cause is routing, security groups, or DNS. The read timeout governs waiting for the response once the connection is up. ReadTimeoutError is the second one, and it means the network was fine — something answered, it was just not finished in time.

That distinction is worth holding onto because the fixes have nothing in common. A connect failure in a VPC is a NAT gateway or a security group. A read timeout is a budget that does not match the work, and no amount of network configuration will change it.

The most useful thing about this error on Lambda is that you are lucky to be seeing it at all. The AWS SDKs default to read timeouts that are generous relative to a typical function's own timeout, which means the Lambda usually dies first — and a Lambda that times out reports Task timed out after N seconds with no mention of the downstream call that was hanging. Setting client timeouts shorter than the function's is what converts a silent, unattributable timeout into a logged error naming the operation, which is a diagnostic technique as much as a reliability one.

Retries make the arithmetic less obvious than it looks. Botocore retries by default, so the budget that matters is attempts multiplied by the read timeout, plus whatever else the handler does. Three attempts at fifteen seconds is forty-five seconds of potential waiting from one client — comfortably past a thirty-second function timeout, which is how a well-intentioned retry configuration produces a Lambda timeout instead of a useful error.

The last thing worth checking is where in the container's life the failure lands. A client constructed inside the handler negotiates a fresh TLS connection every invocation; one at module scope reuses it across every request that execution environment serves. When a timeout is marginal, that handshake is the difference between failing on cold starts and never failing at all.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

Note the timeout value in the message and compare it to the elapsed time before the error. A read timeout=15 failing after roughly fifteen seconds means the client's own budget ran out, not that anything was unreachable.

Then compare it against the Lambda's own timeout. If the SDK's read timeout is longer than the function's, the function dies first and you never see this at all — you get Task timed out instead, with no indication that a downstream call was the reason. Seeing this error is in that sense good news: it means the client gave up in time to tell you something.

Look for the retry pattern too. Botocore's default is to retry, so a single logged ReadTimeoutError usually means several attempts were made and all of them ran out — and the duration on the REPORT line includes all of them.

Causes, most likely first

Fixes

pythonimport boto3
from botocore.config import Config

# Small, fast operations: fail quickly so a retry has time to succeed.
ddb = boto3.client("dynamodb", config=Config(
    connect_timeout=2, read_timeout=5,
    retries={"max_attempts": 3, "mode": "adaptive"},
))

# Large transfers: a longer budget, fewer attempts.
s3 = boto3.client("s3", config=Config(
    connect_timeout=2, read_timeout=60,
    retries={"max_attempts": 2, "mode": "standard"},
))

python# 3 attempts x 5s read timeout = 15s worst case for this client,
# comfortably inside a 30s function timeout with room for the handler.
config = Config(read_timeout=5, retries={"max_attempts": 3})

pythonimport boto3

# Module scope: created once per execution environment.
s3 = boto3.client("s3")

def lambda_handler(event, context):
    return s3.get_object(Bucket=event["bucket"], Key=event["key"])

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Troubleshoot networking issues
• Botocore documentation — Config reference