AWS Lambda for Developers: Configuration, Events, Concurrency and Tuning

Lambda executes your code inside an isolated execution environment that the service creates, reuses, and eventually retires — and understanding that lifecycle explains most Lambda behavior on the exam. When an event arrives and no idle environment exists, Lambda runs the init phase: it provisions the environment, downloads your code, starts the runtime and any extensions, and executes all code outside the handler — top-level imports, client construction, configuration loading. Only then does the invoke phase call your handler, the function you name in configuration as the entry point, passing the event and a context object. That first, full startup is a cold start; its latency is the init phase.

After the invocation, the environment is frozen, not destroyed. The next event may thaw and reuse it — a warm invocation that skips init entirely. Everything in global scope survives: SDK clients, database connections, cached configuration, and files written to /tmp. This is why the core Lambda coding practice is to initialize expensive resources outside the handler, so hundreds of warm invocations reuse one client and one connection instead of rebuilding them per event.

Reuse is an optimization, never a guarantee. Lambda may run your code in many environments in parallel and can recycle any of them at any time, so treat globals and /tmp (512 MB by default, configurable up to 10 GB) strictly as a cache. Correctness must never depend on state from a previous invocation — durable state belongs in a database, cache, or object store. Functions that honor this are stateless in the way the platform assumes, which is exactly what lets Lambda scale by simply creating more environments.

Function configuration is a compact set of parameters, and the exam tests the consequences of each. Memory is allocated from 128 MB up to 10,240 MB — and CPU scales proportionally with it, with roughly one full vCPU available at 1,769 MB. There is no separate CPU setting, so memory is the primary performance dial: a CPU-bound function is often made faster, and sometimes cheaper overall, by raising memory. Timeout can be set up to 900 seconds — 15 minutes — and that ceiling is a favorite exam fact: any workload that needs longer must be redesigned, for example by splitting the work into steps coordinated by Step Functions or moving to container-based compute. The runtime selects the language environment, and the handler setting names the file and function Lambda invokes.

Environment variables supply per-function configuration — endpoints, table names, feature flags — without code changes; all of a function's variables together are limited to 4 KB. They are encrypted at rest, but genuinely sensitive values belong in a secrets service and get fetched at init, a pattern the security domain covers in depth. Layers package shared libraries and dependencies separately from your function code; a function can attach up to five, keeping deployment packages lean and letting many functions share one dependency set. Extensions run alongside the runtime within the environment — monitoring agents, secrets caches — hooking the environment lifecycle.

Two more settings round out the model: triggers, the event sources permitted to invoke the function, and destinations, where Lambda sends invocation results — both covered with the event lifecycle below.

Accessing VPC-private resources — an RDS database in a private subnet, an ElastiCache cluster, an internal service — requires attaching your function to the VPC, because by default Lambda runs in an AWS-managed network that has internet access but no route into your private subnets. You attach a function by specifying subnets and security groups in its VPC configuration. Lambda then creates elastic network interfaces (ENIs) in those subnets through its Hyperplane networking layer; the ENIs are created once per unique subnet and security-group combination and shared across execution environments, so scaling does not mint a new ENI per invocation.

Two consequences follow, and both are exam bait. First, security groups still rule: the database's security group must allow inbound traffic on the database port from the function's security group, or connections silently time out. Second, a VPC-attached function loses direct internet access. If it must call external APIs, its subnets need a route through a NAT gateway. If it only needs AWS services, prefer VPC endpoints: gateway endpoints for S3 and DynamoDB, and interface endpoints (AWS PrivateLink) for services like Secrets Manager, SQS, and KMS — keeping traffic private with no NAT at all.

The database-specific hazard is connection exhaustion. Each concurrent execution environment opens its own database connections, so a traffic spike can scale Lambda past what the database accepts. Amazon RDS Proxy is the exam's answer: it maintains a shared, pooled set of connections to RDS or Aurora, multiplexes function connections onto it, supports IAM authentication, and rides through failovers. When a scenario says Lambda is exhausting database connections, choose RDS Proxy.

Lambda has three invocation models, and predicting retry behavior for each is a guaranteed exam skill.

In a synchronous invocation the caller waits for the response and receives any error directly; if retries are wanted, the client or SDK must perform them. In an asynchronous invocation Lambda queues the event internally and immediately returns an accepted response; a separate process invokes the function, and on failure retries twice — three attempts total. You can tune this with the maximum retry attempts setting and a maximum event age, after which undelivered events are discarded or routed to your failure handling. In the poll-based model, Lambda itself polls the source on your behalf and invokes the function synchronously with batches of records — so retry semantics come from the event source mapping and the source's own redelivery rules, not from the async retry system. Misattributing async retry behavior to synchronous or poll-based invocations is the classic wrong answer.

