Build Production-Ready AWS Serverless Applications

This skill covers AWS Lambda serverless architecture: the Lambda handler pattern (initializing clients outside the handler so they're reused across warm invocations), API Gateway integration via SAM templates, event-driven SQS processing, DynamoDB Streams consumption, cold start optimization (package size reduction, SnapStart for Java/.NET, right-sizing memory since more memory means more CPU and faster init, provisioned concurrency when needed, and lazy initialization), SAM local development (install/init/build/run/invoke/debug/deploy commands), and CDK-based serverless deployment. Core principles: right-size memory and timeout only after measuring, minimize cold starts for latency-sensitive workloads, prefer HTTP API over REST API for simple cases, design for failure with dead-letter queues and retries, keep deployment packages small, and use structured logging with correlation IDs.

It documents eight production sharp edges: as of August 2025, AWS now bills the Lambda INIT (cold start) phase the same as invocation duration, meaning heavy dependency loading or frequent cold starts directly inflate the bill, not just latency - diagnosed via CloudWatch's INIT_REPORT log line and fixed with package-size reduction, lazy-loaded dependencies, AWS SDK v3 modular imports, and SnapStart; Lambda timeout misconfiguration (set an appropriate timeout and make downstream calls timeout-aware); out-of-memory crashes (increase memory, stream large data instead of loading it fully, use AWS Lambda Power Tuning to find the optimal memory setting); VPC-attached Lambda cold start delay (use VPC endpoints instead of a NAT Gateway for AWS service calls, only attach to a VPC when actually necessary); Node.js event loop not clearing (set callbackWaitsForEmptyEventLoop correctly and close connections properly); API Gateway payload size limits (for large uploads/responses); and infinite loop/recursive invocation risk from S3-triggered Lambdas writing back to the same bucket/prefix (fixed with different output buckets/prefixes, idempotency checks, and reserved concurrency as a circuit breaker).

Use this when building or debugging AWS Lambda functions - handler design, API Gateway/SQS/DynamoDB Streams integration, cold start latency or cost issues, timeout/memory configuration, VPC networking, or S3-trigger recursion risk.

Not applicable outside AWS Lambda/serverless architecture, and note the August 2025 INIT-phase billing change specifically if evaluating whether current serverless costs match expectations - it's a real, dated platform change, not a hypothetical.

Inputs: the Lambda function's runtime, trigger type (API Gateway, SQS, DynamoDB Streams, S3), memory/timeout configuration, and VPC requirements.

Outputs: an optimized Lambda handler with lazy initialization, a SAM or CDK template wiring up the trigger, cold-start mitigations (SnapStart, right-sized memory, provisioned concurrency where needed), and safeguards against timeout misconfiguration, OOM crashes, VPC cold-start delay, and S3-trigger recursion - validated against checks like hardcoded credentials, overly permissive IAM policies, missing DLQ configuration, and importing the full AWS SDK v2 instead of modular v3 clients.

AWS Lambda, API Gateway, SQS, DynamoDB Streams, S3 triggers, SAM CLI, AWS CDK, CloudWatch (INIT_REPORT logs), AWS Lambda Power Tuning, SnapStart (Java/.NET).

Developers building or troubleshooting AWS Lambda-based serverless systems who need concrete patterns for handlers, triggers, cold start optimization, and awareness of the 2025 INIT-phase billing change and other common production pitfalls.