Become an AWS pro by learning to run serverless applications with AWS Lambda. Developed by AWS Solution Certified Architects. Get hands-on, no setup, no cleanup, no hassle.

aws_image.tar.gz

LANG

LC_ALL

aws_access_key_id

aws_secret_access_key

BUCKET_NAME

aws_region

dockerjob

dockerjob-copy

RunSamLogsTail

RunCfnLint

RunSamLocal

RunVersionCode

RunGradualDeployment

RunDeploymentAlert

RunChap6CustomisingResponses

RunChap6Processingrequestparameters

RunChap6GlobalSettings

RunChap6CreatingParameterisedCloudFormationStacks

RunChap7

RunChap8

RunChap9AvoidingCircularReferences

RunChap9ConditionalResources

RunChap10InvokingSystemUtilities

RunChap10PublishingToSAR

RunChap11UploadingFilestoS3

RunChap12LambdaUtilityFunctions

dockerjob-copy-ForceRelaunch

dockerjob-copy-copy-FR

RunSamLogsTail-copy

RunCfnLint-copy

RunSamLocal-copy

RunVersionCode-copy

RunGradualDeployment-copy

RunDeploymentAlert-copy

RunChap6CustomisingResponses-copy

RunChap6Processingrequestparameters-copy

RunChap6GlobalSettings-copy

RunChap6CreatingParameterisedCloudFormationStacks-copy

RunChap7-copy

RunChap8-copy

RunChap9AvoidingCircularReferences-copy

RunChap9ConditionalResources-copy

RunChap10InvokingSystemUtilities-copy

RunChap10PublishingToSAR-copy

RunChap11UploadingFilestoS3-copy

RunChap12LambdaUtilityFunctions-copy

RunSamLogsTail-copy1

RunVersionCode-copy1

RunGradualDeployment-copy1

RunDeploymentAlert-copy1

RunChap6CustomisingResponses-copy1

RunChap6Processingrequestparameters-copy1

RunChap6GlobalSettings-copy1

RunChap6CreatingParameterisedCloudFormationStacks-copy1

RunChap7-copy1

RunChap8-copy1

RunChap9AvoidingCircularReferences-copy1

RunChap9ConditionalResources-copy1

RunChap10InvokingSystemUtilities-copy1

RunChap10PublishingToSAR-copy1

RunChap11UploadingFilestoS3-copy1

RunChap12LambdaUtilityFunctions-copy1

In the world of modern development, serverless computing has become table stakes. Serverless computing has seen a major uptake with AWS Lambda having an increased adoption of 667% in 2018. Companies are making the switch to serverless for shorter time to market and decreased operational costs, but for you the advantage lies in the ability to offload the burden of managing infrastructure to serverless platforms, so you can focus on building even better apps.

In this course, you will learn how to run serverless applications using AWS Lambda. You’ll start with the basics such as creating a web service where you’ll learn the steps to deploy an AWS Serverless Application Model (SAM). You’ll then move on to more advanced topics such as handling HTTP Requests, using external storage, and managing sessions and user workflows. By the end of this course, you will be ready to work with AWS Lambda in a professional setting, and you’ll have a great, transferable skill that employers will love to see.

Running Serverless Applications with AWS Lambda

# Description

After the transformation comes the template description:

```yaml
Description: >
  sam-app

  Sample SAM Template for sam-app
```

The `Description` section contains a free-form explanation of the template. This section is useful if you want to publish the template or give it to another team, but it isn't necessary. You can safely skip it when creating templates for small experiments. 

> ### Multi-line text in YAML
>
> YAML files usually contain text values on the same line as the corresponding key. You can use the right angle bracket (`>`) or a pipe (`|`) to signal that what follows is multi-line text, indented one level. The difference is that `>` removes line breaks from the result, and `|` preserves line breaks.

# Global application settings
After the description, the example SAM template contains global application settings. This is a SAM-specific extension to CloudFormation and enables you to reduce the overall template file size by listing common settings in a single place instead of repeating them for each Lambda function. The example template contains just a single function, so adding global values doesn't make a lot of difference, but this section is useful for more complex applications. The sample template usually contains a global `Timeout` setting, the number of seconds the function is allowed to run in Lambda:

