Task timed out afterの直し方｜Lambdaタイムアウト原因別

Task timed out after 3.00 seconds は、Lambda 関数が「タイムアウト」の設定時間を使い切ったときのメッセージです。 関数を作ったときの既定値は 3 秒で、最大 900 秒（15分）まで延ばせます。

ただし、時間を延ばすだけでは直らないことが多いエラーです。 多くは「何かを待ち続けている」ことが原因で、待つ相手によって直し方が違います。

確認環境：Python 3.11・boto3 1.43.111・requests 2.34.2（Linux）。外へ出られない状態は、iptables で通信を捨てる宛先を作って再現し、接続できてから応答しない状態は、何も返さないサーバーで再現しました。context.get_remaining_time_in_millis() で打ち切るコードは、AWS が公開しているランタイムクライアント awslambdaric 4.2.0 を手元で動かして確かめました。Lambda・API Gateway・SQS の上限値と既定値は、AWS のドキュメントで確認しています（確認日 2026年10月12日）。

まずログを読む：Task timed out と REPORT 行

CloudWatch Logs のロググループ /aws/lambda/関数名 に、次のように出ます（AWS のドキュメントの例）。

2024-04-11T17:22:20.857Z abe12jlc-640a-8157-0249-9be825c2y110 Task timed out after 3.01 seconds

REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout

REPORT 行は、1回の呼び出しごとに出る「結果のまとめ」です。 項目の意味と、タイムアウトの切り分けでの見方です。

Duration がタイムアウトの設定値に張り付き、Max Memory Used が小さいときは、CPU を使っていない＝「何かを待っている」状態です。 計算が重いのか、待っているのかを、まずここで分けます。

AWS CLI で、タイムアウトの行だけを見る例です。

aws logs tail /aws/lambda/my-function --since 1h --filter-pattern "Task timed out"

CloudWatch Logs Insights では、REPORT 行の値を集計できます。

filter @type = "REPORT"
| stats count() as calls, max(@duration) as maxMs, avg(@duration) as avgMs,
        max(@maxMemoryUsed / 1000 / 1000) as maxMemMB, max(@initDuration) as maxInitMs
  by bin(1h)

ログの検索全般は、関連記事「CloudWatch LogsのAWS CLI tail・検索・クエリ例」で扱っています。

どこで止まっているかを出す

止まっている行が分からないときは、呼び出しの前後でログを出し、残り時間も一緒に書きます。

import json

def log(step, context):
    print(json.dumps({"step": step, "left_ms": context.get_remaining_time_in_millis()}))

def lambda_handler(event, context):
    log("start", context)
    item = table.get_item(Key={"id": event["id"]})      # DynamoDB
    log("after dynamodb", context)
    res = http.get("https://api.example.com/x", timeout=(3.05, 10))
    log("after external api", context)
    return {"ok": True}

最後に出た step の次の行が、止まっている場所です。

原因① VPC 内から外へ出られない

Lambda を VPC に入れると、そのままではインターネットにも、S3 や DynamoDB などの AWS の API にも出られなくなります。 ドキュメントには「パブリックサブネットに接続しても、インターネットにはアクセスできない」とあり、外に出られないときの例として Task timed out after 3.01 seconds が載っています。

接続先から「拒否」が返るわけではなく、パケットが捨てられるので、エラーにならずに待ち続けます。 これがタイムアウトになる理由です。

ドキュメントの構成は、Lambda をプライベートサブネットに置き、0.0.0.0/0 の行き先を NAT ゲートウェイにする形です。VPC に入れる必要がない関数なら、VPC から外すのが一番簡単な直し方です。

VPC・サブネット・ルートの作り方は、関連記事「AWS CLIでVPCを作成する手順｜サブネットからIGWまで一式」で扱っています。

届かない宛先で、何秒待つかを実測した

iptables で、パケットを捨てる宛先（198.51.100.7）を作り、VPC から外へ出られない状態を再現しました。タイムアウトを指定しないと、boto3 は約5分、requests は約2分待ちました。