Failure handling in Lambda is configured, not just coded, and each invocation model has its own tools. For asynchronous invocations, once retries are exhausted the event can go to a dead-letter queue — an SQS queue or SNS topic that receives the event payload — or, better, to an onFailure destination. Lambda Destinations accept SQS, SNS, EventBridge, or another Lambda function as targets and send a record containing the request payload plus the response context and error details, which a DLQ does not include; AWS recommends Destinations over DLQs for async error handling. The matching onSuccess destination forwards successful results, letting you chain functions without writing invocation code.

Stream sources (Kinesis and DynamoDB Streams) add a twist: records in a shard are ordered, so by default a failing batch is retried until it succeeds or the data expires, blocking that shard behind the failure. The event source mapping gives you controls — maximum retry attempts, maximum record age, bisect batch on function error (split the batch to isolate the bad record), and an on-failure destination that receives metadata describing the skipped records so processing can move on.

For SQS and stream batches alike, enable partial batch responses: with ReportBatchItemFailures turned on, your handler returns a batchItemFailures list naming only the records that failed, and only those are retried instead of the whole batch. Walk the scenario: a payment processor reads batches of ten SQS messages and one is malformed. Without partial batch responses, all ten return to the queue and nine successful payments are reprocessed — duplicate side effects unless the handler is idempotent. With partial batch responses, only the poison message retries, and after exceeding the queue's maxReceiveCount it lands in the queue's dead-letter queue for inspection.

An event source mapping is the Lambda-managed poller that reads from SQS, Kinesis, or DynamoDB Streams and invokes your function with batches — the machinery behind the poll-based model. Its two headline settings trade latency against efficiency. Batch size caps how many records one invocation receives. The batching window (MaximumBatchingWindowInSeconds) tells the poller how long to wait to fill a batch before invoking anyway: a longer window means fewer, fuller, cheaper invocations; a zero window means minimum latency. Event source mappings can also apply event filtering, discarding non-matching records before any invocation happens — often the cheapest optimization available, since filtered records never invoke the function at all.

For SQS sources, Lambda scales its pollers up as the backlog grows and back down as it drains. The critical interaction is with the queue's visibility timeout: a batch in flight must stay invisible for as long as processing might take, so AWS recommends setting the visibility timeout to at least six times the function timeout. Set it too low and in-flight messages reappear and process twice.

For Kinesis and DynamoDB Streams, the mapping processes each shard with one concurrent invocation by default, preserving order within the shard, so total concurrency tracks shard count. The parallelization factor raises this to as many as ten concurrent batches per shard, still keeping records with the same partition key in order. The starting position chooses whether a new mapping reads only new records or begins from the oldest available data. When a scenario says stream processing is falling behind, the levers are parallelization factor, batch size, function duration — or more shards.

Concurrency is the number of invocations a function is serving at the same instant — each in its own execution environment — and it is the unit in which Lambda scales and throttles. All functions in a Region share one concurrency pool (the default quota is 1,000, raisable by support request). When demand would exceed available concurrency, invocations are throttled, and what that means depends on the invocation model: synchronous callers receive a 429 throttling error and must retry; asynchronous events are returned to Lambda's internal queue and retried automatically for up to several hours; poll-based sources simply back off and retry the batch. Scaling is fast but not unbounded — each function can add up to 1,000 concurrent executions every 10 seconds — so an extreme spike can throttle briefly even below quota.

Keep the two straight: reserved concurrency is about how much a function may scale — it both guarantees that capacity and prevents the function from exceeding it. Provisioned concurrency is about how fast requests are served — pre-warmed environments answer without init latency. A function can use both together.

Performance tuning starts with the memory dial: because CPU scales with memory, benchmarking the same function at several memory sizes often finds a setting that is faster and cheaper, since billing is duration times memory and duration falls. The next wins are in the init phase — create SDK clients and database connections outside the handler, reuse HTTP connections with keep-alive, lazily load rarely used dependencies, and keep the deployment package small so it downloads and initializes quickly. For cold starts that still hurt, two platform features apply. Provisioned concurrency keeps environments warm for any runtime, billed while configured. SnapStart instead snapshots the fully initialized environment and resumes new environments from that snapshot — built for runtimes with expensive startup, first for Java and since extended to Python and .NET. With SnapStart, remember that anything computed during init is captured in the snapshot, so uniqueness — random seeds, temporary credentials — must be re-derived after restore.

Testing Lambda code spans three layers. Unit tests exercise your business logic with the handler treated as thin wiring and SDK clients mocked. The console's test events invoke the deployed function with saved JSON payloads. Locally, sam local generate-event produces realistic event JSON for sources like S3 or SQS, sam local invoke runs the function in a Lambda-like container against that payload, and sam local start-lambda exposes a local endpoint your integration tests can call through the SDK.

Finally, near-real-time processing is Lambda consuming a stream via an event source mapping — transforming, enriching, or filtering records within seconds of arrival and forwarding results downstream. Keep batches and timeouts small for latency, use partial batch responses, and remember the managed variant: Amazon Data Firehose can invoke a Lambda function to transform records in flight before delivery.