3.1.2.9. Configuring Serverless Applications (Amazon API Gateway, Lambda, AWS Fargate)

3.1.2.9. Configuring Serverless Applications (Amazon API Gateway, Lambda, SQS)

Serverless applications have unique configuration patterns for scaling, error handling, and integration.

API Gateway configuration:

• Throttling: Account-level (10,000 RPS default) and per-method limits. Configure usage plans for API keys.
• Caching: Enable per-stage to reduce Lambda invocations. 0.5 GB to 237 GB cache sizes.
• Integration types: Lambda proxy (passes full request to Lambda), HTTP proxy, AWS service proxy (direct DynamoDB, SQS, S3 integration without Lambda).

Lambda concurrency management:

# Reserve 100 concurrent executions for critical function
aws lambda put-function-concurrency \
  --function-name OrderProcessor \
  --reserved-concurrent-executions 100

# Provision 50 warm environments for low-latency
aws lambda put-provisioned-concurrency-config \
  --function-name OrderProcessor \
  --qualifier prod \
  --provisioned-concurrent-executions 50

SQS + Lambda integration:

• Lambda polls the queue, processes messages in batches (1-10 messages per invocation)
• BatchSize and MaximumBatchingWindowSeconds control throughput vs. latency trade-off
• Failed messages: Configure maxReceiveCount on the queue. After N failures, messages move to the DLQ.

Event source mapping patterns:

• SQS → Lambda: Scales up to 1,000 concurrent Lambda invocations per queue
• Kinesis → Lambda: One Lambda invocation per shard (parallelization via ParallelizationFactor)
• DynamoDB Streams → Lambda: One invocation per shard, processes in order

Exam Trap: API Gateway has a 29-second integration timeout for Lambda — if your function takes longer, API Gateway returns 504 Gateway Timeout regardless of Lambda's own timeout setting (up to 15 minutes). For long-running operations, use asynchronous invocation: API Gateway writes to SQS, Lambda processes from the queue, and the client polls for results.