AWS Lambda Invocation Models
When AWS Lambda receives a request to run your function, it doesn't always happen the same way. Understanding how different AWS services trigger your Lambda functions is crucial for building reliable serverless applications. Let's break down the three invocation models and which services use each one.
The Three Invocation Models
Before diving into specific services, here's what each model means:
Synchronous: The caller waits for your function to complete and gets the result back immediately.
Asynchronous: The caller drops the event in a queue and moves on. Lambda handles the execution and automatic retries.
Poll-Based (Event Source Mapping): Lambda actively polls a queue or stream and retrieves records to process in batches.
When using the AWS API or CLI, you control this behavior with the InvocationType flag in the cli:
RequestResponse to wait for the result (synchronous) and Event to fire and forget (asynchronous)// example of invoking lambda synchronously via cli
aws lambda invoke \
--function-name MyFunction \
--invocation-type RequestResponse \
--payload '{"key": "value"}' \
response.json// example of invoking lambda asynchronously via cli
aws lambda invoke \
--function-name MyFunction \
--invocation-type RequestResponse \
--payload '{"key": "value"}' \
response.jsonSynchronous Invocation ServicesSynchronous Invocation Services
These are the common AWS services that invoke Lambda synchronously, meaning they wait for your function to complete before continuing:
Elastic Load Balancing (Application Load Balancer) - When ALB routes requests to Lambda, it waits for the response to send back to the client
Amazon API Gateway - API requests must wait for Lambda to process and return data
Amazon Cognito - User authentication flows need immediate responses
Amazon Kinesis Data Firehose - Data transformation happens synchronously during delivery
and more..
Asynchronous Invocation Services
These services trigger Lambda asynchronously, placing events in a queue without waiting for completion:
Amazon S3 - File uploads trigger functions in the background (perfect for image processing, data transformation)
Amazon SNS - Notifications are published and Lambda processes them independently
Amazon SES - Email events trigger functions asynchronously
Amazon CloudWatch Logs - Log processing happens in the background
Amazon CloudWatch Events (EventBridge) - Scheduled events and pattern-matched events trigger asynchronously
Poll-Based Invocation (Event Source Mapping)
Lambda polls these services on your behalf, retrieves records, and invokes your functions:
Amazon Kinesis Data Streams - Lambda polls the stream and processes records in batches
Amazon DynamoDB Streams - Database changes are batched and processed by Lambda
Amazon SQS - Lambda continuously polls the queue for messages
Important distinction: AWS manages the poller on your behalf and performs synchronous invokes of your function. So while Lambda pulls the data, the actual function invocation is synchronous.
Retry behavior: Based on data expiration in the source. For example, Kinesis records stay available for 24 hours by default, giving Lambda multiple opportunities to process them
Some Practical Examples
S3 Thumbnail Generator (Asynchronous)
User uploads an image → S3 triggers Lambda asynchronously → Lambda creates thumbnail → User sees original image immediately, thumbnail appears shortly after.
API Order Processing (Synchronous)
User clicks "Place Order" → API Gateway invokes Lambda synchronously → Lambda validates order and returns confirmation → User sees immediate success/failure message.
SQS Background Jobs (Poll-Based)
Application adds jobs to SQS queue → Lambda polls queue and retrieves messages in batches → Processes multiple jobs efficiently → Failed messages return to queue automatically.
Conclusion
You don't always choose the invocation model—it's often determined by which AWS service triggers your Lambda function. Understanding these patterns helps you design better error handling, set appropriate timeouts, and choose the right service for your use case.
Pro tip: Use CloudWatch Logs and X-Ray to monitor how long requests spend in Lambda's internal queues, especially for asynchronous invocations. This helps you optimize performance and identify bottlenecks.
References:
https://aws.amazon.com/blogs/architecture/understanding-the-different-ways-to-invoke-lambda-functions/
https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html
https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html
Sep 15