AWS Lambda lets you run code as functions without provisioning or managing servers. With serverless computing, your application still runs on servers, but all the server management is done by AWS.
- Lambda-based applications are composed of
functionstriggered byevents. - You cannot log in to the compute instances that run Lambda functions or customize the operating system or language runtime.
- You specify the amount of memory you need allocated to your Lambda functions.
- AWS Lambda allocates CPU power proportional to the memory you specify using the same ratio as a general purpose EC2 instance type.
- Lambda assumes an IAM role when it executes the function.
- AWS Lambda stores code in
Amazon S3and encrypts it at rest. - Lambda scales concurrently executing functions up to your default limit (
1000). - Lambda functions are serverless and independent,
1 event = 1 function. - You can't create a VPC endpoint for AWS Lambda. You can, however, connect a Lambda function to a VPC.
- Using Lambda functions with AWS services as event sources.
- On-demand Lambda function invocation over HTTPS using Amazon API Gateway (custom REST API and endpoint).
- On-demand Lambda function invocation using custom applications (mobile, web apps, clients) and AWS SDKs, AWS Mobile SDKs, and the AWS Mobile SDK for Android.
- Scheduled events can be configured to run code on a scheduled basis through the AWS Lambda Console.
function handler (event, context) {
}- The context object in a Lambda function provides metadata about the function and the current invocation, including a unique identifier for the request, awsRequestId, which can be used to correlate logs from a specific invocation.
- Consist of code and any associated dependencies.
- Configuration information is associated with the function.
- You specify the configuration information when you create the function.
- API provided for updating configuration data.
- Functions can access:
- AWS services or non-AWS services.
- AWS services running in VPCs (e.g. RedShift, Elasticache, RDS instances).
- Non-AWS services running on EC2 instances in an AWS VPC.
- There is a maximum execution timeout.
- Max is
15 minutes (900 seconds), default is3 seconds. - You pay for the time it runs.
- Lambda terminates the function at the timeout.
- Max is
There are two workable procedures for deploying the Lambda function using a CloudFormation template:
Writing code in CloudFormation template
Firstly, you can create an AWS::Lambda::Function resource in the template, then write the code directly inside the CloudFormation template. This is possible for simple functions using Node.js or Python which allow you to declare the code inline in the CloudFormation template.
For example:
Uploading a ZIP file
The other option is to upload a ZIP file containing the function code to Amazon S3, then add a reference to it in an AWS::Lambda::Function resource in the template. To declare this in your AWS CloudFormation template, you can use the following syntax (within AWS::Lambda::Function Code):
The execution context is a temporary runtime environment that initializes any external dependencies of your Lambda function code, such as database connections or HTTP endpoints. This affords subsequent invocations better performance because there is no need to “cold-start” or initialize those external dependencies. After a Lambda function is executed, AWS Lambda maintains the execution context for some time in anticipation of another Lambda function invocation. In effect, the service freezes the execution context after a Lambda function completes, and thaws the context for reuse, if AWS Lambda chooses to reuse the context when the Lambda function is invoked again.
- You can invoke Lambda functions directly with the Lambda console, the Lambda API, the AWS SDK, the AWS CLI, and AWS toolkits.
- You can also configure other AWS services to invoke your function, or you can configure Lambda to read from a stream or queue and invoke your function.
- When you invoke a function, you can choose to invoke it synchronously or asynchronously.
Synchronous Invocation
When you invoke a function synchronously, Lambda runs the function and waits for a response.
To invoke a function synchronously with the AWS CLI, use the invoke command.
$ aws lambda invoke -–function-name my-function -–payload ‘{ “key”: “value” }’
response.json
{ “ExecutedVersion”: “$LATEST”, “StatusCode”: 200 }Asynchronous Invocation
For asynchronous invocation, Lambda places the event in a queue and returns a success response without additional information. A separate process reads events from the queue and sends them to your function. To invoke a function asynchronously, set the invocation type parameter to Event.
$ aws lambda invoke --function-name my-function --invocation-type Event --payload '{ "key": "value" }'
response.json
{ "StatusCode": 202 }If Lambda can’t add the event to the queue, the error message appears in the command output.
Lambda is an event-driven compute service where AWS Lambda runs code in response to events such as changes to data in an S3 bucket or a DynamoDB table.
An event source is an AWS service or developer-created application that produces events that trigger an AWS Lambda function to run.
You can use event source mappings to process items from a stream or queue in services that don’t invoke Lambda functions directly.
Applications need permissions to invoke Lambda functions.
Services that Lambda reads events from:
Amazon Kinesis
Amazon DynamoDB
Amazon Simple Queue Service (SQS)
The configuration of the event source mapping for stream-based services (DynamoDB, Kinesis), and Amazon SQS, is made on the Lambda side. For other services such as Amazon S3 and SNS, the function is invoked
asynchronously, and the configuration is made on the source (S3/SNS) rather than Lambda.
Versioning means you can have multiple versions of your function. Versions are immutable (code cannot be edited). Each version has its own ARN.
The function version includes the following information:
- The function code and all associated dependencies.
- The Lambda runtime that executes the function.
- All the function settings, including the environment variables.
- A unique
Amazon Resource Name (ARN)to identify this version of the function.
A qualified ARN has a version suffix. An unqualified ARN does not have a version suffix. You cannot create an alias from an unqualified ARN.
- Lambda aliases are pointers to a specific Lambda version.
- Using an alias you can invoke a function without having to know which version of the function is being referenced.
- Aliases are mutable.
- Aliases enable stable configuration of event triggers / destinations.
- Aliases also have static ARNs but can point to any version of the same function.
- Aliases can also be used to split traffic between Lambda versions (blue/green).
- Aliases enable blue / green deployment by assigning weights to Lambda version (doesn’t work for $LATEST, you need to create an alias for $LATEST).
The following example AWS CLI command points an alias to a 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} }'You can set a reserved concurrency at the function level to guarantee a set number of concurrent executions will be available for a critical function.
You can reserve up to the Unreserved account concurrency value that is shown in the console, minus 100 for functions that don’t have reserved concurrency.
To throttle a function, set the reserved concurrency to zero. This stops any events from being processed until you remove the limit.
When provisioned concurrency is allocated, the function scales with the same burst behavior as standard concurrency.
After it’s allocated, provisioned concurrency serves incoming requests with very low latency.
When all provisioned concurrency is in use, the function scales up normally to handle any additional requests.
Application Auto Scaling takes this a step further by providing autoscaling for provisioned concurrency.
With Application Auto Scaling, you can create a target tracking scaling policy that adjusts provisioned concurrency levels automatically, based on the utilization metric that Lambda emits.
Provisioned concurrency runs continually and is billed in addition to standard invocation costs.
A dead-letter queue saves discarded events for further processing. A dead-letter queue acts the same as an on-failure destination in that it is used when an event fails all processing attempts or expires without being processed.
However, a dead-letter queue is part of a function’s version-specific configuration, so it is locked in when you publish a version. On-failure destinations also support additional targets and include details about the function’s response in the invocation record.
You can setup a DLQ by configuring the ‘DeadLetterConfig’ property when creating or updating your Lambda function.
You can provide an SQS queue or an SNS topic as the TargetArn for your DLQ, and AWS Lambda will write the event object invoking the Lambda function to this endpoint after the standard retry policy (2 additional retries on failure) is exhausted.
You can configure your Lambda function to pull in additional code and content in the form of layers.
A layer is a ZIP archive that contains libraries, a custom runtime, or other dependencies.
With layers, you can use libraries in your function without needing to include them in your deployment package.
A function can use up to 5 layers at a time.
Layers are extracted to the /opt directory in the function execution environment.
Each runtime looks for libraries in a different location under /opt, depending on the language.
Lambda@Edge allows you to run code across AWS locations globally without provisioning or managing servers, responding to end users at the lowest network latency.
The functions run in response to CloudFront events, without provisioning or managing servers. You can use Lambda functions to change CloudFront requests and responses at the following points:
After CloudFront receives a request from a viewer (viewer request).
Before CloudFront forwards the request to the origin (origin request).
After CloudFront receives the response from the origin (origin response).
Before CloudFront forwards the response to the viewer (viewer response).
Exam note:
Lambda@Edgefunctions can only be created in theus-east-1Region. If you want to deploy such functions, they must be done in this specific region.
You can connect a Lambda function to private subnets in a VPC.
Lambda needs the following VPC configuration information so that it can connect to the VPC:
- Private subnet ID.
- Security Group ID (with required access).
Lambda uses this information to setup an Elastic Network Interface (ENI) using an available IP address from your private subnet.
Lambda functions provide access only to a single VPC. If multiple subnets are specified, they must all be in the same VPC.
Lambda functions configured to access resources in a particular VPC will not have access to the Internet as a default configuration. If you need access to the internet, you will need to create a NAT in your VPC to forward this traffic and configure your security group to allow this outbound traffic.
Exam tip: If a Lambda function needs to connect to a VPC and needs Internet access, make sure you connect to a private subnet that has a route to a NAT Gateway (the NAT Gateway will be in a public subnet).
Lambda uses your function’s permissions to create and manage network interfaces. To connect to a VPC, your function’s execution role must have the following permissions:
ec2:CreateNetworkInterface
ec2:DescribeNetworkInterfaces
ec2:DeleteNetworkInterfaceThese permissions are included in the AWSLambdaVPCAccessExecutionRole managed policy.
Only connect to a VPC if you need to as it can slow down function execution.
AWS Lambda uses environment variables to facilitate communication with the X-Ray daemon and configure the X-Ray SDK.
_X_AMZN_TRACE_ID: Contains the tracing header, which includes the sampling decision, trace ID, and parent segment ID. If Lambda receives a tracing header when your function is invoked, that header will be used to populate the _X_AMZN_TRACE_ID environment variable. If a tracing header was not received, Lambda will generate one for you.
AWS_XRAY_CONTEXT_MISSING: The X-Ray SDK uses this variable to determine its behavior in the event that your function tries to record X-Ray data, but a tracing header is not available. Lambda sets this value to LOG_ERROR by default.
AWS_XRAY_DAEMON_ADDRESS: This environment variable exposes the X-Ray daemon’s address in the following format: IP_ADDRESS:PORT. You can use the X-Ray daemon’s address to send trace data to the X-Ray daemon directly without using the X-Ray SDK.
-
The Lambda function and target group must be in the same account and in the same Region.
-
The maximum size of the request body that you can send to a Lambda function is 1 MB.
-
The maximum size of the response JSON that the Lambda function can send is 1 MB.
-
WebSockets are not supported. Upgrade requests are rejected with an HTTP 400 code.
-
By default, health checks are disabled for target groups of type lambda.
-
Memory – minimum
128 MB, maximum10,240 MBin1 MBincrements. -
Ephemeral disk capacity (/tmp space) per invocation –
512 MB. -
Size of environment variables maximum
4 KB. -
Number of file descriptors –
1024. -
Number of processes and threads (combined) –
1024. -
Maximum execution duration per request –
900 seconds. -
Concurrent executions per account –
1000 (soft limit). -
Function burst concurrency –
500 - 3000 (region dependent).
Invocation payload:
Synchronous `6 MB`.
Asynchronous `256 KB`
Lambda function deployment size is `50 MB (zipped), 250 MB unzipped`.Priced based on:
- Number of requests.
- Duration of the request calculated from the time your code begins execution until it returns or terminates.
- The amount of memory allocated to the function.
A serverless application is a combination of Lambda functions, event sources, and other resources that work together to perform tasks. Note that a serverless application is more than just a Lambda function—it can include additional resources such as APIs, databases, and event source mappings.
The AWS Serverless Application Model (AWS SAM) is an open-source framework designed to streamline the building and deployment of serverless applications on AWS. By simplifying the process of creating and managing resources, it significantly reduces the complexity usually associated with traditional architectures.
These are configuration files, written in YAML or JSON, that specify the resources used in your AWS serverless application. They are an extension of AWS CloudFormation templates, providing a simplified syntax for defining serverless resources such as Lambda functions, API Gateway APIs, and DynamoDB tables.
There are several resource types:
AWS::Serverless::Function (AWS Lambda)
AWS::Serverless::Api (API Gateway)
AWS::Serverless::SimpleTable (DynamoDB)
AWS::Serverless::Application (AWS Serverless Application Repository)
AWS::Serverless::HttpApi (API Gateway HTTP API)
AWS::Serverless::LayerVersion (Lambda layers)
The SAM CLI is a vital tool for local development and testing of serverless applications. It provides commands for all phases of the development lifecycle, from debugging your application locally to deploying your code in the AWS cloud. Provides a Lambda-like execution environment that lets developers locally build, test, and debug applications defined by SAM templates.
- Offers a shorthand syntax to express functions, APIs, databases, and event source mappings.
- SAM seamlessly transforms and expands this syntax into AWS CloudFormation syntax, facilitating faster and more efficient construction of serverless applications.
- AWS SAM supports all AWS CloudFormation template items such as
Outputs,Mappings,Parameters, providing developers with the comprehensive tooling needed to build robust and scalable serverless applications.
Note:
sam deploynow implicitly performs the functionality ofsam package. You can use thesam deploycommand directly to package and deploy your application.
All SAM commands:
sam build # resolve dependencies and construct deployment artifacts for all functions and layers in the SAM template.
sam delete
sam deploy # deploy the application with a specified CloudFormation stack
sam init # creating a new SAM project
sam list
sam local generate-event
sam local invoke
sam local start-api
sam local start-lambda
sam logs
sam package (DECOMMISSIONED)
sam pipeline bootstrap
sam pipeline init
sam publish # publish applications to the AWS Serverless Application Repository
sam remote invoke
sam remote test-event
sam sync # quick syncing of local changes to AWS, more suitable for rapid development testing not for production.
sam traces
sam validate- Only two commands are required to package and deploy serverless apps in AWS.
sam build > sam package (decommissioned) / sam deploy # OR aws cloudformation package aws cloudformation deploy
The following example shows a YAML-formatted template fragment.
AWSTemplateFormatVersion: 1.1 # required
Transform: AWS::Serverless-2016-10-31 # required
Globals: # optional but recommended
set of globals
Description:
String
Metadata:
template metadata
Parameters:
set of parameters
Mappings:
set of mappings
Conditions:
set of conditions
Resources: # required
set of resources
Outputs:
set of outputsAWSTemplateFormatVersion: This specifies the AWS CloudFormation template version that the SAM template is based on.
Resources: This is the most important section, where you define the AWS resources that make up your serverless application. This includes Lambda functions, API Gateway APIs, DynamoDB tables, and other resources. In AWS SAM templates the Resources section can contain a combination of AWS CloudFormation resources and AWS SAM resources.
Parameters (Opt): Allows customization of your template by passing parameters during deployment (e.g., environment variables, resource names).
Outputs (Opt): This section defines output values that can be returned after the application is deployed. These outputs can be used to reference resource attributes or other values.
Mappings (Opt): This section is used to define reusable mappings of keys and values that can be referenced in other parts of the template.
Conditions (Opt): This section defines conditions that can be used to control the creation of resources based on certain criteria.
Transform: This declaration identifies an AWS CloudFormation template file as an AWS SAM template file.
Globals (Opt but recommended): This section is unique to SAM and defines global settings that apply to all resources in the template, such as function memory size, timeout, or environment variables.
Metadata (Opt): Optional section for adding additional information about your template or resources, such as descriptions or tags.
Overall, AWS SAM templates provide a structured way to define and deploy serverless applications on AWS, leveraging AWS CloudFormation for infrastructure management while simplifying the definition of serverless resources.
-
Works seamlessly with popular integrated development environments (IDEs) like PyCharm, IntelliJ, and VS Code. Also integrates with a comprehensive suite of AWS serverless tools.
-
Can leverage AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline to construct an efficient and reliable deployment pipeline for your serverless applications.
-
With SAM CLI, you can locally build, test, and debug applications defined by SAM templates. This accelerates the development cycle by providing immediate feedback. The SAM CLI provides a Lambda-like execution environment that lets developers locally build, test, and debug applications defined by SAM templates.
-
AWS SAM is an extension of AWS CloudFormation, which means you can use all the powerful, flexible features of CloudFormation in addition to serverless-specific capabilities.
-
AWS SAM templates are designed with best practices in mind, incorporating built-in application lifecycle management features such as safe deployments and rollback capabilities
-
AWS SAM enables you to deploy your infrastructure as configuration. This practice facilitates the implementation of additional best practices such as code reviews, which contribute to higher code quality and fewer deployment issues.
-
AWS SAM can be restrictive when it comes to API Gateway configuration. While it simplifies many aspects, it doesn’t offer the same level of flexibility as manual or Serverless Framework configurations.
-
Compared to the Serverless Framework, AWS SAM has fewer plugins available.
The primary differences between AWS SAM templates and AWS CloudFormation templates are the following:
• Transform declaration. The declaration Transform: AWS::Serverless-2016-10-31 is required for AWS SAM templates. This declaration identifies an AWS CloudFormation template as an AWS SAM template.
• Globals section. The Globals section is unique to AWS SAM. It defines properties that are common to all your serverless functions and APIs. All the AWS::Serverless::Function, AWS::Serverless::Api, and AWS::Serverless::SimpleTable resources inherit the properties that are defined in the Globals section.
• Resources section. In AWS SAM templates the Resources section can contain a combination of AWS CloudFormation resources and AWS SAM resources.
With AWS Step Functions, you can create visual workflows, also called state machines, to build distributed applications, automate processes, orchestrate microservices, and create data and machine learning pipelines.
Step Functions is based on state machines and tasks. In Step Functions, state machines are called workflows, which are a series of event-driven steps. Each step in a workflow is called a state. For example, a Task state represents a unit of work that another AWS service performs, such as calling another AWS service or API. Instances of running workflows performing tasks are called executions in Step Functions
- Define the steps of your workflow in the JSON-based Amazon States Language. The visual console automatically graphs each step in the order of execution.
- Start an execution to visualize and verify the steps of your application are operating as intended. The console highlights the real-time status of each step and provides a detailed history of every execution.
- AWS Step Functions operates and scales the steps of your application and underlying compute for you to help ensure your application executes reliably under increasing demand.
It is a managed workflow and orchestration platform.
It is scalable and highly available.
You define your app as a state machine.
Create tasks, sequential steps, parallel steps, branching paths or timers.
Uses Amazon State Language declarative JSON.
Apps can interact and update the stream via Step Function API.
Provides a visual interface which describes flow and real-time status.
Provides detailed logs of each step execution.
- Built-in error handling – AWS Step Functions tracks the state of each step, so you can automatically retry failed or timed-out tasks, catch specific errors, and recover gracefully, whether the task takes seconds or months to complete.
- Automatic Scaling – AWS Step Functions automatically scales the operations and underlying compute to run the steps of your application for you in response to changing workloads. Step Functions scales automatically to help ensure the performance of your application workflow remains consistently high as the frequency of requests increases.
- Pay per use – With AWS Step Functions, you pay only for the transition from one step of your application workflow to the next, called a state transition. Billing is metered by state transition, regardless of how long each state persists (up to one year).
- Execution event history – AWS Step Functions creates a detailed event log for every execution, so when things do go wrong, you can quickly identify not only where, but why. All of the execution history is available visually and programmatically to quickly troubleshoot and remediate failures.
- High availability – AWS Step Functions has built-in fault tolerance. Step Functions maintains service capacity across multiple Availability Zones in each region to help protect application workflows against individual machine or data center facility failures. There are no maintenance windows or scheduled downtimes.
- Administrative security – AWS Step Functions is integrated with AWS Identity and Access Management (IAM). IAM policies can be used to control access to the Step Functions APIs.
A Step Functions execution receives a JSON text as input and passes that input to the first state in the workflow. Individual states receive JSON as input and usually pass JSON as output to the next state. Understanding how this information flows from state to state and learning how to filter and manipulate this data is key to effectively designing and implementing workflows in AWS Step Functions.
A state machine is a collection of states that define the workflow. It's defined using the Amazon States Language (ASL), which is a JSON-based language.
States are the building blocks of a state machine. There are different types of states:
Task State : Represents a single unit of work that can be performed by an AWS service, a Lambda function, or an activity worker.
Choice State : Allows you to branch your workflow based on certain conditions.
Wait State : Delays the workflow execution for a specified period or until a specified condition is met.
Parallel State : Allows you to execute multiple branches of your workflow in parallel.
Map State : Allows you to run a set of steps for each element of an input array in parallel.
Succeed State : Stops the execution of the workflow successfully.
Fail State : Stops the execution of the workflow with a failure.
In the Amazon States Language (ASL), these fields filter and control the flow of JSON from state to state:
– InputPath
– OutputPath
– ResultPath
– Parameters
Both the InputPath and Parameters fields provide a way to manipulate JSON as it moves through your workflow. InputPath can limit the input that is passed by filtering the JSON notation by using a path. The Parameters field enables you to pass a collection of key-value pairs, where the values are either static values that you define in your state machine definition, or that are selected from the input using a path.
AWS Step Functions applies the InputPath field first, and then the Parameters field. You can first filter your raw input to a selection you want using InputPath, and then apply Parameters to manipulate that input further, or add new values.
The output of a state can be a copy of its input, the result it produces (for example, the output from a Task state’s Lambda function), or a combination of its input and result. Use ResultPath to control which combination of these is passed to the state output.
OutputPath enables you to select a portion of the state output to pass to the next state. This enables you to filter out unwanted information, and pass only the portion of JSON that you care about.
You can use a Include a Catch block in state machine to capture the errors in a Task or Parallel State. A catcher contains following fields:
ErrorEquals- array of strings with error namesNext- A string that must match exactly one of the state namesResultPath- a path that determines what input was sent to the state specified inNextfield.
| Feature | AWS Step Functions | Amazon SWF |
|---|---|---|
| Workflow Definition | JSON-based Amazon States Language | Code (deciders) |
| Complexity | Simpler, more developer-friendly | More complex, requires more coding effort |
| Execution Model | Serverless, automatic scaling | Requires managing and scaling decider and worker components |
| Task Coordination | Through state machine definition | Through decider logic |
| Pricing Model | Based on state transitions | Based on workflow/activity executions and duration |
| External Signals | Not supported | Supported |
| Child Workflows | Not supported | Supported, can return results to parent workflow |
| Recommended For | New applications | Applications requiring external signals or child workflows |