Lambda and Serverless Compute

Lambda runs code without provisioning servers—you upload code and Lambda handles scaling, patching, and availability. Configure runtime (Node.js, Python, Java, Go, .NET, Ruby), memory (128 MB to 10 GB), and timeout (up to 15 minutes).

Memory allocation directly correlates with CPU—1,769 MB equals 1 vCPU. Doubling memory doubles CPU proportionally. For compute-heavy workloads, increase memory for faster execution even if it costs slightly more per invocation.

Execution roles grant Lambda permissions to access AWS services. Start with AWS-managed policies (AWSLambdaBasicExecutionRole for CloudWatch Logs) and add specific permissions for S3, DynamoDB, SQS, etc. Follow least privilege—don't use wildcard * permissions. Use resource policies for event source mappings to control which services can invoke your function.

API Gateway creates serverless REST/HTTP APIs. Lambda integrates directly—API Gateway handles request/response transformation, authentication, and throttling. Use Lambda proxy integration for full control.

S3 Events trigger Lambda on object operations (PUT, POST, DELETE). Configure event notifications on bucket prefixes/suffixes—process uploaded images, validate files, or sync data. S3 Batch Operations uses Lambda for bulk processing.

DynamoDB Streams capture item-level changes for real-time processing. Lambda polls the stream and processes new records—ideal for building materialized views, sending notifications, or triggering workflows on data changes.

EventBridge routes events from 25+ AWS services and custom apps. Create rules matching event patterns and send them to Lambda. Schedule Lambda with cron expressions directly in EventBridge.

SQS integration provides batch processing with automatic scaling. Lambda polls SQS queues and processes messages. Configure batch size and window to optimize throughput vs. latency. Use SQS as a buffer for downstream service protection.

Concurrency controls how many Lambda invocations run simultaneously. Default is 1,000 per region (soft limit—request increase for more).

Reserved Concurrency allocates a fixed number from the region pool for a function. This guarantees capacity but limits scaling. Use for critical functions that must not be throttled by other functions in the account.

Provisioned Concurrency keeps instances warm and ready to execute immediately—eliminates cold starts. Configure provisioned instances and Lambda keeps them initialized. Pay for provisioned capacity even when not invoked. Ideal for latency-sensitive APIs.

Throttling occurs when you exceed concurrency limits. Lambda returns 429 Too Many Requests. Configure dead-letter configurations (SQS/SNS) for failed async invocations. Async invocations retry twice automatically—after 3 failures, the event goes to DLQ or is discarded.

For async invocations, Lambda retries twice with a backoff between 0-6 minutes. Configure maximum event age to discard old events. Use DLQ to capture failed events for later analysis.

Cold starts occur when Lambda initializes a new execution environment—includes downloading code, loading runtime, and running initialization code. Mitigate with: provisioned concurrency, smaller deployment packages, and connection reuse.

Deployment packages: keep under 50 MB (zipped), 250 MB (unzipped). Use Lambda Layers for shared dependencies (beyond 250 MB limit). Layers let you share code across functions without duplicating libraries.

Environment variables store configuration (10 KB limit). Use AWS Systems Manager Parameter Store or Secrets Manager for sensitive data—never hardcode credentials. Retrieve secrets during init phase for reuse across invocations.

X-Ray tracing provides visibility into Lambda performance. Enable active tracing to see cold start duration, downstream service calls, and error rates. Use custom subsegments to trace business logic.

Lambda SnapStart (Java/Python/.NET) reduces cold starts by snapshotting initialized environments—reduces startup from seconds to milliseconds. Enable for latency-sensitive Java/Python functions.