boto3 の既定のまま VPC から S3 を呼ぶと、関数のタイムアウトを3秒から延ばしても、300 秒までは延ばしても足りません。 時間がばらつくのは、再試行の間の待ち時間（バックオフ）にランダムな幅があるためです。

手元の Linux の net.ipv4.tcp_syn_retries は 6 でした。requests でタイムアウトを指定しないと、この OS の設定で決まる時間まで待ちます。

原因② 外部 API・DB の応答待ち

接続はできたのに、相手が応答を返さない状態です。何も返さないサーバーを手元に立てて測りました。

requests は、timeout を指定しないと、応答が来るまで待ち続けます。 requests のドキュメントにも、本番のコードでは timeout を付けるよう書かれています。

boto3（botocore）のタイムアウト設定

最悪の待ち時間は、おおよそ「（接続＋読み取りのタイムアウト）× 回数＋再試行の間の待ち」です。 これが関数のタイムアウトより短くなるように決めます。

import boto3
from botocore.config import Config

# 関数のタイムアウトが 10 秒の例：最悪でも (2 + 3) × 2回 ＋ 待ち で 10 秒を切るように
CFG = Config(
    connect_timeout=2,
    read_timeout=3,
    retries={"total_max_attempts": 2, "mode": "standard"},
)
s3 = boto3.client("s3", config=CFG)          # クライアントはハンドラの外で1回作る
dynamodb = boto3.resource("dynamodb", config=CFG)

boto3 のドキュメントでは、max_attempts は最初の1回を含まず、total_max_attempts は含みます。total_max_attempts を使うよう勧められています。再試行される例外の一覧は、関連記事「boto3のエラーハンドリング｜ClientErrorのコード取得とリトライ設定」で扱っています。

requests のタイムアウト設定

import requests

# (接続のタイムアウト, 読み取りのタイムアウト)
res = requests.get("https://api.example.com/items", timeout=(3.05, 10))

timeout=10 のように1つの数字だと、接続と読み取りの両方に 10 秒が使われます。 読み取りのタイムアウトは「データが途切れている時間」の上限で、ダウンロード全体の時間の上限ではありません。

requests の再試行やエラー処理は、関連記事「Pythonのrequestsの使い方｜タイムアウト・エラー処理・再試行まで」で扱っています。値の決め方は、関連記事「タイムアウト設計の値の決め方｜接続・読み取りの違いと多段の計算例」で扱っています。

DB（RDS など）の場合

DB のドライバにも接続のタイムアウトがあります。例えば PyMySQL は connect_timeout、psycopg は connect_timeout（接続文字列）で指定します。接続はハンドラの外で作って使い回すと、呼び出しのたびの接続待ちが減ります。 同時実行が増えると DB の接続数が足りなくなることがあり、ドキュメントでは RDS Proxy が案内されています。

時間切れの前に処理を打ち切るコード

context.get_remaining_time_in_millis() は、タイムアウトまでの残りミリ秒を返します。 残りが少なくなったら、自分で処理を止めて結果を返せば、Task timed out にならずに済みます。

次のコードは、SQS から受け取ったメッセージを1件ずつ処理し、残り1秒を切ったら、残りのメッセージを「失敗」として SQS に戻します（SQS のイベントソースで ReportBatchItemFailures を有効にした場合の返し方）。

import json
import time

SAFETY_MS = 1_000   # 時間切れの何ミリ秒前に打ち切るか


def process(record):
    time.sleep(0.4)  # 1件あたりの処理（外部APIやDBの代わり）


def lambda_handler(event, context):
    records = event["Records"]
    failures = []
    for i, record in enumerate(records):
        left = context.get_remaining_time_in_millis()
        if left < SAFETY_MS:
            # 残りは処理せず、失敗として SQS に戻す（ReportBatchItemFailures）
            failures = [{"itemIdentifier": r["messageId"]} for r in records[i:]]
            print(json.dumps({"msg": "stop before timeout", "done": i, "left_ms": left}))
            break
        process(record)
    return {"batchItemFailures": failures}

