AWS Lambda Best Practices

Opinionated, language-agnostic conventions for designing and operating Lambda functions at scale. For SDK/API usage, infrastructure-as-code definitions, or language-specific handler patterns, consult the relevant AWS SDK or Terraform documentation instead.

Is Lambda the Right Choice?

Lambda excels at event-driven, short-lived, stateless workloads. Evaluate fit before committing.

Function Design

One function per responsibility. Scope by event source or business operation. Keep the handler thin: validate input, delegate to business logic (pure functions), return a structured response. Initialize SDK clients and connections at module level -- Lambda reuses the execution environment across invocations.

Don't: build a Lambda monolith (all routes in one function), inline business logic in the handler, or create connections inside the handler.

Idempotency is mandatory. Lambda guarantees at-least-once invocation -- your function will receive duplicates. Use an idempotency key (request ID, message ID) with DynamoDB or Powertools to prevent reprocessing.

Don't: write orchestration logic in Lambda. If your function has more if/else/retry than business logic, move the workflow to Step Functions. Never have Lambda synchronously invoke another Lambda -- use SQS or Step Functions to decouple.

Don't: write to the same resource that triggered the function -- this causes recursive invocation loops with exponential cost. If detected, set reserved concurrency to 0 immediately.

See references/function-design.md for execution environment reuse details, cold start factors, idempotency implementation, connection management, and environment variables. See references/anti-patterns.md for why each anti-pattern feels right but isn't, impact analysis, and migration strategies.

Function Configuration

Memory and CPU -- they are linked

Lambda allocates CPU proportional to memory. At 1,769 MB, a function gets one full vCPU.

Use AWS Lambda Power Tuning to find the optimal price/performance balance.

Architecture -- default to arm64

arm64 (Graviton) costs 20% less per GB-second than x86_64 with equal or better performance. Use it unless a native dependency, layer, or container base image requires x86_64.

Timeout -- set deliberately, not defensively

Set to p99 duration + 20-50% buffer. For SQS triggers, set SQS Visibility Timeout >= 6x function timeout. API Gateway's integration timeout is 29 seconds by default (raisable above that only for Regional/private REST APIs via quota increase).

Key quotas

See references/function-configuration.md for memory/CPU tuning strategies, architecture selection, IAM policy guidance, SQS integration, and quota management.

Function Scalability

Concurrency model

Concurrency = (requests per second) x (average duration in seconds)

100 RPS with 200ms average duration = 20 concurrent executions.

Choosing a concurrency control

Lambda scales automatically -- your dependencies may not. Use RDS Proxy for relational databases, reserved concurrency to cap scaling to third-party rate limits, and on-demand mode for DynamoDB under Lambda workloads.

Don't: let Lambda overwhelm your database. A traffic spike -> 1,000 concurrent functions -> 1,000 simultaneous DB connections -> connection exhaustion -> all functions timeout -> cascade failure. This is the most common Lambda production incident.

See references/function-scalability.md for scaling rate, provisioned concurrency scheduling, throttle tolerance patterns, upstream/downstream protection, and cascade failure prevention.

Metrics and Alarms

Prefer Embedded Metric Format (EMF) over PutMetricData API calls for custom metrics -- zero latency overhead. Use Powertools for AWS Lambda to handle EMF formatting. Use PutMetricData only when you need high-resolution (1-second) metrics or immediate availability.

Key metrics to alarm on

Use structured JSON logging, correlation IDs across services, X-Ray tracing, and Cost Anomaly Detection.

See references/metrics-and-alarms.md for EMF details, structured logging guidance, alarm configuration, and cost anomaly detection setup.

Working with Streams

Batch tuning is the critical lever -- larger batches amortize overhead, batching windows buffer small batches. Always enable ReportBatchItemFailures in production to retry only failed records instead of the entire batch. Every stream-processing function must be idempotent -- at-least-once delivery is guaranteed.

See references/stream-events.md for batch tuning parameters, partial batch response implementation, Kinesis shard management, IteratorAge monitoring, and SQS FIFO considerations.

Security

IAM -- least privilege, always. One narrowly scoped execution role per function. No wildcards in production. Use resource-based policies to control who can invoke your function.

See references/security.md for VPC configuration trade-offs, code signing setup, secrets management patterns, data protection, and governance strategies.

Common Mistakes

Reference Files

• references/anti-patterns.md -- Lambda monolith, Lambda as orchestrator, synchronous chains, recursive loops, synchronous waiting -- why each feels right, impact analysis, migration strategies
• references/function-design.md -- Execution environment reuse, cold start factors, idempotency implementation, connection management, RDS Proxy, environment variables
• references/function-configuration.md -- Memory/CPU tuning strategies, arm64/Graviton selection, timeout alignment, quotas, IAM policies, SQS integration, cleanup
• references/function-scalability.md -- Concurrency estimation, reserved vs provisioned concurrency, scaling rate, upstream/downstream protection, cascade failure prevention
• references/metrics-and-alarms.md -- CloudWatch metrics, EMF implementation, structured logging, alarm configuration, Cost Anomaly Detection, X-Ray tracing
• references/stream-events.md -- Batch tuning, partial batch response, Kinesis/DynamoDB Streams/SQS scaling, IteratorAge monitoring, SQS FIFO high-throughput mode
• references/security.md -- IAM least privilege, code signing, VPC trade-offs, secrets management, data protection, Security Hub, GuardDuty, governance