AWS Lambda offers Serverless computing

Lambda lets you run code without provisioning or managing servers, where you pay only for the compute time when the code is running.

Lambda allows running of code for any type of application or backend service with zero administration.

Runs stateless code

Supports Node.js, Java, Python, C#, Go, and Ruby

Runs your code on a schedule or in response to events (e.g., changes to data in an Amazon S3 bucket or an Amazon DynamoDB table)

Lambda performs provisioning, monitoring fleet health, applying security patches to the underlying compute resources, deploying code, running a web service front end, and monitoring and logging the code.

Scalability and availability

1. • Lambda provides easy scaling and high availability to the code.

   • Lambda is designed to process events within milliseconds.

   • Latency will be higher immediately after a Lambda function is created, updated, or if it has not been used recently.

   • Lambda is designed to run many instances of the functions in parallel.

   • Lambda is designed to use replication and redundancy to provide high availability for both the service and the Lambda functions it operates.

   • There are no maintenance windows or scheduled downtimes.

   •  Lambda function updates, there is a brief window of time, less then a minute, when requests would be served by both the versions.

   • Lambda has a default safety throttle for number of concurrent executions per account per region.

All calls made to AWS Lambda must complete execution with a timeout to any value between 1 and 900 seconds. Default timeout is 3 seconds. 

AWS Step Functions can help coordinate a series of Lambda functions in a specific order. Multiple Lambda functions can be invoked sequentially, passing the output of one to the other, and/or in parallel, while the state is being maintain by Step Functions.

AWS X-Ray helps tracing for Lambda functions, which provides insights such as Lambda service overhead, function init time, and function execution time.

Lambda functions consist of:

1. • Your code 

   • Its associated dependencies

   • Its configuration

Configuration consists of information such as the:

1. • Handler that will receive the event

   • IAM role that Lambda can assume to execute the function on your behalf

   • Compute resource you want allocated

   • Execution timeout

Your code can also use layers that provide shared code or custom runtimes.

You can configure your Lambda runtime environment. You can configure concurrency, memory allocation, timeouts and more.   

You must provide additional VPC-specific configuration information such as VPC subnet IDs and security group IDs in order to enable your Lambda functions to access resources in an Amazon VPC, 

You can use environment variables to adjust your function's behavior without updating code. 

Each Lambda function has associated configuration information, such as its name, description, entry point, and resource requirements.

Lambda may choose to retain an instance of the function and reuse it to serve a subsequent request, rather than creating a new copy.

Each Lambda function receives 500MB of non-persistent disk space in its own /tmp directory.

Design Lambda function as stateless launching as many copies of the function as needed as per the demand.

1. • Local file system access, child processes, and similar artifacts may not extend beyond the lifetime of the request.

   • State can be maintained externally in DynamoDB or S3.

Lambda function can be granted permissions to access other resources using an IAM role.

Restrictions

1. • Inbound network connections are blocked by AWS Lambda.

   • Outbound connections only TCP/IP sockets are supported.

   • ptrace (debugging) system calls are blocked.

   • TCP port 25 traffic is also blocked as an anti-spam measure.

Lambda automatically monitors functions, reporting real-time metrics through CloudWatch, including total requests, latency, error rates, and throttled requests.

Lambda automatically integrates with CloudWatch logs, creating a log group for each function and providing basic application lifecycle event log entries, including logging the resources consumed for each use of that function.

Lambda functions supports code written in: Node.js (JavaScript), Python, Java (11), C# (.NET Core),  Go and  Ruby.

Versioning

1. • Each AWS Lambda function has a single current version of the code and there is no versioning of the same function.

   • Each Lambda function version has a unique ARN and after it is published it is immutable.

   • Versioning can be implemented using Aliases.

   • Lambda supports creating aliases, which are mutable, for each Lambda function versions.

   • Each alias maintains an ARN for a function version to which it points

   • An alias can only point to a function version, not to another alias.

   • Alias helps in rolling out new changes or rolling back to old versions.

   • Lambda doesn't create a new version if the code in the unpublished version is the same as the previous published version. 

   • You need to deploy code changes in $LATEST before you can create a new version. 