ランタイムクライアント awslambdaric で、持ち時間を 3 秒にして 10 件を渡しました。5 件を処理したところで残りが 980 ミリ秒になり、2.02 秒で結果を返しました。

{"msg": "stop before timeout", "done": 5, "left_ms": 980}

{"batchItemFailures": [{"itemIdentifier": "m6"}, {"itemIdentifier": "m7"}, {"itemIdentifier": "m8"}, {"itemIdentifier": "m9"}, {"itemIdentifier": "m10"}]}

SDK のタイムアウトと組み合わせる

1回の呼び出しが長く止まると、ループの途中で残り時間を確かめても間に合いません。SDK のタイムアウトを短くしておくことと、残り時間で止めることは、両方そろって効きます。

import json
import boto3
from botocore.config import Config
from botocore.exceptions import ConnectTimeoutError, ReadTimeoutError, EndpointConnectionError

CFG = Config(connect_timeout=2, read_timeout=3, retries={"total_max_attempts": 2, "mode": "standard"})
s3 = boto3.client("s3", config=CFG)


def lambda_handler(event, context):
    print(json.dumps({"start_left_ms": context.get_remaining_time_in_millis()}))
    try:
        s3.list_buckets()
        return {"ok": True}
    except (ConnectTimeoutError, ReadTimeoutError, EndpointConnectionError) as e:
        print(json.dumps({"error": type(e).__name__, "left_ms": context.get_remaining_time_in_millis()}))
        raise

S3 の宛先を届かないアドレスに向けて、持ち時間 15 秒で動かした結果です。

Task timed out は「どこで止まったか」が出ませんが、自分のコードで例外を出せば、エラーの種類と行がログに残ります。 原因の特定が速くなります。

ハンドラの書き方や、ランタイムクライアントでのローカルテストは、関連記事「AWS Lambda Python入門｜3.14対応handler例とローカルテスト」で扱っています。

原因③ メモリが小さく、処理が遅い

Lambda の CPU は、メモリの設定に比例して割り当てられます。 ドキュメントでは、メモリは 128 MB〜10,240 MB（1 MB 単位）、既定は 128 MB、1,769 MB で 1 vCPU 相当とされています。

画像処理・圧縮・大きな JSON の解析など、CPU を使う処理では、メモリを増やすと Duration が短くなります。Max Memory Used が小さくても、CPU のためにメモリを増やす意味があります。

aws lambda update-function-configuration --function-name my-function \
  --memory-size 1024 --timeout 30

原因④ 初期化（INIT）が遅い

ハンドラの外のコード（import・クライアントの作成・設定の読み込み）は「Init フェーズ」で動きます。 ドキュメントでは、Init フェーズは 10 秒までで、超えると、最初の呼び出しのときに、関数のタイムアウトの中で Init をやり直すとされています（suppressed init）。

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout

タイムアウトが 3 秒前後と短いと、やり直しの Init だけで時間を使い切り、Task timed out after 3.00 seconds になることがあります。ドキュメントの対策は、タイムアウトを延ばす・メモリを増やす・初期化のコードを軽くする、の3つです。

原因⑤ API Gateway の統合タイムアウト

API Gateway から Lambda を呼ぶと、Lambda のタイムアウトとは別に、API Gateway の待ち時間の上限があります。 これを超えると、呼び出し側には 504 Endpoint request timed out が返ります。

Lambda のタイムアウトを 60 秒にしても、REST API の既定では 29 秒で 504 になります。 長い処理は、API では受け付けだけをして（SQS に入れる・Step Functions を起動する）、結果は別に取りに行く形にします。

原因⑥ SQS の可視性タイムアウトとの関係

SQS から Lambda を動かすとき、メッセージは処理中「見えない」状態になり、その時間が可視性タイムアウトです。 関数が終わる前に可視性タイムアウトが切れると、同じメッセージがまた配られ、二重に処理されます。

ドキュメントの決まりと推奨です。

aws sqs set-queue-attributes --queue-url "$QUEUE_URL" \
  --attributes VisibilityTimeout=180

