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

There are two ways of using S3 as a web server: 
* bucket endpoints
* website endpoints

## Bucket endpoints and website endpoints
A _bucket endpoint_ allows direct access to S3 objects using HTTPS. AWS automatically activates this endpoint when you create an S3 bucket. For example, a file called `test.txt` in the bucket `gojko` will be available from <https://gojko.s3.amazonaws.com/test.txt>. Access to the bucket endpoint is controlled by IAM. When uploading a file to S3, you can make it publicly readable (as was done with `test.txt`), so anyone can access it using a web browser. You can also mark the file as private, so others will need a pre-signed download policy to access it. You used this approach for conversion results in the previous chapter.

A _website endpoint_ is an optional feature of S3 that can perform some basic web workflows, such as redirecting users or showing index or error pages. This endpoint has a different URL from the bucket endpoint, usually a subdomain of `s3-website-us-east-1.amazonaws.com` in the `us-east-1` region, or a similar service for other regions. To use a website endpoint, you need to activate it after creating the bucket. You can activate a website endpoint for an S3 bucket from the AWS Web Console, using the _Static web site hosting_ section of the bucket properties page. Of course, it's possible to activate it using CloudFormation as well, using the `WebsiteConfiguration` properties of a bucket.

> ### Set a custom domain name
> 
> S3 will automatically assign a domain name to a website endpoint. It's not possible to set a custom domain name, but you can put a CDN between the users and the website endpoint and configure a custom domain name in the CDN. This is the usual approach for creating nice web domains for serverless applications.

Requests for the bucket endpoint only work with URLs matching an exact resource path, so asking for the root object (`/`) will not automatically show `index.html`. You can set up the website endpoint to send back an index file if users ask for the root object.

Another major difference between website endpoints and bucket endpoints is that website endpoints work using HTTP, while bucket endpoints work using HTTPS. This might sound like a security problem, but for real-world production usage,​ you should put a content distribution network in front of the S3 website endpoint, so the CDN provides HTTPS access to users. If you use Amazon's CDN, then the CDN talks to the S3 website endpoint only internally in the AWS network, so the risk of man-in-the-middle attacks between the CDN and the origin isn't that big. 

You'll need another bucket to host the files from your `web-site` directory. Users will expect to see a landing page when they type a domain in their web browsers, so you should create a new S3 bucket for static assets and set up a website endpoint. Another resource is added to the `Resources` section on the template, with the code from the following listing (indented so that `WebAssetsS3Bucket` aligns with other resource names, such as `UploadS3Bucket`).



There are two ways of using S3 as a web server: 
* bucket endpoints
* website endpoints

# Bucket endpoints and website endpoints
A _bucket endpoint_ allows direct access to S3 objects using HTTPS. AWS automatically activates this endpoint when you create an S3 bucket. For example, a file called `test.txt` in the bucket `gojko` will be available from <https://gojko.s3.amazonaws.com/test.txt>. Access to the bucket endpoint is controlled by IAM. When uploading a file to S3, you can make it publicly readable (as was done with `test.txt`), so anyone can access it using a web browser. You can also mark the file as private, so others will need a pre-signed download policy to access it. You used this approach for conversion results in the previous chapter.

A _website endpoint_ is an optional feature of S3 that can perform some basic web workflows, such as redirecting users or showing index or error pages. This endpoint has a different URL from the bucket endpoint, usually a subdomain of `s3-website-us-east-1.amazonaws.com` in the `us-east-1` region, or a similar service for other regions. To use a website endpoint, you need to activate it after creating the bucket. You can activate a website endpoint for an S3 bucket from the AWS Web Console, using the _Static web site hosting_ section of the bucket properties page. Of course, it's possible to activate it using CloudFormation as well, using the `WebsiteConfiguration` properties of a bucket.

> ### Set a custom domain name
> 
> S3 will automatically assign a domain name to a website endpoint. It's not possible to set a custom domain name, but you can put a CDN between the users and the website endpoint and configure a custom domain name in the CDN. This is the usual approach for creating nice web domains for serverless applications.

Requests for the bucket endpoint only work with URLs matching an exact resource path, so asking for the root object (`/`) will not automatically show `index.html`. You can set up the website endpoint to send back an index file if users ask for the root object.

Another major difference between website endpoints and bucket endpoints is that website endpoints work using HTTP, while bucket endpoints work using HTTPS. This might sound like a security problem, but for real-world production usage,​ you should put a content distribution network in front of the S3 website endpoint, so the CDN provides HTTPS access to users. If you use Amazon's CDN, then the CDN talks to the S3 website endpoint only internally in the AWS network, so the risk of man-in-the-middle attacks between the CDN and the origin isn't that big. 

You'll need another bucket to host the files from your `web-site` directory. Users will expect to see a landing page when they type a domain in their web browsers, so you should create a new S3 bucket for static assets and set up a website endpoint. Another resource is added to the `Resources` section on the template, with the code from the following listing (indented so that `WebAssetsS3Bucket` aligns with other resource names, such as `UploadS3Bucket`).



In this lesson, you will learn how to use S3 as a web server by getting familiar with bucket endpoint​s and ​website endpoints.

Using S3 as a Web Server

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

Using S3 as a Web Server

Bucket endpoints and website endpoints #