1 of 78

Module 7: Developing Event-Driven Serverless Solutions

AWS Academy Cloud Developing

2 of 78

Section 1: Introduction

Module 7: Developing Event-Driven Serverless Solutions

3 of 78

Module objectives

At the end of this module, you should be able to:

Explain serverless computing
Describe how AWS Lambda works
Recognize Lambda invocation models
Identify how to use AWS Identity and Access Management (IAM) to grant Lambda permissions
Indicate the steps to author and configure a Lambda function
Explain how to deploy Lambda functions
Identify why AWS X-Ray is a critical developer tool
Create Lambda functions

3

4 of 78

Module overview

Sections

Introduction
Introducing serverless computing
Introducing Lambda
Invoking Lambda functions
Setting permissions for Lambda
Authoring and configuring Lambda functions
Deploying Lambda functions
Monitoring and debugging tools for application developers

Demonstration

Using X-Ray with Lambda

Lab

Creating Lambda Functions Using the AWS SDK for Python

�

4

Knowledge check

5 of 78

Café business requirement

Sofía finished using the mock endpoints to test the API, and now she wants to launch the dynamic version of the café website. She needs to update the API integration to connect to the backend database.

5

6 of 78

Serverless as part of developing a cloud application

6

7 of 78

Section 2: Introducing serverless computing

Module 7: Developing Event-Driven Serverless Solutions

8 of 78

Serverless computing

8

Focus on business logic

Level of abstraction

Heavy capital expense
Guessed capacity
Deployed in months
Years of maintenance
Low innovation factor

On premises

Hardware independence
Elastic resources and scale
Faster provisioning
Reduced maintenance

Virtual servers in the cloud

Platform independence
Higher resource utilization
Easier and faster deployments
Isolation and sandboxing

Containers

No OS instances to manage
Flexible scaling
Pay per usage
Built-in fault tolerance
Zero maintenance

Serverless

One benefit of cloud computing is that you can abstract the infrastructure layer to alleviate many operational tasks. Thus, you can focus more on the business logic for your applications. You do not need to manage instances, operating systems, or servers. Everything that is required to run and scale your application with high availability is handled for you. Serverless computing eliminates infrastructure management tasks, such as server or cluster provisioning, patching, operating system maintenance, and capacity provisioning. The reduced overhead also means you can experiment and innovate faster.

You don’t pay for any infrastructure when the code isn’t running. Additionally, with serverless computing, your code runs only when it’s needed.

In a practical sense, with servers you must think about the following:

Configuring instances
Updating your OS
Installing the application platform
Configuring automatic scaling and load balancing
Building and deploying applications
Continuously patching, securing, and monitoring servers
Monitoring and maintaining applications

With serverless, you can focus on the following:

Building and deploying applications
Monitoring and maintaining applications

9 of 78

Building modern serverless applications

9

Serverless compute and event-driven patterns

Serverless,�purpose-built data stores

Managed services for integration

Deployment frameworks

Small pieces, �loosely joined

Purpose-built �data stores

Specialized services for integration

Automation by using �code

From a builder’s perspective, the abstraction of infrastructure into the cloud from virtual servers to containers and now to serverless has changed application development. It coincides with a move away from monolithic applications and a move toward service-oriented architectures and microservices.

The ideas of distributed applications and microservices aren’t new, but the evolution of cloud services makes it easier to build applications that follow these principles:

Use small, loosely joined pieces and purpose-built data stores. This strategy provides the flexibility to make changes without affecting other parts of the system, scale and deploy pieces independently, and incorporate reversible decisions.
Use specialized integration services to increase the speed of delivery and decrease the effort of integrations between services.
Write infrastructure as code to automate as much of the deployment process as you can. This approach makes it simpler to replicate environments, and deploy more frequently with minimal overhead and greater confidence.

Serverless (Serverless on AWS) is an efficient approach to modern applications:

With serverless compute services, you can focus on writing business logic while someone else handles scaling and high availability.
With purpose-built serverless databases, you can choose the features and capacity that suit the type and volume of data that each service needs.
Managed services provide API proxy, messaging, and orchestration and have prebuilt integrations with Lambda and other AWS services. With this process you can connect services by using asynchronous event-driven patterns to achieve decoupling and flexibility. At the same time, it reduces the undifferentiated lifting of building the integrations to connect your components.
Serverless deployment frameworks make it easier to use infrastructure as code for deployments and automate the deployment pipeline.

10 of 78

Moving away from a monolithic application

10

Monolith

Does everything�

Microservice

Does one thing

With a monolithic application, things start out easier. It’s simpler to build and test, and you have only one artifact to deploy. For some less complex applications, a monolithic approach might be the best option for a long time.

For complex applications that grow over time, the interdependencies among components and the necessary coordination among development teams for testing and deploying become more difficult. These concerns can decrease developer productivity.

You have one technology stack in which you must develop. You must hire and train developers in that technology and can’t take advantage of skills in other languages. Any change to the technology stack becomes a major project.
You have a single database. The most demanding use case drives your cost and capacity. Operations that aren’t suited to the database or data structures will continually be tuned to strive for better performance. However, they will reach a limit that is impossible to improve on without a redesign.

From an operational standpoint, many developers are pushing changes through a shared release pipeline, which causes friction at many points of the lifecycle.

If you want to upgrade a shared library to use a new feature, you must convince everyone else to upgrade at the same time.
If you want to quickly push an important fix for your feature, you still must merge it with everyone else’s in-process changes. This approach leads to merge Fridays or, worse yet, merge weeks when all developers compile their changes and resolve any conflicts for the next release.
After development, you also face overhead when you’re pushing the changes through the delivery pipeline. You must rebuild the entire application, run all of the test suites to ensure that you have no regression issues, and redeploy the entire application.

Every new feature adds to the complexity of the coordination, deployment, and ongoing operations effort. Technical debt stacks up, and it becomes nearly impossible to untangle code.

As an example, before migrating to a microservices approach, Amazon had a central team whose sole job was to deploy its monolithic application into production.

With a modern serverless application, the effort to get started is higher. Moving to microservice-based development requires a significant surge in effort as everyone learns and make mistakes. Often, everyone is new to the approaches that are required. Moving from experiments and utilities into full-scale production applications requires a surge of effort that includes both technology and organizational changes. The energy that it takes to get over that initial hurdle can hold organizations back without some initiating event or tipping point.

