Skip to content

AWS Lambda: Understand Events, Retries, and Concurrency Before Choosing Functions

Aug 22, 2026 1 min
TL;DR Lambda fits short-lived, event-driven, bursty work; its design center is invocation, retries, idempotency, and downstream capacity—not merely smaller containers.
Table of Contents
  1. Separate the three invocation models
  2. Automatic scaling does not scale dependencies
  3. A container image is not a general container platform
  4. Lambda, Fargate, or App Runner
  5. References

🌏 中文版

AWS Lambda is event-driven function compute. You deploy code and configuration; AWS creates execution environments as requests arrive. The team stops managing hosts but must design invocation, concurrency, and failure semantics.

Separate the three invocation models

A synchronous caller waits and usually owns retries for function errors. An asynchronous call first enters a Lambda-managed queue, with separate behavior for failures, throttling, and event age. Event source mappings for SQS or Kinesis poll batches and add source-specific retries, visibility timeouts, partial failures, and checkpoints.

Those distinctions determine duplicate and loss risks. AWS retry guidance says code should tolerate the same event more than once. For payments, email, or external writes, create an idempotency record keyed by event ID. Route terminal failures to a destination or DLQ and monitor queue age, not only function errors.

Automatic scaling does not scale dependencies

Concurrency counts in-flight invocations. A burst can create enough environments to overwhelm database connections, third-party quotas, or downstream queues. Reserved concurrency can cap as well as reserve capacity; provisioned concurrency trades money for more predictable startup. The scaling documentation includes account, function, and scaling-rate quotas, so inspect the target Region before deployment.

Do not judge cold starts by averages alone. Runtime, dependencies, VPC setup, initialization, and package size affect tail latency. Measure p95 and p99 before shrinking dependencies, moving setup outside the handler, or buying provisioned concurrency.

A container image is not a general container platform

Lambda accepts zip archives and container images, but an image must implement the Lambda runtime API and accept its read-only filesystem and /tmp boundary. A Dockerfile does not turn Lambda into Fargate or support an arbitrary persistent daemon.

Keep handlers stateless and store durable state in a database or object store. Reused environments may reuse clients, but globals and /tmp are not reliable state. Apply least privilege to the function role and inspect resource policies and cross-account boundaries on event sources.

Lambda, Fargate, or App Runner

Lambda is usually operationally smallest for event-triggered, short, bursty work. Choose Fargate for long processes, custom runtime behavior, sidecars, stable connection pools, or container-level resources. App Runner is higher-level when the requirement is simply turning an HTTP container repository into a service.

Test more than one happy HTTP request. Redeliver an event, time out the handler, exhaust concurrency, and disable a dependency. Verify idempotency, backoff, DLQs, alarms, and reserved concurrency under those failures.

References