AWS Lambda: Synchronous vs Asynchronous Invocation

You can invoke a Lambda function in two ways.

Synchronous Invocation

The first one is called Synchronous invocation, which is the default mode. Synchronous invocation is pretty straightforward. When you invoke a function synchronously, AWS Lambda waits until the function is done processing, then returns the result.

Let’s see how this works through the following example:

The diagram illustrates a Lambda function-backed API that is managed by API Gateway. When API Gateway receives a GET request from the /getOrder resource, it invokes the getOrder function. The function receives an event containing the payload, processes it, and then returns the result.

Considerations when using synchronous invocation:

• If you’re planning to integrate AWS Lambda with API Gateway, keep in mind that API Gateway has an integration timeout of 29 seconds. This means that when a function takes longer than that to complete a request, the connection will time out, and the request will fail. Hence, use synchronous invocations for applications that don’t take too long to complete (e.g., authorizing requests, CRUD operations).
• Synchronously-invoked functions can accept a payload of up to 6 MB.
• You might need to implement retry logic in your code to handle intermittent errors.

Common services that invoke Lambda functions synchronously:

• Amazon API Gateway
• Application Load Balancer

• Amazon Cognito
• Amazon Kinesis Data Firehose
• Amazon CloudFront (Lambda@Edge)

Asynchronous Invocation

Typically, developers use Asynchronous invocation when clients do not require immediate results from a function. Examples of this include long-latency processes that run in the background, such as batch operations, video encoding, and order processing.

When you invoke a function asynchronously, AWS Lambda stores the event in an internal queue that it manages. Let’s understand asynchronous invocation through the example below:

A PUT request is made to the /putOrder resource. Like the previous example, the request goes through API Gateway, which produces an event. This time, instead of API Gateway directly invoking the function, AWS Lambda queues the event. If the event is successfully queued, AWS Lambda returns an empty payload with HTTP 202 status code. The 202 status code is just a confirmation that the event is queued; it’s not indicative of a successful invocation. To improve user experience, you can create a background job that tracks order status and sends notifications once the order is successfully processed. This will eliminate the need for the client to wait for the Lambda function to complete.

To call a Lambda function asynchronously via the Invoke command, simply set Event as the value for the invocation-type parameter, as shown below:

aws lambda invoke \
  –function-name testFunction  \
      –invocation-type Event \
          –cli-binary-format raw-in-base64-out \
              –payload ‘{ “input”: “input_value” }’ response.json

Considerations when using asynchronous invocation:

• Asynchronously-invoked functions can only accept a payload of up to 256 KB.
• The Lambda service implements a retry logic for asynchronously-invoked functions
• Good for applications that run in the background

Common services that invoke Lambda functions asynchronously:

• Amazon API Gateway (by specifying Event in the X-Amz-Invocation-Type request header of a non-proxy integration API)
• Amazon S3
• Amazon CloudWatch Logs
• Amazon EventBridge
• AWS CodeCommit
• AWS CloudFormation
• AWS Config

Handling failed asynchronous invocations

AWS Lambda has got you covered when it comes to retrying asynchronous invocations. If the function returns an error, Lambda will make two more attempts to process the request. Each attempt will have a longer wait interval than the previous one, giving the function a bit more time to process the request successfully. If all of the retry attempts are unsuccessful, AWS Lambda will give up and discard the request. However, to prevent the loss of important events, you can redirect failed attempts to an SQS dead-letter queue. This will allow you to investigate and debug the issue at a later time and retry the function.