Failure Handling

1. • For S3 bucket notifications and custom events, Lambda will attempt execution of the function three times in the event of an error condition in the code or if a service or resource limit is exceeded.

   • For ordered event sources, for e.g. DynamoDB Streams and Kinesis streams, that Lambda polls, it will continue attempting execution in the event of a developer code error until the data expires.

   • Kinesis and DynamoDB Streams retain data for a minimum of 24 hours.

   • Dead Letter Queues can be configured for events to be placed, once the retry policy for asynchronous invocations is exceeded.

Trigger

1. • Events that invoke the call. You can set up your code to initiate from other AWS services automatically or call it directly from any web or mobile app.

Code

1. Upload your code as a Lambda function. 

2. The code can be in any of the supported languages or use custom runtimes and native libraries. 

3. AWS Lambda stores code in Amazon S3 and encrypts it at rest.

Configuration

1. When you create the function, specify configuration information such as permissions, resources, credentials, and environment variables.

Extensions

1. Integrate Lambda with existing tools, such as tools used for monitoring, observability, security, and governance.

Lambda runtime environment (Execution Context)

1. Execution Context is a temporary runtime environment that initializes any external dependencies of the Lambda function code, for e.g. database connections or HTTP endpoints.

2. Lambda invokes your function in a secure and isolated container created according to resources defined by the configuration. 

3. Lambda then loads into memory the code that is to be run. 

4. This Lambda runtime environment manages the resources required to run your function and supports the lifecycle of the function’s runtime. 

5. The process of creating and mounting the environment is called a cold start. 

6. After the environment is set up, Lambda retains the environment and handles requests. 

7. The invocation of a Lambda function after the environment exists (with its layers, initialization, and runtime setup) is known as a warm start. 

8. This new runtime does not share resources with other Lambda runtime environments.

9. All requests are limited to 15 minutes (900 seconds) of running time. The default timeout is 3 seconds.

Canary managment

1. With the introduction of alias traffic shifting, it is now possible to trivially implement canary deployments of Lambda functions. 

2. By updating additional version weights on an alias, invocation traffic is routed to the new function versions based on the weight specified. 

3. Detailed CloudWatch metrics for the alias and version can be analyzed during the deployment, or other health checks performed, to ensure that the new version is healthy before proceeding. 

4. Example:

   • # Point alias to new version, weighted at 5% (original version at 95% of traffic)

   • aws lambda update-alias --function-name myfunction --name myalias --routing-config '{"AdditionalVersionWeights" : {"2" : 0.05} }'

   • # Verify that the new version is healthy

   • …

   • # Set the primary version on the alias to the new version and reset the additional versions (100% weighted)

   • aws lambda update-alias --function-name myfunction --name myalias --function-version 2 --routing-config '{}'

   • 
     

5. v

Core components of Lambda are Lambda functions and event sources.

1. • An AWS Lambda event source is the AWS service or custom application that publishes events.

   • Lambda function is the custom code that processes the events.

An event source is an AWS service or developer-created application that produces events that trigger an AWS Lambda function to run.

Events are passed to a Lambda function as an event input parameter.

 For batch event sources, such as Kinesis Streams, the event parameter may contain multiple events in a single call, based on the requested batch size.

Lambda Event Source Mapping;  configuration which maps an event source to a Lambda function. Enables automatic invocation of the Lambda function when events occur, identifies the type of events to publish and the Lambda function to invoke when events occur.

Error handling for a event source depends on how Lambda is invoked.

Lambda functions can be invoked on demand without the need to preconfigure any event source mapping in this case. 

Event sources can be both push and pull sources

