Fixing AWS Lambda Timeout: How to Increase It and What the Maximum Limit Is

Your Lambda function exits mid-execution — not because of a bug, but because it hit its configured timeout. If your task genuinely requires more than the default 3-second window (as set by the AWS Console for new functions), you need to know exactly where to change that setting and what ceiling you're working within.

TL;DR

Parameter Value / Detail
Default timeout (console-created functions) 3 seconds (unless overridden by your tooling or IaC template)
Maximum timeout 900 seconds (15 minutes)
Where to change it AWS Console, AWS CLI, SAM/CloudFormation, Terraform
Billable impact You are billed for actual duration, not the configured timeout
Error when exceeded Task timed out after X.XX seconds in CloudWatch Logs
Analogy: Think of the Lambda timeout like a kitchen timer on a microwave. The default is set to 3 seconds when you buy it (console default), but you can dial it up to 15 minutes max. If your dish isn't done when the timer goes off, the microwave cuts power — regardless of whether the food is cooked. The timer doesn't cost you anything extra; you only pay for the electricity actually consumed while it ran.

Why This Happens: Understanding Lambda's Execution Lifecycle

When Lambda invokes your function, the runtime enforces a hard wall at the configured timeout value. The moment execution time crosses that threshold, the runtime sends a SIGKILL-equivalent termination signal. Your code gets no cleanup window — it simply stops. This is a resource-protection mechanism, not a bug.

The key distinction: the configured timeout is a ceiling you set. The actual billed duration is what your function consumed. A function configured for 900 seconds that finishes in 10 seconds is billed for ~10 seconds.

graph TD A["Trigger
(API GW / EventBridge / S3)"] --> B["Lambda Invocation"] B --> C["Execution Starts
Timer begins"] C --> D{"Elapsed Time < Configured Timeout?"} D -- "Yes — function completes" --> E["✅ Success Response Execution environment frozen"] D -- "No — timeout reached" --> F["❌ Forcible Termination Task timed out after X.XX seconds"] F --> G["CloudWatch Logs Timeout error recorded"]
  1. Invocation: A trigger (API Gateway, EventBridge, S3, etc.) sends an event payload to Lambda.
  2. Execution Start: Lambda initializes the runtime environment and begins executing your handler code.
  3. Timeout Check: The Lambda service continuously monitors elapsed time against the configured timeout value.
  4. Success Path: If the function completes before the timeout, it returns a response and the execution environment is frozen.
  5. Timeout Path: If elapsed time exceeds the configured timeout, Lambda forcibly terminates the execution and logs Task timed out after X.XX seconds to CloudWatch Logs.

Method 1: AWS Management Console

This is the fastest path for one-off adjustments or exploration.

  1. Navigate to AWS Lambda in the Console.
  2. Select your function.
  3. Click the Configuration tab.
  4. Select General configuration from the left panel.
  5. Click Edit.
  6. Under Timeout, set your desired value (minutes and seconds fields are provided separately).
  7. Click Save.

For a 10-second task, set the timeout to at least 15–30 seconds to provide a safe buffer for cold starts and variable execution time.

Method 2: AWS CLI

Use this for scripted updates or CI/CD pipelines.

aws lambda update-function-configuration \
  --function-name my-function-name \
  --timeout 30

The --timeout value is in seconds (integer). The command above sets a 30-second timeout. Verify the change:

aws lambda get-function-configuration \
  --function-name my-function-name \
  --query 'Timeout'

Method 3: AWS SAM (CloudFormation)

For infrastructure-as-code workflows, define the timeout in your SAM template. This is the recommended approach for production workloads — it keeps your configuration version-controlled and reproducible.

🔽 Click to expand — SAM Template Example 
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: my-function-name
      Handler: index.handler
      Runtime: nodejs20.x
      Timeout: 30  # Value in seconds; max is 900
      MemorySize: 256
      CodeUri: ./src/
      Policies:
        - AWSLambdaBasicExecutionRole

Deploy with:

sam build && sam deploy --guided

Method 4: Terraform

For teams using Terraform as their IaC layer:

🔽 Click to expand — Terraform Resource Example 
resource "aws_lambda_function" "my_function" {
  function_name = "my-function-name"
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  timeout       = 30  # Value in seconds; max is 900
  memory_size   = 256
  role          = aws_iam_role.lambda_exec.arn
  filename      = "function.zip"

  source_code_hash = filebase64sha256("function.zip")
}

resource "aws_iam_role" "lambda_exec" {
  name = "lambda-exec-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

Execution Flow: Timeout vs. Completion

graph LR A["Configured Timeout T (1s – 900s)"] --> B["Execution Begins"] B --> C{"Actual Duration vs T"} C -- "Actual Duration < T" --> D["✅ Function Returns Billed for Actual Duration"] C -- "Actual Duration = T" --> E["❌ Lambda Terminates Timeout Error in CloudWatch"]
  1. Configured Timeout (T): The ceiling you define — anywhere from 1 second to 900 seconds.
  2. Actual Duration: The real wall-clock time your function consumed. This is what you are billed for.
  3. Success Zone: Actual duration is less than T. Function returns normally.
  4. Timeout Zone: Actual duration reaches T. Lambda terminates the process and emits a timeout error to CloudWatch Logs.

IAM & Security Considerations

Changing a Lambda function's timeout requires the lambda:UpdateFunctionConfiguration IAM permission. Apply least-privilege by scoping this permission to specific function ARNs rather than using wildcards.

🔽 Click to expand — Least-Privilege IAM Policy Example 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLambdaConfigUpdate",
      "Effect": "Allow",
      "Action": [
        "lambda:UpdateFunctionConfiguration",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function-name"
    }
  ]
}

