How do I eliminate cold start latency for Lambda-backed APIs?

Use provisioned concurrency to keep a specified number of Lambda instances pre-initialized and ready. Set a baseline (e.g., 10 instances) and configure Application Auto Scaling to scale provisioned concurrency based on LambdaProvisionedConcurrencyUtilization (target 70%). For cost-sensitive environments, use a CloudWatch Events scheduled rule to invoke the function every 5 minutes as a warm-up. Also optimize your deployment package: smaller packages and fewer dependencies reduce cold start time. Go and Python have the fastest cold starts; Java and .NET are slowest.

Why does my Lambda function timeout even though it finishes processing?

The most common cause is the API Gateway integration timeout of 29 seconds — this is a hard limit that cannot be increased. Even if your Lambda timeout is set to 60 seconds, API Gateway returns 504 at 29 seconds. Set your Lambda timeout to 25 seconds (below the 29s limit) and restructure long operations: return 202 Accepted immediately, process asynchronously via SQS or Step Functions, and let clients poll a status endpoint. Also check for connection pool exhaustion to databases — hanging database connections cause Lambda to exceed its timeout.

Should I use DynamoDB on-demand or provisioned mode for serverless APIs?

Use on-demand for unpredictable traffic patterns, new applications, or when avoiding throttling is critical — it scales instantly and you pay per request. Use provisioned with auto-scaling for predictable, steady-state traffic to save 60-80% on costs. Provisioned mode risks throttling during sudden traffic spikes because auto-scaling takes minutes to react. A hybrid approach works well: on-demand for tables with spiky access patterns, provisioned with auto-scaling for tables with predictable load. Monitor ConsumedReadCapacityUnits and ThrottledRequests metrics.

How do dead letter queues prevent silent message loss in serverless architectures?

Without a DLQ, messages that fail Lambda processing retry up to the maximum retry count and are then silently discarded. A DLQ captures these failed messages in a separate SQS queue (or SNS topic) after maxReceiveCount retries (typically 3). Set up a CloudWatch alarm on ApproximateNumberOfMessagesVisible for the DLQ to get alerted immediately when messages fail. You can then inspect, fix, and replay failed messages. Set the source queue's visibility timeout to at least 6x your Lambda timeout to prevent messages from becoming visible again while still processing.

How do canary deployments work with Lambda and how do they prevent downtime?

Create a Lambda alias with routing_config that splits traffic between the current version and a new version. Start by sending 10% of traffic to the new version. Use CodeDeploy with a linear deployment configuration (e.g., CodeDeployDefault.LambdaLinear10PercentEvery1Minute) to automatically increase traffic by 10% every minute. Configure auto-rollback with CloudWatch alarms — if the error rate or latency exceeds thresholds during the shift, CodeDeploy automatically reverts all traffic to the previous version. This limits the blast radius of a bad deployment to a small percentage of users.

Preventing API Downtime in Serverless