```yaml
Globals:
  Function:
    Timeout: 3
```
# Resources
Next comes the `Resources` section, which lists the services or resources for CloudFormation to configure: 

```yaml
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get
```

This is where things become really interesting. With CloudFormation, each resource starts with its own block. The first line specifying a resource is the _logical ID_ of the resource. In the sample template, `HelloWorldFunction` is a logical ID of a Lambda function. The logical ID is an internal name that CloudFormation uses to refer to a resource in a single template. It is effectively a variable name, and you can use it to refer to a resource when connecting it with other resources within the same template.

CloudFormation will create the actual ('physical') function name using a randomised string based on the logical ID. This makes it possible to create several instances of the same infrastructure in a single AWS account (for example, for development, testing and production), without causing any resource conflicts. 

> ### Do not set resource names
>
> CloudFormation allows you to specify names for many resource types, including functions, using the `Name` property. Unless there is a very specific reason why you need this, avoid setting physical names. Letting CloudFormation set random names makes it easy to create several stacks based on the same template and avoid resource naming conflicts.

Each resource needs to specify a `Type` property which tells CloudFormation what to create. For the `HelloWorldFunction`, the type is `AWS::Serverless::Function`. This is another SAM extension to CloudFormation, making it easy to set up Lambda functions. You will almost always use this type when creating Lambda functions with SAM. 

Following the type, a template usually lists configuration properties for a resource, depending on its type. The following three properties are required for a Lambda function:

* `CodeUri` points to the source code package for the function. This is usually a local directory with the source code, relative to the SAM template file.
* `Runtime` is the execution engine for the function.
* `Handler` is the main execution entry point. 

> ### Specifying Lambda handlers
>
> The Lambda handler is the main function responsible for processing incoming requests. The format of this setting depends on the runtime type. For Node.js, the format is `module.function`, where `module` is the file name (without the `.js` extension). The previous example points at `app.lambdaHandler`, meaning the function `lambdaHandler` in the `app.js` file.

Serverless functions can have some other properties, which will be introduced in the following chapters. For now, only the `Events` property is important. Lambda functions usually run in response to some external events. The `Events` property configures a set of triggers for the function. Structurally, this property resembles the main `Resources` section. Each event has a logical ID followed by `Type` and `Properties`, which are type-specific event configuration attributes. 

The example template sets up an HTTPS service, so it automatically declares an `Api` event type. This represents API Gateway, an AWS service that can accept client HTTP requests. You will use a browser to send HTTPS requests to API Gateway, and the gateway will pass requests to your Lambda function. For `Api` event types, it's important to specify the HTTP method and request path. The example template sets up a Lambda call when clients request the `/hello` path, using the `GET` method. 

This template involves another AWS service, which is not explicitly listed. It is called Identity and Access Management (IAM). IAM lets you configure access policies for AWS resources. If you just create a Lambda function without configuring IAM, no other AWS service will be allowed to invoke it. To actually make the function do something useful, you need to let IAM know who is allowed to send requests to it. SAM makes this easy because it will automatically set up the correct security privileges from event definitions. Because you have a single event configured to invoke a Lambda function from API Gateway, SAM will tell IAM to allow this connection automatically.

In this lesson, you'll see some further sections from 'template.yaml' and learn what they represent. 

Further Sections of 'template​.yaml'

Getting Started

Setup Tools for Local Development

Creating a Web Service

Host a Serverless Application on AWS Lambda

Development and Troubleshooting

Core Features of AWS Lambda

Handling HTTP Requests

Using External Storage

Cheaper, Faster, Serverless

Handling Platform Events

Using Application Components

Managing Sessions and User Workflows

Designing Robust Applications

Deployment Options

Process Amazon SNS Notifications with AWS Lambda

Further Sections of 'template.yaml'

Description #

Multi-line text in YAML #