Build Serverless with AWS Lambda

Use Provisioned Concurrency to keep instances warm, optimize package size by pruning dependencies, use layers for shared code, choose ARM64 architecture for faster init, and consider SnapStart for Java. For latency-sensitive workloads, keep functions warm with scheduled pings during off-hours.

Lambda functions can run for up to 15 minutes (900 seconds). For longer tasks, use Step Functions to orchestrate multiple Lambda invocations, or consider ECS Fargate for workloads exceeding 15 minutes. You can also implement checkpoint patterns for resumable processing.

Default account limit is 1,000 concurrent executions (soft limit, can be increased). Use Reserved Concurrency to guarantee capacity for critical functions. Implement exponential backoff in clients. For burst traffic, configure SQS with Lambda to buffer requests and process at a controlled rate.

Use Lambda for event-driven workloads, APIs with variable traffic, and tasks under 15 minutes. Use containers (ECS/EKS) for long-running processes, workloads requiring GPU, or when you need more control over the runtime. Lambda now supports containers up to 10GB, bridging the gap.

Use CloudWatch Logs Insights for querying logs, X-Ray for distributed tracing, and CloudWatch Metrics for performance. Enable active tracing for latency analysis. For local debugging, use SAM CLI or Docker-Lambda. Consider structured logging with correlation IDs for complex flows.

Never hardcode secrets in code or environment variables. Use AWS Secrets Manager or Parameter Store with IAM roles. Cache secrets within the function instance using Lambda extensions or initialization code. Rotate secrets without redeploying by referencing secret ARNs dynamically.

Layers package libraries, custom runtimes, and configuration files separately from function code. Functions can include up to 5 layers, with total unzipped size under 250MB. Share layers across functions and accounts. Great for common dependencies like pandas, numpy, or custom SDKs.

Lambda supports 200+ event sources: API Gateway (HTTP), S3 (object changes), DynamoDB Streams (data changes), SQS/SNS (messaging), EventBridge (scheduling/events), Kinesis (streaming), CloudWatch Events, Alexa Skills, and more. You can also invoke directly via SDK.

Right-size memory (more memory = faster execution = lower cost sometimes). Use ARM64 for 20% cost savings. Minimize package size for faster cold starts. Use Provisioned Concurrency strategically. Review CloudWatch Lambda Insights for optimization opportunities. Consider Compute Savings Plans for predictable workloads.

Yes, configure VPC settings to place Lambda in private subnets. Lambda creates ENIs for VPC access. Use NAT Gateway for internet access from VPC Lambda. Cold starts may be slightly longer with VPC. For RDS, use RDS Proxy to manage connection pooling and avoid exhausting database connections.

Lambda automatically retries failed async invocations twice. Configure Dead Letter Queues (SQS/SNS) for failed events. Use Lambda Destinations for success/failure routing. For sync invocations (API Gateway), implement error handling in code. Set appropriate timeout values to avoid cascading failures.

Synchronous: Caller waits for response (API Gateway, SDK with RequestResponse). Timeout affects caller. Errors returned immediately. Asynchronous: Lambda queues event and returns immediately (S3, SNS, EventBridge). Built-in retries. Use DLQ for failed events. Lower cost for fire-and-forget patterns.