関数がタイムアウトすると、そのバッチのメッセージは可視性タイムアウトのあとに再び配られます。 何度もタイムアウトするなら、デッドレターキュー（DLQ）に送る回数（maxReceiveCount）も決めておきます。上の「打ち切るコード」で、処理できなかった分だけを戻すと、処理済みの分は二重に動きません。

可視性タイムアウトの仕組みは、関連記事「Amazon SQSの使い方｜送受信・削除と可視性タイムアウト、FIFO」で扱っています。

タイムアウトの上限値・既定値の早見表

タイムアウトの変更は、次のコマンドです（ドキュメントの例）。

aws lambda update-function-configuration --function-name my-function --timeout 120

よくある質問

Q. タイムアウトを 900 秒にしておけば安全ですか。 A. 待ち続けている原因があると、900 秒まで課金されたうえでタイムアウトします。ドキュメントでも、タイムアウトを平均の実行時間に近い値にするとタイムアウトしやすい、とされています。目安は「普段の最大の実行時間＋余裕」で、外部呼び出しには SDK 側のタイムアウトを付けます。

Q. ローカルでは速いのに、Lambda だけタイムアウトします。 A. ローカルは CPU が多く、ネットワークにも出られます。Lambda では、128 MB だと CPU が少なく（原因③）、VPC に入れると外に出られません（原因①）。REPORT 行の Duration と Max Memory Used を見て分けます。

Q. タイムアウトした呼び出しは再試行されますか。 A. 非同期呼び出し（S3 のイベント通知など）は、Lambda が再試行します。ドキュメントでは、既定で最大 2 回の再試行です。同じイベントが2回以上処理されても困らない作り（冪等性）にしておきます。

Q. タイムアウトのときに /tmp のファイルは消えますか。 A. ドキュメントでは、タイムアウトなどで実行環境がリセットされても、/tmp は次の Init の前に消されないとされています。途中まで書いたファイルが残る前提で作ります。

関連する Lambda のエラーとして、読み込みの段階で失敗するものは、関連記事「Lambda Unable to import moduleの直し方｜Python」で扱っています。

まとめ

• Task timed out after は設定時間の使い切り。既定 3 秒・最大 900 秒。延ばす前に「何を待っているか」を見る
• REPORT 行で、Duration が上限に張り付き Max Memory Used が小さいなら「待ち」
• VPC から外へ出られないと、boto3 の既定では 約 309 秒待った。NAT か VPC エンドポイント
• boto3 は Config(connect_timeout, read_timeout, retries)、requests は timeout=(接続, 読み取り) を関数のタイムアウトより短く
• context.get_remaining_time_in_millis() で、時間切れの前に自分で止めて結果を返す
• API Gateway の REST は 29 秒、HTTP API は 30 秒。SQS の可視性タイムアウトは関数の 6 倍以上

参考・出典

確認日はいずれも 2026年10月12日です。

• AWS Lambda デベロッパーガイド「Configure Lambda function timeout」：https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html
• AWS Lambda デベロッパーガイド「Configure Lambda function memory」：https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html
• AWS Lambda デベロッパーガイド「Understanding the Lambda execution environment lifecycle」：https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
• AWS Lambda デベロッパーガイド「Troubleshoot invocation issues in Lambda」：https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-invocation.html
• AWS Lambda デベロッパーガイド「Enable internet access for VPC-connected Lambda functions」：https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc-internet.html
• AWS Lambda デベロッパーガイド「Log and monitor Python Lambda functions」（REPORT 行の項目）：https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html
• AWS Lambda デベロッパーガイド「Creating and configuring an Amazon SQS event source mapping」：https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-configure.html
• Amazon API Gateway デベロッパーガイド「Quotas for configuring and running a REST API」：https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-execution-service-limits-table.html
• Amazon API Gateway デベロッパーガイド「Quotas for HTTP APIs」：https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-quotas.html
• Boto3 ドキュメント「Retries」：https://docs.aws.amazon.com/boto3/latest/guide/retries.html
• awslambdaric（AWS Lambda Runtime Interface Client for Python）4.2.0：https://pypi.org/project/awslambdaric/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。