1. • Push Model: Services like S3, SNS publish events to Lambda by invoking the cloud function directly. Event source mapping maintained on their side. Resource-based policy should be used to grant the event source necessary permissions

   • Pull Model: Lambda can also poll resources in services like Kinesis streams that do not publish events to Lambda. Need to have the event source mapping maintained on the Lambda side.

AWS Lambda can be configured as an event source for multiple AWS services .

Amazon S3

DynamoDB

Kinesis Streams

Simple Notification Service (SNS)

Simple Email Service (SES)

CloudFormation

CloudWatch Logs

CloudWatch Events

CodeCommit

Scheduled Events (powered by CloudWatch Events)

AWS Config

Amazon API Gateway

Application Load Balancers

Alexa

Amazon API Gateway

AWS CloudTrail

AWS CloudFormation 

Amazon Cognito

AWS Config

Amazon DynamoDB

Amazon Lex

Synchronous invocation

1. Lambda runs the function and waits for a response. The function runs immediately when it is invoked. 

2. When the function completes its run, Lambda returns the response from the function's code with additional data. Examples of data include status code and the version of the function that was run. 

3. This invocation model does not have build-in retries. 

Asynchronous (event) invocation

1. Lambda sends the event to a queue. 

2. A separate process reads events from the queue and runs your function. 

3. When the event is added to the queue, Lambda returns one of the following:

   1. A success response without additional information

   2. An error that indicates that it cannot add it to the event queue

4. You can send an invocation record, which contains details about the request and response, to a destination service, such as the following: 

   1. AWS Lambda

   2. Amazon SNS

   3. Amazon SQS

   4. Amazon EventBridge

5. Successful and unsuccessful events can have separate destinations. 

6. A best practice for asynchronous invocations is to create and use dead-letter queues to better handle message failures.

7. Built-in retries (2x)

Poll-based invocation

1. You can configure an AWS Lambda resource to read from a streaming-based or queuing-based event source and invoke your Lambda function.

2.  Examples of event sources include the following:

   1. Amazon DynamoDB

   2. Amazon Kinesis

   3. Amazon MQ

   4. Amazon Managed Streaming for Apache Kafka

   5. Self-managed Apache Kafka

   6. Amazon SQS 

3. This is known as event source mapping. It is used to process items from streams or queues in a service that does not normally invoke Lambda functions directly.

4. Retries depends on event sources.

For sensitive information, for e.g. passwords, AWS recommends using client-side encryption using AWS Key Management Service and store the resulting values as ciphertext in your environment variable. Lambda function code should include the logic to decrypt these values.

Lambda stores code in S3 and encrypts it at rest and performs additional integrity checks while the code is in use.

Each AWS Lambda function runs in its own isolated environment, with its own resources and file system view.

Permissions

1. Invocation permissions

   1. Grant event sources permission to invoke Lambda

   2. Update the access policy associated with your Lambda function

   3. Use the Lambda AddPermission API

2. Processing permissions

   1. Grant AWS Lambda permission to read from the stream

   2. Update the execution role

Push Permissions

1. You grant these event sources permissions to invoke your Lambda function by updating the access policy associated with your Lambda function.

2. AWS Lambda provides the AddPermission API for this purpose.

Pull Permissions

1. You do this by updating the IAM execution role associated with your Lambda function. 

Can be configured to connect to private subnets in a cloud (VPC) .

Lambda runs the function code securely within a VPC by default.

Lambda function connected to VPC can access private resources databases, cache instances, or internal services during execution.

To enable the Lambda function to access resources inside the private VPC, additional VPC-specific configuration information that includes private subnet IDs and security group IDs must be provided.

AWS Lambda uses this information to set up elastic network interfaces (ENIs) that enable the function to connect securely to other resources within your private VPC.

Lambda functions connected to VPC need a NAT Gateway to access any external resources outside of AWS.

Lambda functions cannot connect directly to a VPC with dedicated instance tenancy, instead peer it to a second VPC with default tenancy.

Canary

