Demystifying AWS Lambda: Unveiling the Serverless Powerhouse (Part 1)

Demystifying AWS Lambda: Unveiling the Serverless Powerhouse (Part 1)

AWS Lambda is an event-driven, serverless compute service. It allows you to run code without provisioning or managing servers.


  • It abstracts (hides) the infrastructure layer. This ability eliminates the need to manually manage the underlying physical hardware. So you can focus on the code for your applications without spending time building and maintaining the underlying infrastructure.

  • Advantage comparison of traditional environment and serverless.

  • services that are part of the AWS serverless platform:


It operates and maintains all of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring, and logging.


  • You can run code for almost any type of application or backend service.

  • You can run code without provisioning or maintaining servers.

  • It initiates functions for you in response to events.

  • It scales automatically.

  • It provides built-in code monitoring and logging via Amazon CloudWatch.


  • With AWS Lambda, you can run code without provisioning or managing servers.

  • Lambda initiates events on your behalf, scales automatically, and provides built-in monitoring and logging.

  • You can write code in your preferred language.

  • You do configure the memory for your function, but not CPU.

  • You don't work with the OS. AWS provides the operating environment at runtime.

What is a Lambda Function:

  • The code you run on AWS Lambda is called a Lambda function.

  • These are stateless, with no affinity to the underlying infrastructure.

  • Lambda can rapidly launch as many copies of the function as needed to scale to the rate of incoming events.

How AWS Lambda works?

AWS Lambda is an example of an event-driven architecture. Most AWS services generate events and act as an event source for Lambda. Lambda runs custom code (functions) in response to events. Lambda functions are designed to process these events and, once invoked, may initiate other actions or subsequent events. So it is important to understand how events initiate functions to invoke the code within.

Invocation models for running Lambda functions

3 general patterns (invocation models). Each invocation model is unique and addresses a different application and developer needs.

  1. Synchronous:

    • When a function is invoked synchronously, Lambda runs the function and waits for a response.

    • When the function completes, Lambda returns the response from the function's code with additional data, such as the version of the function that was invoked.

    • Synchronous events expect an immediate response from the function invocation.

    • There are no built-in retries. You must manage your retry strategy within your application code.

    • The following diagram shows clients invoking a Lambda function synchronously.

    • Lambda sends the events directly to the function and sends the function response directly back to the invoker.

      Shows icons of event flow, client, event, function.

The following AWS services invoke Lambda synchronously:

  • Amazon API Gateway, Amazon Cognito, AWS CloudFormation, Amazon Alexa, Amazon Lex, Amazon CloudFront
  1. Asynchronous:

    • When you invoke a function asynchronously, events are queued and the requestor doesn't wait for the function to complete.

    • This model is appropriate when the client doesn't need an immediate response.

    • With the asynchronous model, you can make use of destinations.

    • Use destinations to send records of asynchronous invocations to other services.

Event flow, client, event, asynch, function.

A destination can send records of asynchronous invocations to other services. You can configure destinations on a function, a version, or an alias, similarly to how you can configure error handling settings. With destinations, you can address errors and successes without needing to write more code.


When the function returns a success response or exits without producing an error, Lambda sends a record of the invocation to an EventBridge event bus. When an event fails all processing attempts, Lambda sends an invocation record to an Amazon Simple Queue Service (Amazon SQS) queue.

AWS Services: Amazon SNS, Amazon S3 and Amazon EventBridge invokes Lambda asynchronously.

  1. Polling:

    • This invocation model is designed to integrate with AWS streaming and queuing based services with no code or server management.

    • Lambda will poll (or watch) these services, retrieve any matching events, and invoke your functions.

    • This invocation model supports the following services: Kinesis, SQS, and DynamoDB Streams.

    • With this type of integration, AWS will manage the poller on your behalf and perform synchronous invocations of your function.

    • The configuration of services as event triggers is known as event source mapping.

      • This process occurs when you configure event sources to launch your Lambda functions and then grant these sources IAM permissions to access the Lambda function.
    • Lambda reads events from: DynamoDB, Kinesis, MQ, Managed Streaming for Apache Kafka (MSK), Self-managed Apache Kafka and SQS

    • With this model, the retry behavior varies depending on the event source and its configuration.

Invocation model error behavior When deciding how to build your functions, consider how each invocation method handles errors.

Synchronous - No retries

Asynchronous - Built in - retries twice

Polling - Depends on the event source

Lambda execution environment:

icons showing invocation flow.

When you create your Lambda function, you specify configuration information, such as the amount of available memory and the maximum invocation time allowed for your function. Lambda uses this information to set up the execution environment.

Init Phase:
In this phase, Lambda creates or unfreezes an execution environment. The Init phase happens either during the first invocation, or before function invocations if you have enabled provisioned concurrency.

The Init phase is split into three sub-phases:

  1. Extension init - starts all extensions

  2. Runtime init - bootstraps the runtime

  3. Function init - runs the function's static code

    These sub-phases ensure that all extensions and the runtime complete their setup tasks before the function code runs.

Invoke Phase:

In this phase, Lambda invokes the function handler. After the function runs to completion, Lambda prepares to handle another function invocation.

Shutdown Phase:

If the Lambda function does not receive any invocations for a period of time, this phase initiates. In the Shutdown phase, Lambda shuts down the runtime, alerts the extensions to let them stop cleanly, and then removes the environment. Lambda sends a shutdown event to each extension, which tells the extension that the environment is about to be shut down.

Did you find this article valuable?

Support SIDDHANI VAMSI SAI KUMAR by becoming a sponsor. Any amount is appreciated!