AWS Lambda Best Practices: Write Functions That Scale and Never Time Out

AWS Lambda is the easiest compute service to start with and one of the trickiest to optimize at scale. Cold starts affect user-facing APIs. Memory misconfiguration wastes money. Connection pools exhaust database limits. These best practices address every production Lambda challenge with concrete solutions.

⚡ TL;DR: Initialize connections outside handler — reused across invocations. Set memory based on Power Tuning results, not guesses. Use Provisioned Concurrency for user-facing functions. X-Ray for distributed tracing. Lambda Layers for shared dependencies. Always set timeout < downstream service timeout.

Handler structure — reuse expensive resources

// Good: initialize OUTSIDE handler (reused across warm invocations)
const { Pool } = require('pg');
const pool = new Pool({ connectionString: process.env.DB_URL, max: 1 });
// max:1 — Lambda has 1 concurrent execution per instance

const { SSMClient, GetParameterCommand } = require('@aws-sdk/client-ssm');
const ssm = new SSMClient({ region: 'us-east-1' }); // Reused!

// Lazy-load secrets — cached in module scope
let cachedApiKey;
const getApiKey = async () => {
  if (!cachedApiKey) {
    const cmd = new GetParameterCommand({Name:'/api/key',WithDecryption:true});
    cachedApiKey = (await ssm.send(cmd)).Parameter.Value;
  }
  return cachedApiKey;
};

exports.handler = async (event) => {
  const apiKey = await getApiKey(); // Cached after first call
  const db = await pool.connect();
  try {
    const result = await db.query('SELECT ...');
    return { statusCode: 200, body: JSON.stringify(result.rows) };
  } finally {
    db.release(); // Return to pool!
  }
};

Memory and timeout configuration

# Lambda Power Tuning (open source) finds optimal memory:
# State machine tests your function at: 128,256,512,1024,2048,3008MB
# Returns cost vs performance graph
# Common finding: 512MB runs 3x faster than 128MB at same cost
# (CPU scales with memory allocation)

# Timeout rules:
# Set LOWER than calling service timeout
# API Gateway timeout: 29s → set Lambda timeout: 25s
# SQS visibility timeout: 30s → Lambda timeout: 25s
# Never set timeout to maximum (900s) unless needed

# Memory tip: memory also controls network bandwidth and CPU
# 1769MB = 1 full vCPU (below this: fractional CPU)

Provisioned concurrency for zero cold starts

# template.yaml (SAM)
Resources:
  UserFacingApi:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs20.x
      MemorySize: 512
      Timeout: 25
      AutoPublishAlias: live
      ProvisionedConcurrencyConfig:
        ProvisionedConcurrentExecutions: 10

# Application Auto Scaling for schedule-based PC:
# Scale up before peak, down after
# Saves cost vs always-on provisioned concurrency

X-Ray tracing — see distributed traces

const AWSXRay = require('aws-xray-sdk-core');
const AWS = AWSXRay.captureAWS(require('aws-sdk'));
// Now all AWS SDK calls are traced automatically

// Custom subsegments:
const segment = AWSXRay.getSegment();
const subseg = segment.addNewSubsegment('database-query');
try {
  const result = await db.query(sql);
  subseg.addAnnotation('rows', result.rowCount);
  return result;
} catch(err) {
  subseg.addError(err);
  throw err;
} finally {
  subseg.close();
}

• ✅ Initialize DB/Redis/SDK clients outside handler
• ✅ Run Lambda Power Tuning before going production
• ✅ Provisioned Concurrency for user-facing p99 latency SLAs
• ✅ X-Ray for distributed tracing across Lambda+DynamoDB+SQS
• ✅ Layers for shared deps (reduces cold start and deployment size)
• ❌ Never set Lambda timeout to max without understanding downstream timeouts
• ❌ Never open DB connection inside handler loop

External reference: AWS Lambda operator guide.