AWS re:Invent 2025 - Serverless patterns for large-scale applications with AWS Lambda (CNS372)

Scaling Serverless Applications with AWS Lambda

Organizing Lambda Functions

• Moved from scattered, single-purpose Lambda functions to a microservices and bounded context approach
• Grouped related Lambda functions into separate folders/services based on domain
• Deployed each microservice to its own Git repository and SAM template
• Benefits:
  • Each service can be developed, deployed, and scaled independently
  • Owned by different teams
  • Shared dependencies are isolated

Reducing Lambda Functions with Web Adapters

• Merged related Lambda functions (add/remove cart) into a single "manage cart" function
• Used the Lambda Web Adapter pattern to run a web framework (FastAPI) inside the Lambda function
• Benefits:
  • Fewer cold starts as there is one function to keep warm
  • Shared initialization for database connections, SDK clients, etc.
  • Easier to test as routing logic is inside the Lambda function
• Considerations:
  • Don't create a monolith - keep functions focused on bounded contexts
  • Monitor function size and memory usage
  • One function failure may affect multiple operations

Removing Lambda Functions with Direct Integrations

• Replaced the "get cart" Lambda function with a direct integration between API Gateway and DynamoDB
• API Gateway calls the DynamoDB GetItem API directly, without an intermediary Lambda function
• Benefits:
  • Lower cost - no Lambda invocation charges
  • Lower latency - one less hop in the request path
  • No cold starts as API Gateway is always warm
  • Better scalability - no Lambda concurrency limits
• Use cases:
  • Simple CRUD operations with no business logic or validation
  • Absolute lowest latency and cost requirements
  • Avoid for complex transformations or error handling beyond HTTP status codes

Reusing Code with Lambda Layers

• Used the AWS Lambda Power Tools layer to add logging, monitoring, and other best practices
• Can create custom layers for shared dependencies, runtimes, etc.
• Considerations:
  • Limited to 5 layers per Lambda function
  • Deployment package size limits (50MB zipped, 250MB unzipped)
  • Impact cold starts as layers need to be downloaded
  • Versioning can be complex if functions need different versions

Orchestrating Workflows with Step Functions

• Used AWS Step Functions to orchestrate the order fulfillment workflow
  • Submit order, reserve inventory, process payment, fulfill order
• Replaced individual Lambda functions with direct DynamoDB and SDK calls
• Benefits:
  • Reduced code duplication and maintenance
  • Leveraged Step Functions' built-in error handling and retry logic
  • Maintained important business logic in Lambda functions

Deploying Dynamically with SAM and GitHub Actions

• Used SAM parameters, mappings, and conditions to make the template dynamic
  • Adjusted memory size, timeouts, and environment variables based on environment
  • Conditionally deployed resources based on environment
• Leveraged GitHub Actions for consistent, auditable deployments
  • Used variable overrides to deploy to different environments
  • Included human review gateway before prod deployment

Key Takeaways

• Organize Lambda functions using microservices and bounded contexts
• Reduce the number of Lambda functions using web adapters and direct integrations
• Reuse code across functions with Lambda layers
• Orchestrate complex workflows with Step Functions
• Deploy dynamically using SAM parameters and deployment pipelines

The presented strategies help enterprises scale their serverless applications on AWS by improving maintainability, reducing costs, and increasing reliability.