However, after the initial learning curve, the agility that this approach provides starts to accelerate the speed with which you can release new features. It also reduces the effort that it takes to keep them running.

Microservices provide these benefits:

Scale individual services independently.
Choose the best technology stack and data store for each service.
Deploy changes independently as often as desired.
Focus on a specific service and innovate within that service.

11 of 78

Section 3: Introducing Lambda

Module 7: Developing Event-Driven Serverless Solutions

12 of 78

AWS Lambda

Lambda is a serverless compute service that you can use to run code without provisioning or managing servers.

Invokes your code in response to events
Scales automatically
Provides built-in code monitoring and logging with Amazon CloudWatch

12

AWS Lambda

13 of 78

How Lambda works

Upload your code to Lambda or write code in the Lambda editor

Set up your code to run when events occur in other AWS services, at HTTP endpoints, or as part of in-app activity

Lambda runs your code only when it is activated by an event and uses only the compute resources that are needed

Pay only for the compute time that you use

13

!

14 of 78

Lambda features

14

Offers the ability to bring your own code

Integrates with and �extends other AWS services

Offers flexible resource and �concurrency models

Offers a flexible permissions model

Provides built-in availability �and fault tolerance

Reduces the need to pay for idle resources

AWS Lambda provides the following features:

Offers the ability to bring your own code – The code that you write for Lambda isn’t written in a new language that you have to learn. Development in Lambda is not tightly coupled to AWS, so you can easily port code in and out of AWS. With Lambda, you bring your code (written in your language of choice—such as Node.js, Java, Python, C#, Go, or Ruby), custom runtimes, and libraries.
Integrates with and extends other AWS services – From within your Lambda function, you can do anything that traditional applications can do. Examples include calling an AWS SDK or invoking a third-party API.
Offers flexible resource and concurrency models – Lambda scales in response to events. You configure memory settings, and AWS handles the details, such as CPU, network, and I/O throughput.
Offers a flexible permissions model – Lambda uses AWS Identity and Access Management (IAM) to securely grant access to your resources and give you fine-grained control for invoking your functions.
Provides built-in availability and fault tolerance – Because Lambda is a fully managed service, high availability and fault tolerance are integrated into the service, without any additional configuration on your part.
Reduces the need to pay for idle resources – Lambda functions run only when they are invoked, so you don't pay for idle capacity.

15 of 78

Example use cases for Lambda

15

Amazon S3

The front-end code for the weather app is hosted on Amazon S3

Website

A user chooses a link for local weather information

API Gateway

The app makes a REST API call to the endpoint

Lambda

Lambda runs code to get the weather data from DynamoDB and returns the data

DynamoDB

DynamoDB contains the weather data that the app uses

Web app

Kinesis

A social media stream is loaded into Kinesis in real time

Lambda

Lambda runs code that generates hashtag trend data

DynamoDB

Hashtag trend data is stored in DynamoDB

Real-time stream processing

!

An endpoint call invokes Lambda

Social media trend data is immediately available for business users to query

!

Stream events invoke Lambda

You can use Lambda in various ways. Web applications and real-time stream processing are two common use cases. Additional common use cases include the following:

Backends – You can build serverless backends by using Lambda to handle web, mobile, Internet of Things (IoT), and third-party API requests. You can build backends by using Lambda and Amazon API Gateway to authenticate and process API requests. Lambda makes it easy to create rich, personalized application experiences.
Data processing – You can use Lambda to run code in response to triggers, such as changes in data, shifts in system state, or actions by users. AWS services, such as Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB, can directly invoke Lambda. Other services that can invoke Lambda include Amazon Kinesis, Amazon Simple Notification Service (Amazon SNS), and CloudWatch. AWS Step Functions can also orchestrate Lambda in workflows. You can use Lambda with these services to build various real-time processing systems for serverless data.
Chatbots – Amazon Lex is a service for building conversational interfaces into any application by using voice and text. Amazon Lex uses the same deep learning technologies that power Amazon Alexa, and it integrates with Lambda.
Amazon Alexa – You can use Lambda to build the backend for custom Alexa skills.
IT automation – You can use Lambda to automate repetitive processes by invoking them with events or by running them on a fixed schedule. You can automatically update the firmware of hardware devices, start and stop Amazon Elastic Compute Cloud (Amazon EC2) instances, or schedule security group updates. In addition, you can automate your test and deployment pipeline.

For more case studies, see the AWS Lambda product page.

Anything that you want to do with servers you can probably do with Lambda. Use Lambda and serverless to reimagine your approach to new or updated applications.

To get started, follow these suggestions:

Look for opportunities to introduce serverless through common use cases.
Choose something authentic, iterate on it, learn from it, and expect to keep working on it in production.
Expect to change your mind about what you thought was the best solution when you started. Keep learning and updating your approach.

16 of 78

Lambda functions

16

Access �permissions

Initiating

events

Lambda

Lambda function

Configuration

Application �code

Dependencies�and libraries

Runtime and deployment package

As a developer, you create Lambda functions that the Lambda service manages. When you create a function, you define the permissions for the function and specify which events will invoke the function. You choose a runtime and create a deployment package that includes your application code and any dependencies and libraries necessary to run your code. Finally, you configure parameters such as memory, timeout, and concurrency. When your function is invoked, Lambda provides a runtime environment based on the runtime and configuration options that you selected.

Lambda initializes concurrent environments to maintain the pace of invocation requests up to certain quotas. Each environment is temporary, and the Lambda service controls it, which affects some of the best practices that you should apply to your function code. You will discuss these ideas later in this section.

Lambda supports multiple languages through the use of runtimes, including Node.js, Python, Ruby, Java, Go, and .NET. You can also implement a custom runtime if you want to use another language in Lambda.

For more information about the Lambda runtime environment, see Lambda Runtimes.

17 of 78

Lambda functions run in on-demand ephemeral environments

17

Concurrency:

1

2

3

4

Invocation requests

Concurrency: The number of function invocations that are running at one time

AWS Lambda

Each invocation of a Lambda function runs in an ephemeral environment—one that is initialized on demand, lasts a brief time, and then is removed. Lambda manages creating and tearing down these environments for your functions. You don’t have direct control over these environments.

Concurrency is the number of Lambda function invocations that are running at one time. Lambda provides the environments on demand as it receives requests, which is how Lambda quickly scales horizontally.

Factors that influence concurrency include the following:

Reserved concurrency on a function – This optional value is set per function and reserves a subset of the Regional quota for the function. It also establishes the maximum concurrent instances that are permitted for the function. For more information about managing reserved concurrency, see Managing Concurrency for a Lambda Function.
Regional quota – This quota is the total number of invocations that can run concurrently across all Lambda functions within an account by Region. AWS sets this number as a soft quota on the account. For more information about quotas, see Lambda Quotas.
Burst quota – Each Region has a burst limit, which prevents concurrency from increasing too quickly if a large spike of requests occurs in a short time period. You cannot modify this limit. For more information about bursts, see AWS Lambda Function Scaling.
Request rate and function duration – This value is the rate at which new invocation requests for the function arrive, in conjunction with how long Lambda takes to run the function.
The event source – Lambda manages concurrency of requests in different ways based on the type of event that invokes it.

18 of 78

Section 3 key takeaways

Lambda is a serverless compute service that integrates with other AWS services.
You can use Lambda for many use cases including web applications, backends, and data processing.
Lambda functions run in on-demand temporary environments.

18

19 of 78

Section 4: Invoking Lambda functions

Module 7: Developing Event-Driven Serverless Solutions

20 of 78

Push and pull models

20

Lambda

Lambda function�(custom code)

Pull (polling) event

Push �event

Lambda polls �for events and invokes �the Lambda function with batches of records

An AWS service �directly invokes the�Lambda function

21 of 78

Push event types

21

Synchronous

/order

API Gateway

Lambda�function

No retry built in

Invoke via API:�RequestResponse

Asynchronous

3 tries

Amazon S3

Lambda�function

0–2 retries

Invoke via API:�Event

The other service �waits for a �response from �your function.

Lambda �queues the event �before passing it �to your function.

Some services invoke your function directly.

For synchronous invocation, the other service waits for the response from your function. Consider an example where API Gateway is the event source. In this case, when a client makes a request to your API, that client expects a response immediately. This model has no built-in retry in Lambda. You must manage your retry strategy in your application code.

Examples of synchronous event sources include the following:

Elastic Load Balancing
Amazon Cognito
Amazon Lex
Amazon Alexa
Amazon API Gateway
AWS CloudFormation
Amazon CloudFront
Amazon Kinesis Data Firehose

For asynchronous invocation, Lambda queues the event before passing it to your function. The other service gets a success response as soon as the event is queued and isn't aware of what happens afterwards. The event sources "sends it then forgets it". If an error occurs, Lambda will automatically retry the invocation twice. It can send failed events to a dead-letter queue that you configure.

Examples of asynchronous event sources include the following:

Amazon S3
Amazon SNS
Amazon Simple Email Service (Amazon SES)
AWS CloudFormation
Amazon CloudWatch Logs
Amazon CloudWatch Events
AWS CodeCommit
AWS Config

In both cases, you invoke your Lambda function by using the invoke operation, and you can specify the invocation type as synchronous or asynchronous. When you use an AWS services as a trigger, the invocation type is predetermined for each service. You have no control over the invocation type that these event sources use when they invoke your Lambda function.

For more information how to invoke Lambda functions, see Invoking AWS Lambda Functions in the AWS Lambda Developer Guide.

22 of 78

Pull (polling) event types

22

shard

Lambda polls a stream

Lambda polls a queue

Amazon �DynamoDB Streams

Amazon Kinesis

Data Streams

Records from the stream

Lambda �function

Lambda

Records from the queue

Lambda�function

Lambda

Amazon Simple Queue Service (Amazon SQS)

Errors in a shard �block further�processing

Errors in a batch�are returned to�the queue

In the polling model, Lambda uses event source mappings to get information from a stream or queue. Lambda polls the stream or queue. If it finds records, it delivers the payload and invokes the Lambda function. In this model, the Lambda service itself is extracting data from the stream or queue for processing by the Lambda function.

Stream-based event sources include Amazon DynamoDB Streams and Amazon Kinesis Data Streams. Stream records are organized into shards. Lambda polls the stream for records and attempts to invoke the function. If a failure occurs, Lambda will not read any new shards until the failed batch of records expires or is processed successfully. You can configure error handling options to modify how Lambda deals with errors.
Queue-based event sources include Amazon Simple Queue Service (Amazon SQS). Lambda polls the queue for records. If the invocation fails or times out, then the failed message is returned to the queue. Lambda continues to retry the failed message until it’s processed successfully or the retry limit or message retention period is reached. Failed messages can be sent to an OnFailure destination or a dead-letter queue.

You can create a mapping between an event source and your Lambda function. Lambda reads items from the event source and invokes the function. For more information about the CreateEventSourceMapping operation, see CreateEventSourceMapping in the AWS Lambda Developer Guide.

Polling does not incur any charge. You are charged only if actions result from a poll.

With streams, Lambda retries until it succeeds or the record reaches a 24-hour expiration. Thus, an erroring record can block processing. You can configure error handling options to bypass failing records and send them to an OnFailure destination for offline processing. For more information about how Lambda works with streams, see Using AWS Lambda with Amazon Kinesis in the AWS Lambda Developer Guide.

With queues, failed records become visible on the queue to be resent to your Lambda function up to a number of retries, which you can configure. You can send records that continue to fail to a dead-letter queue. For more information about how Lambda works with queues, reference Using AWS Lambda with Amazon SQS in the AWS Lambda Developer Guide.

23 of 78

Invoking a function synchronously

aws lambda invoke \�--function-name my-function \�--payload '{ "name": "Bob" }' \�response.json

23

{"ExecutedVersion": "$LATEST","StatusCode": 200}

Response

Invoke

24 of 78

Invoking a function asynchronously

aws lambda invoke \�--function-name my-function \�--invocation-type Event \�--payload '{ "name": "Bob" }' \�response.json

24

{"StatusCode": 202}

Ack

Invoke

25 of 78

Section 4 key takeaways

Lambda invokes Lambda functions by using one of these invocation models:

Synchronous
Asynchronous
Polling (event source mapping)

Lambda has built-in handling that differs by event source type.

25

26 of 78

Section 5: Setting permissions for Lambda

Module 7: Developing Event-Driven Serverless Solutions

27 of 78

Lambda permissions

27

Initiating�event

Event sources need �permissions to invoke�a Lambda function

Lambda functions need �permissions to interact �with other services

Lambda function

Event source

AWS service or resource

Allowed�action

28 of 78

Invocation permissions

28

Initiating event

Lambda function

An IAM resource policy gives permissions to invoke the function.

Resource policy:

Associated with synchronous or asynchronous event source
Allows the event source to take the lambda:InvokeFunction action

Amazon S3 bucket

29 of 78

Example resource (function) policy

29

{

"Version": "2012-10-17",

"Id": "default",

"Statement": [

{

"Sid": "lambda-fd269e28-988b-4d2b-96ae-eabcd7dc399c",

"Effect": "Allow",

"Principal": {

"Service": "s3.amazonaws.com"

},

"Action": "lambda:InvokeFunction",

"Resource": "arn:aws:lambda:function:myFirstFunction",

"Condition": {

"ArnLike": {

"AWS:SourceARN": "arn:aws:s3:::myBucket1"

}

]

}

30 of 78

Lambda execution role

30

The Lambda execution role specifies what the Lambda function is permitted to do.

Lambda function

Allowed action

IAM policy
Trust policy

Execution role

Amazon �S3

DynamoDB

Amazon SQS

Upload a file

Read from a table

Poll a queue

CloudWatch

Write CloudWatch logs

The Lambda execution role grants your Lambda function permissions to access AWS services and resources. You select or create the execution role when you create a Lambda function.

Two policies are attached to the execution role:

IAM policy – Defines the actions that the Lambda function can take on another AWS service or resource, such as writing to a DynamoDB table
Trust policy – Allows the Lambda service to assume the execution role

To grant permissions to Lambda to use the AssumeRole action, you must have permissions for the iam:PassRole action.

Polling event sources also need the execution role to give the Lambda function permissions to read from the queue or stream.

The Lambda function also needs the execution role to poll event sources to be able to read from the queue or stream.�

For more information, see AWS Lambda execution role.

31 of 78

Execution role example

31

{

"Effect": "Allow",

"Action": [

"logs:CreateLogGroup",

"logs:CreateLogStream",

"logs:PutLogEvents"

],

"Resource": "arn:aws:logs:*:*:*"

}

{

"Effect": "Allow",

"Principal": {

"Service": "lambda.amazonaws.com"

},

"Action": "sts:AssumeRole"

}

IAM policy

Trust policy

32 of 78

Adding permissions by using the AWS CLI

aws lambda add-permission \�--function-name my-function \�--action lambda:InvokeFunction \�--statement-id sns \�--principal sns.amazonaws.com

32

{�"Statement":�{�"Sid":"sns",�"Effect":"Allow",�"Principal":{�"Service":"sns.amazonaws.com"�},�"Action":"lambda:InvokeFunction",�"Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"�}�}

Output

Give Amazon SNS permissions to invoke a function

33 of 78

Section 5 key takeaways

Lambda functions require permissions to be invoked and permissions to interact with other services.
Both types of permissions are defined by using IAM or trust policies.

33

34 of 78

Section 6: Authoring and configuring Lambda functions

Module 7: Developing Event-Driven Serverless Solutions

35 of 78

The function handler

35

Event object�

Passes event information to the handler
Uses a predefined object format for AWS integrations and events
Can be tested with user-defined custom objects

Handler (event, context) method

Context object�

Passes runtime information to the handler
Includes, at a minimum, these methods or properties:

awsRequestId
getRemainingTimeInMillis()
logStreamName

When you create a Lambda function, you specify the function handler. The Lambda function handler is the entry point that Lambda calls to start running your Lambda function. The handler method always takes two objects: the event object and the context object.

Event object – Provides information about the event that invoked the Lambda function. This information could be a predefined object that an AWS service generates, or it could be a custom user-defined object. A user-defined object could be a serializable string, such as a plain old Java object (POJO) or a JSON stream. The contents of the event object include all the data and metadata that your Lambda function needs to drive its logic. The contents and structure of the event object vary, depending on which event source created it. For example, an event that API Gateway created contains details that are related to the HTTPS request that the API client made. The details might include path, query string, and request body. However, an event that Amazon S3 created would include details about the bucket and the new object.

Context object – AWS generates a context object and provides runtime information. The context object enables your function code to interact with the Lambda runtime environment. The contents and structure of the context object vary based on the language runtime that your Lambda function uses. However, at a minimum, the context object will contain:

awsRequestId – This property is used to track specific invocations of a Lambda function (important for error reporting or when contacting AWS Support).
logStreamName – This is the CloudWatch log stream that your log statements will be sent to.
getRemainingTimeInMillis() – This method returns the number of milliseconds that remain before running your function times out.

36 of 78

Lambda function handler example

{

"first_name": "John",

"last_name": "Smith"

}

36

{

"message": "Hello John Smith!"

}

Handler

event object

def lambda_handler(event, context):

message = 'Hello {} {}!'.format(event['first_name'],

event['last_name'])

return {

'message' : message

}

response

37 of 78

Example testing from the console

37

Create test event

Review results

38 of 78

Performance-related configurations

38

Configuration	Description
Memory	Set the amount of memory and proportional CPU that is allocated to the function. Lambda allocates CPU power linearly in proportion to the memory that you set. Values from 128 MB–10,240 MB.
Timeout	Choose the maximum amount of time to let a function run before ending it if it has not completed. Values from 1 second up to 15 minutes.
Concurrency	Number of invocations of a function that can run at the same time. By default, you can have 1,000 concurrency invocations per Region for an account. This limit is a soft limit. Per function, you can set a limit to prevent overwhelming a downstream system or to reserve capacity from within the account pool for the function.
Provisioned concurrency	Number of Lambda environments to keep warm. When Lambda creates the temporary environment for your function, it will attempt to reuse it for additional invocations. This approach saves startup time. When Lambda must initialize new environments to run a function, an invocation might get a cold start, which creates startup latency. Use provisioned concurrency to avoid cold starts. Provisioned concurrency is priced separately.
Monitoring and operations	Settings to enable X-Ray (active tracing) and CloudWatch Lambda Insights (collect and aggregate Lambda function runtime performance metrics and logs).

Memory and timeout are configurations that determine how your Lambda function performs. These configurations affect your billing. With Lambda, you are charged based on the number of requests for your functions (the total number of requests across all your functions). You are also charged based on the duration (the time it takes for your code to run). The price depends on the amount of memory that you allocate to your function.

Memory – You specify the amount of memory that you want to allocate to your Lambda function. Lambda then allocates CPU power that is proportional to the memory. Lambda is priced so that the cost per 1 millisecond of function duration increases as the memory configuration increases.
Timeout – You can control the maximum duration of your function by using the timeout configuration. Using a timeout can prevent higher costs that come from long-running functions. You must find the right balance between not letting the function run too long and being able to finish under normal circumstances.

Follow these best practices:

Test the performance of your Lambda function to make sure that you choose the optimum memory size configuration. You can view the memory usage for your function in CloudWatch Logs.
Load-test your Lambda function to analyze how long your function runs and determine the best timeout value. This information is important when your Lambda function makes network calls to resources that might not be able to handle the scaling of Lambda functions.

For more information, see the following resources:

39 of 78

Resource-related configurations

39

Configuration	Description
Triggers	Event sources that invoke a function.
Permissions	The resources that have permissions to invoke the function and the permissions that the function has to interact with other resources.
Destinations	An SNS topic, SQS queue, other Lambda function, or EventBridge event bus. It receives invocation records from a function when it is successful (on success) or when it fails (on failure).
Asynchronous invocation	Settings for number of retry attempts on async invocations (0–2) and how long to keep an event waiting to be invoked (up to 6 hours). Also, configuration of a dead-letter queue for functions that continue to fail.
VPC	Settings to enable your Lambda function to access resources in a custom VPC. A custom VPC defines a private network of resources, such as databases, cache instances, or internal services.
State machines	Step Functions state machines that can invoke your function directly in at least one of the steps.
Database proxies	Settings that are used when connecting to an Amazon Relational Database Service (Amazon RDS) instance. These settings are used to set up a database proxy to manage connection pooling for database connections.
File systems	Settings to connect an Amazon Elastic File System (Amazon EFS) file system so that the function can access the file system at runtime.

In addition to the resource-related configurations that you discussed so far (event sources, IAM permissions), Lambda offers more. Options are available for configuring how Lambda interacts with other AWS resources to adapt to different use cases. For example, you might need to connect to a virtual private cloud (VPC), an Amazon Relational Database Service (Amazon RDS) instance, or an Amazon Elastic File System (Amazon EFS) file system. You can also configure details that are related to event sources, such as destinations, and asynchronous invocation details. Both of these types are relevant to asynchronous event sources. Destinations can also be used for streaming event sources.

You can also configure Step Functions state machines that can directly invoke your function in one of their steps.

40 of 78

Code-related configurations

40

Configuration	Description
Runtime	Runtime that the function will use or language that the code will be written in. Choose from supported runtimes that are listed in the AWS Lambda Developer Guide or use a custom runtime.
Environment variables	Key-value pairs that are accessible from your function code. Environment variables are useful to store configuration settings without the need to change function code.
Tags	Labels that you assign to an AWS resource. Each tag consists of a key and an optional value. You can use tags to search and filter your resources or track your AWS costs.
Code signing	Option to ensure that code has been signed by an approved source and has not been altered.

41 of 78

Design a Lambda function: Best practices for a Lambda environment

Treat functions as stateless.
Include only what you need.
Reuse the temporary runtime environment.

41

Some best practices to follow when you design your Lambda function are listed:�

Treat functions as stateless. No information about state should be saved within the context of the function itself. Because your functions exist only when work must be done, it’s important for serverless applications to treat each function as stateless.
Include only what you need.

Minimize both the size and the dependencies of your deployment package to reduce the startup time for your function. For example, choose only the modules that you need, such as the DynamoDB and Amazon S3 SDK modules, and Lambda core libraries. Don’t include an entire AWS SDK library in your deployment package.
Reduce the time that it takes Lambda to unpack deployment packages that are authored in Java.
Minimize the complexity of your dependencies. Choose simpler Java dependency injection (IoC) frameworks. For example, choose Dagger or Guice instead of more complex frameworks like Spring.

Reuse the temporary runtime environment to improve the performance of your function. The temporary runtime environment initializes any external dependencies of your Lambda function code. Make sure that any externalized configuration or dependencies that your code retrieves are stored and referenced locally after the initial run. Limit reinitializing variables and objects on every invocation. Keep alive and reuse connections—such as HTTP, database, or others—that were established during a previous invocation.

42 of 78

Design a Lambda function: Best practices for writing code

Separate the core business logic (outside of the handler method).
Write modular functions.
Include logging statements.
Include results information.
Use environment variables.
Avoid recursive code.
Don't call one function from another.

42

Some best practices to follow when you are writing code are listed:

Separate the core business logic from the handler method. This practice makes your code more portable, and you can target unit tests at your code without concern about the configuration of the function.
Write modular functions. Create single-purpose functions.
Include logging statements. Lambda functions can and should include logging statements that are written to CloudWatch.
Include results information. Functions must give information to Lambda about the results of their run.
Use environment variables. With environment variables, you can pass operational parameters and configuration settings to your function without making changes to the code itself. For example, if you are writing to an S3 bucket, configure the bucket name as an environment variable instead of hardcoding the bucket name. You can also use environment variables to store sensitive information that the function requires.
Avoid using recursive code. Avoid a situation where a function calls itself. In this circumstance, it might continue to spawn new invocations that would cause you to lose control of your concurrency.
Don't call one function from another. Instead use destinations or orchestrate with Step Functions.

43 of 78

Tuning your function

Higher memory configurations have a higher per-1-millisecond cost but might decrease duration costs and concurrency needs.
Find the balance that optimizes for speed and cost.

43

Example results for two CPU-intensive functions, which become cheaper and faster with more power

Source: https://github.com/alexcasalboni/aws-lambda-power-tuning

44 of 78

Section 6 key takeaways

Lambda supports different languages and runtimes.
The function handler is the entry point into the Lambda function.
You can configure attributes including the amount of memory and function timeout.
Follow best coding practices to create efficient Lambda functions.

44

45 of 78

Section 7: Deploying Lambda functions

Module 7: Developing Event-Driven Serverless Solutions

46 of 78

Deployment options

.zip archive

Choose a runtime when you create the function.
Compress files for application code and dependencies, and upload them to Lambda.

Container image

Choose a runtime and linux distribution when creating the image.
Package your code and dependencies as a container image.
Upload the image to your container registry that is hosted on Amazon Elastic Container Registry (Amazon ECR).

46

To deploy a Lambda function with the Lambda API, command-line tools, or the AWS SDKs, you must create a Lambda function deployment package. You also must create a deployment package if your function uses a compiled language or to add dependencies to your function.

You can create two types of deployment packages, .zip archives or container images.

If you use a .zip archive, you choose a runtime when you use the Lambda console or a toolkit to create a function. When you author your function, Lambda will automatically create the .zip file of your code.

You can also use a container image for your deployment package. Thus, it is possible to use familiar container tooling, workflows, and dependencies to build applications that are based on Lambda.

For more information, see the following resources:

47 of 78

Uploading .zip deployment packages

47

Developer

Integrated development environment (IDE)

Write and edit in the�Lambda console editor

Lambda

Test and �debug

Lambda �console

Local test �and debug

AWS Cloud

1

Upload the deployment package directly from your IDE

2

3

Compress (.zip) and upload to the S3 bucket

S3 bucket

You can use the console or use your integrated development environment (IDE) to author Lambda functions. For .zip file deployment packages, you have three options for providing the deployment package to the Lambda service:

Lambda console editor – If your code does not require custom libraries (other than the AWS SDK), then you can edit your code inline through the AWS Management Console. The console compresses your code (with the relevant configuration information) into a deployment package that the Lambda service can run. This deployment choice is ideal for simple scenarios.
Upload the deployment package directly from your IDE – In most scenarios where your code requires custom libraries, you can create your deployment package in your IDE. Then, you can upload it through the Lambda console.
Compress and upload to an S3 bucket – You can also upload your deployment package to an S3 bucket and provide the S3 bucket, object key, and optional version for the object. Lambda will load your code directly from Amazon S3.

The deployment packages have the following limits:

50 MB (compressed, for direct upload)
250 MB (not compressed, including layers)
3 MB (using the console editor)
512 KB maximum for an individual file

48 of 78

Deploying as a container image

48

docker push

Amazon ECR

Container image

Upload the image to the registry

Invoke

Status: ACTIVE

Ready to invoke

Lambda

function

Container image

Pull the image from Amazon ECR
Optimize the image
Deploy the image to Lambda

CreateFunction

Container image

Status: PENDING

Lambda

49 of 78

Versioning

Immutable copies of Lambda function code �and configuration
Create: $LATEST version

Publish: Snapshot copy of $LATEST
Each version has its own Amazon Resource Name (ARN) with a new sequential version number

49

Lambda function�(version $LATEST)

arn:aws:lambda:aws-region:acct-id:function:helloworld:$LATEST

arn:aws:lambda:aws-region:acct-id:function:helloworld:1

Snapshot of �Lambda function�(version 1)

1

Publish

50 of 78

Aliases

Mutable pointers to versions
Each alias has its own ARN

50

Lambda function�(version $LATEST)

Lambda function�(version 2)

2

Lambda function�(version 1)

1

Lambda function test alias:

arn:aws:lambda:aws-region:acct-id:function:helloworld:test

Dev

Test

Prod

51 of 78

Example of using versioning and aliases

51

arn:aws:lambda:aws-region:acct-id:function:helloworld:$LATEST

Amazon S3

Event source mapping that uses the Lambda function ARN �(update with each version)

Lambda function�(version $LATEST)

Snapshot of �Lambda function�(version 1)

1

Publish

arn:aws:lambda:aws-region:acct-id:function:helloworld:1

Without aliases:

arn:aws:lambda:aws-region:acct-id:function:helloworld:PROD

Amazon S3

With aliases:

Event source mapping that uses the alias ARN �(don’t need to update with each version)

For example, suppose that Amazon S3 is the event source that invokes your Lambda function when new objects are created in a bucket. When Amazon S3 is your event source, you store the information for event source mapping in the configuration for bucket notifications. In that configuration, you can identify the Lambda function ARN that Amazon S3 can invoke. However, in this case, you must update the notification configuration. It is necessary so that Amazon S3 will invoke the correct version each time you publish a new version of your Lambda function.

Instead of specifying the function ARN, you can specify an alias ARN in the notification configuration (for example, you can specify the PROD alias ARN). As you promote new versions of your Lambda function into production, you only must update the PROD alias to point to the latest stable version. You don't need to update the notification configuration in Amazon S3.

52 of 78

Custom runtimes

With custom runtimes you can use other languages in Lambda.
Lambda provides a runtime interface for getting events and sending responses.
The bootstrap file is the runtime's entry point.
You can deploy a custom runtime next to your function code or in a layer.

52

53 of 78

Lambda layers

Reduce the size of deployment packages
Speed up deployments
Limits:

Up to five layers
250 MB

53

Centrally manage code and data that are shared across multiple functions

Even if you are using a standard runtime, when you build serverless applications, it is common to have code that is shared across Lambda functions. It can be custom code that more than one function uses, or a standard library that you add to simplify the implementation of your business logic.

Previously, you needed to package and deploy this shared code together with all the functions that used it. Now, you can configure your Lambda function to include additional code and content as 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.

It is a best practice to have smaller deployment packages and to share common dependencies with layers. You can use layers to keep your deployment package small, which makes development easier. You can avoid errors that can occur when you install and package dependencies with your function code. For Node.js, Python, and Ruby functions, if you keep your deployment package under 3 MB, you can develop your function code in the Lambda console.

A function can use up to five layers at a time. The total extracted size of the function and all layers cannot exceed the extracted deployment package size limit of 250 MB.

AWS published a public layer that includes NumPy and SciPy, which are scientific libraries for Python. This layer can help you with data processing and machine learning applications. For information about how to use this layer, see New for AWS Lambda – Use Any Programming Language and Share Common Components on the AWS News Blog.

For more information about Lambda layers, see Lambda layers.

54 of 78

Example deploying from the AWS CLI

aws lambda create-function \�--function-name my-function \�--runtime nodejs10.x \�--zip-file fileb://my-function.zip \�--handler my-function.handler \�--role arn:aws:iam::123456789012:role/service-role/MyTestFunction-role-tges6bf4

54

{�"TracingConfig": {�"Mode": "PassThrough"�},�"CodeSha256": "PFn4S+er27qk+UuZSTKEQfNKG/XNn7QJs90mJgq6oH8=",�"FunctionName": "my-function",�"CodeSize": 308,�"RevisionId": "873282ed-4cd3-4dc8-a069-d0c647e470c6",�"MemorySize": 128,�"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",�"Version": "$LATEST",�"Role": "arn:aws:iam::123456789012:role/service-role/MyTestFunction-role-zgur6bf4",�"Timeout": 3,�"LastModified": "2019-08-14T22:26:11.234+0000",�"Handler": "my-function.handler",�"Runtime": "nodejs10.x",�}

Output

Create function

55 of 78

Example of updating a function from the AWS CLI

aws lambda update-function-code \�--function-name my-function \�--zip-file fileb://my-function.zip

55

{�"FunctionName": "my-function",�"LastModified": "2019-09-26T20:28:40.438+0000",�"RevisionId": "e52502d4-9320-4688-9cd6-152a6ab7490d",�"MemorySize": 256,�"Version": "$LATEST",�"Role": "arn:aws:iam::123456789012:role/service-role/my-function-role-uy3l9qyq",�"Timeout": 3,�"Runtime": "nodejs10.x",�"TracingConfig": {�"Mode": "PassThrough"�},�"CodeSha256": "5tT2qgzYUHaqwR716pZ2dpkn/0J1FrzJmlKidWoaCgk=",�"CodeSize": 304,�"FunctionArn": "arn:aws:lambda:us-west-2:123456789012:function:my-function",�"Handler": "index.handler"�}

Output

Update function

56 of 78

Section 7 key takeaways

Lambda has built-in versioning so that you can create immutable versions of your code.
You can use aliases to point at different versions of your Lambda function.
Lambda provides popular runtimes, but you can create custom runtimes.
Lambda layers are libraries of code that you create and which other Lambda functions can call.

56

57 of 78

Section 8: Monitoring and debugging tools for application developers

Module 7: Developing Event-Driven Serverless Solutions

58 of 78

Modern applications challenge traditional monitoring approaches

58

Faster release velocity

User experience

More devices, services, and data

Short-lived resources

59 of 78

Amazon CloudWatch

CloudWatch collects monitoring and operational data in the form of logs, metrics, and events.

Get a unified view of AWS resources, applications, and services
Review logs as a flow of events ordered by time
Query log data interactively with CloudWatch Logs Insights
Use default operational metrics from AWS services
Alarm based on metric thresholds and initiate automated actions

59

Amazon CloudWatch

60 of 78

Example of Lambda logging

60

Time	Message
19:35:32	START RequestId: 41c8dcf0-ff10-4d96-af2a-1ab5e346c937 Version: $LATEST
19:35:32	2020-08-27T19:35:32.553Z 41c8dcf0-ff10-4d96-af2a-1ab5e346c937 INFO …
19:35:32	2020-08-27T19:35:32.575Z 41c8dcf0-ff10-4d96-af2a-1ab5e346c937 INFO …
19:35:32	END RequestId: 41c8dcf0-ff10-4d96-af2a-1ab5e346c937
19:35:32	REPORT RequestId: 41c8dcf0-ff10-4d96-af2a-1ab5e346c937 Duration: 64.40 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 68 MB Init Duration: 162.85 ms
19:35:36	START RequestId: a23cbea6-3053-4b51-8721-ff11aba24e33 Version: $LATEST
…

CloudWatch > Log Groups > /aws/lambda/FAQ > 2020/08/27/[$LATEST]05419d29f9014fc3b1634b1e9968ef28

Log group

Log stream

Log events

Lambda logs all requests and results in a CloudWatch log group that is called /aws/lambda/<function name>. A one-to-one relationship exists between function and log group. The first time that the function runs, the group is created. If you set up provisioned concurrency, the log group is created when you create the provisioned concurrency. The log group is the entity that you would typically use for searching events within your Lambda logs.

The log group is made up of log streams that are identified by the date, function version, and a unique identifier. Lambda automatically creates new log streams within a group. They are based on internal factors that are related to how invocations are allocated to environments and the timing of invocations.

When you test functions from the Lambda console, log information is presented on the console to assist with debugging. The console highlights the success or failure of the invocation, and provides summary information from the log entries.

Each log stream contains a sequence of events that describe Lambda request details. Each request includes a unique RequestID, and a START event, END event, and REPORT event, which quickly tell you summary information about the Lambda request. The RequestID is the primary identifier that you will use to find events related to a particular invocation. The REPORT event is a quick way to see how long the function ran. It also shows the billing duration, the memory that is configured for the function, and the memory that it used. The “Init” duration in this example tells you that this invocation was a cold start.

For more information about CloudWatch Logs, see What Is Amazon CloudWatch Logs?

For more information about accessing CloudWatch Logs for Lambda, see Accessing Amazon CloudWatch logs for AWS Lambda.

61 of 78

AWS X-Ray

X-Ray traces requests that travel through your application and shows a map of your application’s underlying component.

One-click enablement for Lambda functions and integration with other AWS services
X-Ray SDK to capture metadata for API calls that are made to AWS services with the AWS SDK
Visual detection of latency distribution and quick isolation of outliers and trends
Easier debugging of application code
Filtering and grouping of requests by error type

61

AWS X-Ray

62 of 78

Parts of an X-Ray trace

62

Element	Description
Segments	Data about the work done by compute resources that run your application, including: Resource name Details about the request and the work that is done Subsegments
Subsegments	Breakdown of segment data into greater detail, including: More granular timing Details about downstream calls Inferred segments for downstream services Annotations and metadata
Annotations	Key-value pairs that can be indexed and used with filter expressions to group traces in the console for easier analysis
Metadata	Key-value pairs of any type that are not indexed but can be used to store data in the trace that you won’t use for searching traces

A segment provides the resource's name, details about the request, and details about the work that is done.

A segment can break down the data about the work that is done into subsegments. Subsegments provide more granular timing information and details about downstream calls that your application made to fulfill the original request. A subsegment can contain additional details about a call to an AWS service, external HTTP API, or SQL database. You can even define arbitrary subsegments to instrument specific functions or lines of code in your application.

Annotations include key-value pairs that can be indexed and used with filter expressions to group traces in the console for easier analysis.

Metadata includes key-value pairs of any type that are not indexed but can be used to store data in the trace that you won’t use for searching traces

For information about segments, see AWS X-Ray concepts.

For information about X-Ray segment documents, see AWS X-Ray segment documents.

For information about annotations and metadata, see AWS X-Ray concepts.

This additional data makes it easier to use filter expressions and look at your traces in logical groups. For more information about using filter expressions to search for traces in the console, see Using filter expressions to search for traces in the console.

63 of 78

Example X-Ray trace

63

Segments�

Subsegments�

Annotations�

64 of 78

Demonstration: Using X-Ray with Lambda

64

65 of 78

Section 8 key takeaways

Modern applications require more than traditional operations monitoring.
CloudWatch provides built-in logging and metrics to monitor your Lambda functions.
With X-Ray, you can trace requests across your application to find trouble spots quickly.

65

66 of 78

Lab 7.1: Creating Lambda Functions Using the AWS SDK for Python��

66

67 of 78

Lab: Scenario

In this lab, you again play the role of Sofía. You replace the mock endpoints that you created in the previous lab with real endpoints so that the web application can connect to the database. You will use Lambda to make this connection between the REST API and the data that is stored in DynamoDB.

67

68 of 78

Lab: Tasks

Preparing the development environment
Creating the get_all_products Lambda function
Configuring the REST API GET method to invoke the Lambda function
Creating the create_report Lambda function
Configuring the REST API POST method to invoke the Lambda function
Testing the integration by using the café website

68

69 of 78

Lab: Final product

69

API Gateway

products

endpoint

DynamoDB

FoodProducts

Table (stores menu information)

Lambda

An S3 bucket

hosts the café website HTML and JavaScript pages

A café website user chooses a link on the website

1

2

3

The endpoint invokes the Lambda function

4

Lambda queries the database table

A café website user loads the café home page

create_report

endpoint

get_all_products

function

Data is returned

5

create_report

function

70 of 78

Begin Lab 7.1: �Creating Lambda Functions Using the AWS SDK for Python

70

~ 90 minutes

71 of 78

Lab debrief: �Key takeaways

71

72 of 78

Module wrap-up

Module 7: Developing Event-Driven Serverless Solutions

73 of 78

Module summary

In summary, in this module, you learned how to:

Explain serverless computing
Describe how Lambda works
Recognize Lambda invocation models
Identify how to use IAM to grant Lambda permissions
Indicate the steps to author and configure a Lambda function
Explain how to deploy Lambda functions
Identify why X-Ray is a critical developer tool
Create Lambda functions

73

This module addressed the following topics:

Explain serverless computing
Describe how Lambda works
Recognize Lambda invocation models
Identify how to use IAM to grant Lambda permissions
Indicate the steps to author and configure a Lambda function
Explain how to deploy Lambda functions
Identify why X-Ray is a critical developer tool
Create Lambda functions

To finish this module, complete the corresponding knowledge check.

It is simple to get started with Lambda, and the possibilities are broad for its use. However, it takes some practice to get used to thinking serverless. Keep the following key things in mind:

15-minute maximum duration: If your function cannot routinely run in less than 15 minutes, you won't be able to put it into a function. Follow best practices for limiting the time that is required to run your function.

Best Practices for Working with AWS Lambda Functions

Concurrency: Lambda scales to meet demand up to the account or function limits. Use the function concurrency setting to manage the maximum concurrency to avoid overwhelming downstream systems.

Cold start latency: Test your functions in production-like conditions to determine whether the impact of cold starts affect your function's ability to respond as quickly as needed. Tune your function to shorten the startup time, and consider using provisioned concurrency to prevent cold starts.

Lambda and VPCs: When you are working with VPC resources, you have additional considerations for your function. If you must access VPC resources, use the available resources to plan your configuration.

74 of 78

Complete the knowledge check

74

75 of 78

Sample exam question

A developer is testing an application locally and has deployed it to Lambda. To remain under the package size limit, they did not include the dependencies in the deployment file. When testing the application remotely, the function does not run because of missing dependencies.

Which approach would best resolve the issue?

Use the Lambda console editor to update the code and include the missing dependencies.
Create an additional .zip file with the missing dependencies, and include the file in the original Lambda deployment package.
Add references to the missing dependencies in the Lambda function’s environment variables.
Create a layer that contains the missing dependencies, and attach it to the Lambda function.

75

76 of 78

Additional resources

AWS Lambda Developer Guide:

Amazon CloudWatch Logs User Guide:

Analyzing Log Data with CloudWatch Logs Insights

76

77 of 78

Thank you

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited. Corrections, feedback, or other questions? Contact us at https://support.aws.amazon.com/#/contacts/aws-training. All trademarks are the property of their owners.

78 of 78

Serverless as part of developing a cloud application

78

Café employees

Elastic Beanstalk

ECR hosts Docker image

EC2 instance with Docker container runs coffee supplier website

Aurora Serverless on RDS stores supplier database

AWS WAF �secures API endpoint

Café employees

Refresh cache per settings

CloudFront distribution

ElastiCache �for Memcached

AWS WAF �secures website

SNS

SQS

Suppliers

Coffee inventory

updates

Lambda

Step Functions �retrieves data from RDS and posts report to S3 with presigned URL

Amazon Cognito provides token for report requests

Amazon S3�

Developers

AWS Cloud9

CloudShell

AWS CLI

SDK for Python

Console

�bucket hosts café website

Café website users

Webpage �requests

Bucket policy

DynamoDB database stores products table

API Gateway REST API

Lambda function �does database lookups