Operational Best Practices

  • Set timeout with a buffer: If your task takes ~10 seconds under normal conditions, configure 20–30 seconds. Account for cold starts and tail latency.
  • Monitor with CloudWatch: Use the Duration metric on your Lambda function to track actual execution time over time. Set a CloudWatch Alarm if Duration approaches your configured timeout.
  • Consider architectural alternatives for long tasks: If your workload consistently approaches or exceeds 15 minutes, Lambda is the wrong tool. Evaluate AWS Step Functions (for orchestration), AWS Fargate (for containerized long-running tasks), or AWS Batch.
  • Timeout ≠ Memory: Increasing timeout does not increase memory or CPU. If your function is slow due to compute constraints, increase MemorySize — Lambda allocates CPU proportionally to memory.

Glossary

Term Definition
Configured Timeout The maximum duration (in seconds) you allow a Lambda function to run before the service forcibly terminates it.
Cold Start The initialization latency incurred when Lambda provisions a new execution environment for a function that has no warm instances available.
Billed Duration The actual execution time rounded up to the nearest millisecond, used to calculate Lambda charges — independent of the configured timeout.
Execution Environment The isolated runtime sandbox (micro-VM) that Lambda creates to run your function code, including the runtime, dependencies, and environment variables.
CloudWatch Logs The AWS logging service where Lambda automatically streams function output, errors, and timeout events for observability.

Next Steps

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables

Launching an EC2 instance in a custom VPC only to find it cannot reach the internet is one of the most common networking pitfalls in AWS — and it almost always comes down to two missing pieces: an Internet Gateway (IGW) and a correctly configured Route Table. This post walks you through the exact architecture, the root cause, and the precise steps to fix it. TL;DR Step Action Why It Matters 1 Create and attach an Internet Gateway to your VPC Without an IGW, there is no path between your VPC and the public internet 2 Add a 0.0.0.0/0 route pointing to the IGW in your subnet's Route Table The route table is the traffic director — without this entry, outbound packets have nowhere to go 3 Assign a Public IP or Elastic IP to the EC2 instance The IGW performs NAT only for instances with a public IP address 4 Verify Security Group allows outbound traffic Security Groups are stateful firewalls; outbound rules...
Read more

IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User

Choosing between an IAM User and an IAM Role is one of the most consequential security decisions in AWS — get it wrong and you either expose long-lived credentials or block your application entirely. This post cuts through the confusion and gives you a definitive answer for the EC2-to-S3 access pattern. TL;DR — Quick Comparison Dimension IAM User IAM Role Identity type A person or a static service account An assumable identity for AWS services, users, or external principals Credential type Long-lived Access Key ID + Secret Access Key Short-lived, auto-rotating STS tokens (max 12 h by default) Credential rotation Manual — you must rotate keys yourself Automatic — AWS rotates them transparently Stored on EC2? Yes — in ~/.aws/credentials or env vars (risky) No — delivered via the In...
Read more

Lambda Infinite Loop with S3: How to Prevent Recursive Triggers

Writing a processed file back to the same S3 bucket that triggered your Lambda function creates a recursive loop — each output file fires a new invocation, which writes another file, ad infinitum. Left unchecked, this silently drains your AWS budget and exhausts Lambda concurrency limits within minutes. TL;DR Strategy Mechanism Best For Complexity Separate Output Prefix/Bucket S3 event filter on prefix Simple pipelines Low Object Metadata Check Lambda reads S3 object metadata before processing Single-bucket requirement Medium Separate Output Bucket Trigger only on source bucket Clean architectural separation Low DynamoDB Idempotency Guard Track processed ETag/key in DynamoDB Exactly-once guarantees Medium-High Understanding the Recursive Loop Before fixing the problem, you need to understand exactly why it happens. The S3 → Lambda trigger is an event-driven subscription: S3 publishes an ObjectCreat...
Read more