1. Traffic is shifted in two increments. 

2. You can choose from predefined canary options that specify the percentage of traffic shifted to your updated Lambda function version in the first increment. 

3. You can also choose the interval, in minutes. 

4. This shift to the updated Lambda function is completed before the remaining traffic is shifted in the second increment.

Linear

1. Traffic is shifted in equal increments, with an equal number of minutes between each increment. 

2. You can choose from predefined linear options that specify the percentage of traffic shifted in each increment and the number of minutes between each increment.

All-at-once

1. All traffic is shifted from the original Lambda function to the updated Lambda function version all at once.

Lambda@Edge allows running of code across AWS locations globally without provisioning or managing servers, responding to end users at the lowest network latency.

Lambda function can be configured to be triggered in response to CloudFront requests, which includes:

• Viewer Request – event occurs when an end user or a device on the Internet makes an HTTP(S) request to CloudFront, and the request arrives at the edge location closest to that user.

• Viewer Response – event occurs when the CloudFront server at the edge is ready to respond to the end user or the device that made the request.

• Origin Request – event occurs when the CloudFront edge server does not already have the requested object cached, and the viewer request is ready to be sent to backend origin webserver.

• Origin Response – event occurs when the CloudFront server at the edge receives a response from your backend origin webserver.

Lambda function executes across AWS locations globally when a request for content is received, and scales with the volume of CloudFront requests globally.

Lambda@Edge only supports Node.js for global invocation by CloudFront events at this time.

Lambda@Edge function does provide the capability to customize content. 

Lambda@Edge allows users to run their own Lambda functions to customize the content that CloudFront delivers, executing the functions in AWS Regions closer to the viewer.

 Lambda functions run in response to CloudFront events, without provisioning or managing servers. 

Use Lambda@Edge to customize content based on geography that CloudFront delivers and generate geography-specific URL.

Coordinates microservices using visual workflows

Useful if you need Lambda or API Gateway to act in parallel, in series, with retries, or with if/else statements

Allows you to step through the functions of your application

Automatically triggers and tracks each step

Provides simple error catching and logging if a step fails

Is a state machine (an object with a set number of operating conditions which depend on its previous condition to determine output)

States can perform a variety of functions in your state machine, including:

1. Task – Performs a single unit of work by doing the following:

2. Choice – Choose the appropriate branch of the flow.

3. Fail or Succeed – Stop the flow based on pass/fail.

4. Pass – Pass the input to the output as is, or combined with some fixed data.

5. Wait – Delay the flow for a specific amount of time.

6. Parallel – Begin parallel branching within the flow.

7. Map – Run the same steps for multiple entries of an array in the state input.

InputPath 

1. InputPath can limit the input that is passed by filtering the JSON notation by using a path 

2. The Parameters field enables you to pass a collection of key-value pairs, 

3. The ResultSelector field provides a way to manipulate the state’s result before ResultPath is applied. 

4. Example:

   1. {

   2.   "comment": "Example for InputPath.",

   3.   "dataset1": {

   4.     "val1": 1,

   5.     "val2": 2,

   6.     "val3": 3

   7.   },

   8.   "dataset2": {

   9.     "val1": "a",

   10.     "val2": "b",

   11.     "val3": "c"

   12.   }

   13. }

   14. You could apply the InputPath. 

   15. "InputPath": "$.dataset2",

   16. Result in:

   17. {

   18.   "val1": "a",

   19.   "val2": "b",

   20.   "val3": "c"

   21. }

   22. If you apply the path $.a[0:2], the following is the result.

   23. [ 1, 2 ]

ResultPath

1. The output of a state can be a copy of its input, the result it produces (for example, output from a Task state’s Lambda function), or a combination of its input and result. 

2. Result Options:

   1. Condition: ResultPath is not provided.

   2. Result: Input discarded; raw output is used.

   3. Condition: ResultPath is null.

   4. Result: State input is state output.

   5. Condition: ResultPath set the combined JSON.

   6. Result: Includes state output with state input.

   7. Condition: ResultPath produces plural output.

   8. Result: Not allowed, validator rejects it.

