Memory, Timeout & Performance Tuning

AWS Lambda (Amazon’s “run code without managing servers” service) gives you only three real knobs to turn for performance: memory, timeout, and concurrency. The most surprising part is that the “memory” setting does much more than control memory. It also decides how much CPU and network bandwidth your function gets, and it directly drives your bill. Getting this right is the single biggest lever you have over both speed and cost, so it is worth understanding deeply.

Memory is really a “power” dial

When you set Lambda memory, you are not just reserving RAM. AWS proportionally scales the amount of CPU (the processor power that runs your code) and network throughput along with it. A function with 1,792 MB of memory gets roughly one full vCPU (a virtual CPU core); above that you start getting access to multiple cores. The allowed range is 128 MB to 10,240 MB (10 GB), set in 1 MB steps.

This matters because CPU-bound work (compressing images, parsing large JSON, cryptography) speeds up dramatically when you raise memory, even if the function never uses the extra RAM. You are really buying more processor.

Gotcha: Counterintuitively, MORE memory often makes a function cheaper, not more expensive. You pay per GB-second (gigabyte of memory multiplied by seconds of run time, billed in millisecond increments). If doubling memory makes the function finish more than twice as fast, your total bill goes down. Under-provisioning memory to “save money” frequently costs more and risks timeouts. Always tune memory empirically rather than guessing the minimum.

How Lambda billing actually works

Lambda charges you for GB-ms: memory (in GB) multiplied by execution time (in milliseconds), plus a tiny per-request fee. In 2026, on-demand pricing in us-east-1 is about $0.0000166667 per GB-second for x86, and roughly 20% cheaper on Arm/Graviton2.

Memory	Duration	Billed time × memory	Cost per 1M invocations (approx)
128 MB	800 ms	0.125 GB × 0.8 s = 0.1 GB-s	~$1.67
512 MB	200 ms	0.5 GB × 0.2 s = 0.1 GB-s	~$1.67
1024 MB	90 ms	1.0 GB × 0.09 s = 0.09 GB-s	~$1.50

Notice the 512 MB and 128 MB rows cost the same but 512 MB returns the answer 4x faster. The 1024 MB row is both fastest and cheapest. This is exactly why guessing the minimum is the wrong instinct.

Setting memory

Memory is configured per function and applies to every invocation.

Console steps:

Open the AWS Lambda console and choose your function.
Go to the Configuration tab, then General configuration.
Click Edit.
Drag the Memory slider or type a value (e.g. 1024).
Click Save.

AWS CLI (v2):

aws lambda update-function-configuration \
  --function-name process-images \
  --memory-size 1024

Output:

{
    "FunctionName": "process-images",
    "MemorySize": 1024,
    "Timeout": 30,
    "Architectures": ["x86_64"],
    "LastUpdateStatus": "InProgress"
}

Timeout: the safety cap

The timeout is the maximum number of seconds a single invocation may run before Lambda forcibly stops it. The default is 3 seconds and the hard maximum is 900 seconds (15 minutes).

Set the timeout slightly above your realistic worst-case run time, not wildly higher. A too-high timeout means a stuck function (for example, waiting on a database that never responds) keeps running and keeps billing you. A too-low timeout kills legitimate slow requests.

When to use a short timeout (a few seconds): APIs behind Amazon API Gateway, where users are waiting. Fail fast.

When you need the full 15 minutes: batch jobs, large file processing, report generation. When NOT to: if your job regularly approaches 15 minutes, Lambda is the wrong tool. Move to AWS Step Functions, AWS Fargate, or AWS Batch instead.

aws lambda update-function-configuration \
  --function-name nightly-report \
  --timeout 300

Finding the sweet spot with Lambda Power Tuning

Guessing is unreliable. AWS Lambda Power Tuning is a free, open-source tool (an AWS Step Functions state machine) that runs your function at several memory settings, measures real cost and speed, and shows you the optimal point on a graph.

Deploy it once from the AWS Serverless Application Repository: search for aws-lambda-power-tuning and click Deploy.
Start an execution, passing your function’s ARN (Amazon Resource Name, the unique ID of an AWS resource) and the memory values to test:

aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:111122223333:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:111122223333:function:process-images",
    "powerValues": [128, 256, 512, 1024, 1792, 3008],
    "num": 50,
    "strategy": "balanced"
  }'

Output:

{
    "executionArn": "arn:aws:states:us-east-1:111122223333:execution:powerTuningStateMachine:a1b2c3d4",
    "startDate": "2026-06-15T10:42:11.318000-04:00"
}

The strategy field accepts cost (cheapest), speed (fastest), or balanced. When the execution finishes, the output includes a visualization URL plotting cost vs. speed so you can pick the best memory value with data, not guesswork.

Concurrency: controlling how many run at once

Concurrency is the number of function instances running simultaneously. There are two controls worth knowing.

Setting	What it does	When to use it
Reserved concurrency	Caps (and guarantees) how many instances a function can use	Protect a fragile downstream database from being overwhelmed; isolate a function’s share of the account limit
Provisioned concurrency	Keeps instances pre-warmed and ready	Latency-sensitive APIs that cannot tolerate cold starts; predictable traffic spikes

aws lambda put-provisioned-concurrency-config \
  --function-name checkout-api \
  --qualifier prod \
  --provisioned-concurrent-executions 10

Cost note: Provisioned concurrency bills you for keeping instances warm even when idle (roughly $0.000004167 per GB-second in us-east-1). Only enable it where cold-start latency genuinely hurts users, and consider scheduling it with Application Auto Scaling so you are not paying overnight.

Define the same settings in infrastructure-as-code so they are repeatable:

Resources:
  ProcessImages:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      MemorySize: 1024
      Timeout: 30
      Architectures:
        - arm64

Best Practices

Tune memory with real data using Lambda Power Tuning; never ship the 128 MB default by habit.
Remember memory scales CPU and network too — raise it to speed up CPU-heavy work, not just to add RAM.
Set timeouts just above your worst realistic case so stuck invocations fail fast instead of burning money.
If a job routinely nears 15 minutes, move it off Lambda to Step Functions, Fargate, or Batch.
Prefer Arm/Graviton (arm64) where your dependencies support it for ~20% lower cost at equal performance.
Use reserved concurrency to shield fragile databases, and provisioned concurrency only where cold starts truly hurt.
Re-tune after major code or dependency changes — the optimal memory point moves over time.