Triggers, Cold Starts & Pricing

Event-Driven by Design

Lambda runs code in response to a trigger — an API Gateway request, an S3 upload, an SQS message, a scheduled EventBridge rule — with no servers to provision or manage. Billing is per-invocation and execution time, not for idle capacity — well-suited to intermittent, bursty traffic where a continuously-running server would sit mostly idle.

Handler & Basic Function

// index.js — configured handler: index.handler
exports.handler = async (event) => {
  const userId = event.pathParameters.id;
  const user = await db.users.findById(userId);
  return {
    statusCode: 200,
    body: JSON.stringify(user),
  };
};

Cold Starts & Provisioned Concurrency

A cold start is the latency of initializing a fresh execution environment; a warm invocation reuses one and runs faster. Provisioned concurrency keeps environments pre-warmed for consistently low latency — at extra cost, trading away some of Lambda's pure pay-per-use efficiency for latency-sensitive use cases.

Memory, CPU & Cost

Memory allocation scales CPU proportionally too — a CPU-bound function can sometimes finish faster (and cost about the same or less overall) at a higher memory setting, despite the higher per-ms rate. Worth benchmarking rather than assuming lower memory is always cheaper.

Timeout & Concurrency

Max execution time is up to 15 minutes — Lambda suits short, event-driven tasks, not long-running processes or persistent connections. Concurrent invocations each get their own parallel execution environment automatically, up to a configurable limit — no manual server-fleet provisioning.