OutputPath

1. OutputPath enables you to select a portion of the state output to pass to the next state. 

2. This enables you to filter out unwanted information, and pass only the portion of JSON that you care about. 

Example

1. { "Comment": "Example of the Amazon States Language using a Pass state",

2.   "StartAt": "DynamoDB GetItem",

3.   "States": {

4. "DynamoDB GetItem": {

5.    "Type": "Task",

6.       "Resource": "arn:aws:states:::dynamodb:getItem",

7.    "Parameters": { "TableName": "NoteInventory", "Key": { "NoteName": {"S.$": "$.note" } } },

8.    "ResultPath": "$.DynamoDB",

9.       "Catch": [  { "ErrorEquals": [ "States.ALL“   ], "Next": "Fail“ }],

10.       "Next": "Lambda Invoke"

11. },

12. "Lambda Invoke": {

13.    "Type": "Task",

14.    "Resource": "arn:aws:states:::lambda:invoke",

15.    "OutputPath": "$.Payload",

16.    "Parameters": {

17.      "Payload.$": "$",

18.      "FunctionName": "arn:aws:lambda:us-east-2:069025409925:function:ProcessDynamoDBRecords2:$LATEST"

19.    },

20.       "Retry": [

21.      {"ErrorEquals": [ "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException“ ],

22.        "IntervalSeconds": 2,

23.        "MaxAttempts": 6,  …

Error handling example:

1. { 

2.   "Comment": "Call out to a RESTful service", 

3.   "StartAt": "Call out", 

4.   "States": { 

5.     "Call out": { 

6.       "Type": "Task", 

7.       "Resource": 

8.         "arn:aws:lambda:eu-central-1:123456789012:function:RestCallout", 

9.       "Retry": [ 

10.         { "ErrorEquals": [ "HandledError" ], "MaxAttempts": 10 }

11.       ],

12.       "End": true

13.     }  

14.   } 

15. }

Parallel Execution Example

1. "Send for OCR": {
   "Type": "Parallel",
   "Next": "Pick result",
   "Branches": [
   {
   "StartAt": "Prep1",
   "States": {
       "Prep1": {
   "Type": "Pass",
   "Result": { "inputList": [ "OCR Provider 1" ]  },
   "Next": "Go1“
   },
       "Go1": {
   "Type": "Task",
   "Resource": "arn:aws:lambda:eu-central-1:123456789012:function:StatesBot",
   "End": true
       }

2.         } 

3.     ]

By default, the Amazon States Language doesn't set timeouts in state machine definitions. 

1. Without an explicit timeout, Step Functions often relies solely on a response from an activity worker to know that a task is complete. 

2. If something goes wrong and TimeoutSeconds isn't specified, an execution is stuck waiting for a response that will never come.

3. Ensure to specify a timeout in state machine definitions. 

Executions that pass large payloads of data between states can be terminated. 

If the data you pass between states might grow to over 32 KB, use Amazon Simple Storage Service (Amazon S3) to store the data, and pass the Amazon Resource Name instead of the raw data. 

1. Alternatively, adjust your implementation so that you pass smaller payloads in your executions.

Lambda function code should be stateless, and ensure there is no affinity between the code and the underlying compute infrastructure.

Instantiate AWS clients outside the scope of the handler to take advantage of connection re-use.

Make sure you have set +rx permissions on your files in the uploaded ZIP to ensure Lambda can execute code on your behalf.

Lower costs and improve performance by minimizing the use of startup code not directly related to processing the current event.

Use the built-in CloudWatch monitoring of your Lambda functions to view and optimize request latencies.

Delete old Lambda functions that you are no longer using.

When we are using Cognito ff you get a LambdaThrottledException exception, you should retry the sync operation (update records). 

Separate the Lambda handler from your core logic. This allows you to make a more unit-testable function. In Node.js this may look like: 

1. exports.myHandler = function(event, context, callback) {

2. var foo = event.foo;

3. var bar = event.bar;

4. var result = MyLambdaFunction (foo, bar);

5. 
   

6. callback(null, result);

7. }

8. 
   

9. function MyLambdaFunction (foo, bar) {

10. // MyLambdaFunction logic here

11. }

Take advantage of execution environment reuse to improve the performance of your function. 

1. Initialize SDK clients and database connections outside of the function handler, and cache static assets locally in the /tmp directory. 

2. Subsequent invocations processed by the same instance of your function can reuse these resources. This saves cost by reducing function run time. 

Use a keep-alive directive to maintain persistent connections. 

1. To maintain your persistent connection 

Use environment variables to pass operational parameters to your function. 

Control the dependencies in your function's deployment package. 

1. To have full control of the dependencies your function uses, package all of your dependencies with your deployment package. 

Minimize your deployment package size to its runtime necessities. 

Reduce the time it takes Lambda to unpack deployment packages 

1. In Java by putting your dependency .jar files in a separate /lib directory. 

Minimize the complexity of your dependencies. 

1. Prefer simpler frameworks that load quickly on execution environment startup. 

Avoid using recursive code in your Lambda function.

Do not use non-documented, non-public APIs in your Lambda function code. 

1. Lambda periodically applies security and functional updates to Lambda's internal APIs. These internal API updates may be backwards-incompatible.

Performance testing your Lambda function is a crucial part in ensuring you pick the optimum memory size configuration. 

1. Any increase in memory size triggers an equivalent increase in CPU available to your function. 

To find the right memory configuration for your functions, we recommend using the open source AWS Lambda Power Tuning project. 

1. To optimize function performance, we also recommend deploying libraries that can leverage Advanced Vector Extensions 2 (AVX2). 

Load test your Lambda function to determine an optimum timeout value. 

1. It is important to analyze how long your function runs so that you can better determine any problems with a dependency service that may increase the concurrency of the function beyond what you expect. 

Use most-restrictive permissions when setting IAM policies. 

Be familiar with Lambda quotas. 

Memory allocation=128 MB to 10,240 MB

Max runtime (Time out)=15 minutes

Burst concurrency=500–3000 (varies by Region)

Invocation payloads=Synchronous: 6 MB  & Asynchronous: 256 KB 

Deployment package=Zip: 50 MB; unzipped: 250 MB; from console: 3 MB & Container image: 10 GB 

/tmp directory storage=512 MB

Concurrent executions: 1,000

Storage for uploaded functions (.zip file archives) and layers: 75 GB 

ENIs per (VPC): 250 

Function environment variables: 4 KB

Function resource-based policy: 20 KB

Function layers : five layers

Function burst concurrency : 500 - 3000 (varies per Region)

Invocation payload (request and response) : 6 MB (synchronous) 256 KB (asynchronous)

Test events (console editor) : 10

File descriptors : 1024

Execution processes/threads : 1024

Invocation requests per Region (requests per second) : 10 x concurrent executions quota (synchronous, all sources) 

Invocation requests per Region (requests per second) for asynchronous AWS service sources : Unlimited requests accepted. 

Invocation requests per function version or alias (requests per second) : 10 x allocated provisioned concurrency

GetFunction API requests : 100 requests per second

GetPolicy API requests : 15 requests per second

Remainder of the control plane API requests (excludes invocation, GetFunction, and GetPolicy requests) : 15 reques

Execution time

The duration price depends on the amount of memory allocated to the function. 

Lambda function charges you based on the number of requests, such as $0.20 per 1M requests. 

You propose to increase the allocated memory of the Lambda function. The cost may not increase as the execution time for the Lambda may be less although you will be charged more for the memory. 

Optimize the Lambda function so that the function executes the code faster. 

Simple Lambda Function Example