3 AWS Lambda and Event-Driven Compute

Lambda functions and execution

AWS Lambda runs code in response to events without requiring management of the underlying servers. It is suited to short, independently scalable tasks, such as resizing an image after it is uploaded to Amazon S3. It is not a general replacement for Amazon EC2 or container services; choose compute based on workload duration, runtime and operating-system needs, control requirements, and traffic pattern.

A function includes code, a runtime, a handler (the entry point), and configuration. Lambda delivers an event, typically JSON, to the handler, which processes it and returns or completes. Lambda creates execution environments as needed and may reuse them. Reuse can make initialized clients and libraries faster, but memory and temporary files in an environment should not be relied on for durable state. Store persistent data in a service such as Amazon S3 or DynamoDB.

Triggers, invocation, and reliability

Events reach a function through two main patterns:

• Direct invocation (push): A service such as API Gateway, EventBridge, or S3 invokes the function. Depending on the invoker, invocation may be synchronous, so the caller waits for a response, or asynchronous, so the event is queued for processing.

• Event source mapping (poll): Lambda polls a queue or stream, such as Amazon SQS or DynamoDB Streams, and invokes the function with a batch of records.

The trigger determines the event structure, batching, and error behavior. For example, an S3 event can start image processing, while an SQS event source mapping can process queued orders in batches.

Retries and duplicate delivery

Design for retries and duplicate delivery. Lambda retries asynchronous invocations when function errors occur; stream and queue mappings have source-specific retry and redelivery behavior. Make processing idempotent: reprocessing the same event should not create a second charge, order, or other unintended result. Configure failure destinations or dead-letter handling where appropriate, and monitor queues or streams for backlogs.

Permissions and access

Two separate permission paths are involved in Lambda systems. A function's execution role grants it permission to access AWS resources, such as reading from a bucket or writing to a database. Give the role only the permissions required for the function's task.

A service that directly invokes a function generally needs permission in the function's resource-based policy. In contrast, an event source mapping that polls a queue or stream needs the required source-reading permissions through the execution role. Keep invocation permission and resource-access permission distinct when troubleshooting access failures.

Configuration and deployment

Configure the runtime, handler, architecture, memory, timeout, and any required environment variables. Tune memory and timeout based on observed workload behavior rather than guessing. Lambda provides temporary /tmp storage, which is not durable. Use environment variables for non-secret settings, and retrieve secrets from a managed secret store rather than embedding them in code or logs.

Connect a function to a VPC when it must reach private resources there; do not add network configuration without a need. Deploy code as a ZIP package or a container image. For safer releases, publish an immutable version and point an alias, such as prod, to it. The alias can be moved to a different version for deployment or rollback.

Concurrency and scaling

Concurrency is the number of invocations running at the same time. Lambda scales execution environments with demand, subject to account and function limits. Scaling must also account for downstream capacity: unconstrained scaling can overload a database or external API that cannot handle the function's peak traffic.

• Reserved concurrency sets a function's concurrency ceiling and reserves that capacity for the function. It can protect other workloads from a runaway function, but the ceiling can also cause throttling.

• Provisioned concurrency prepares execution environments in advance to reduce initialization delay for latency-sensitive workloads. It incurs additional charges and should be sized against actual demand.

Monitor concurrency and throttling, and coordinate limits with the throughput of dependent services.

Monitoring and cost

Lambda publishes invocation, error, duration, and concurrency metrics to Amazon CloudWatch. Use CloudWatch Logs for application logs, and create alarms for operational signals such as errors, throttles, or a growing queue backlog. Structured logs should include useful identifiers for tracing an event through the system, but exclude credentials and sensitive data.

For standard Lambda functions, charges are based primarily on requests and execution duration; duration is affected by allocated memory. Provisioned concurrency adds charges, and logging and other services used by the application can also add cost. Reduce unnecessary invocations and excess runtime, right-size memory based on tests, and avoid recursive event flows that can multiply invocations. Check current AWS pricing for the relevant Region and configuration before estimating a workload's cost.