Why Serverless Application Model (SAM) in AWS? - Purpose & Use Cases

The Big Idea

What if you could build cloud apps without wrestling with endless setup steps?

The Scenario

Imagine you want to build a small app that runs in the cloud without managing servers. You try to write all the setup by hand, creating each function, API, and permission separately.

It feels like assembling a complex puzzle without a picture.

The Problem

Manually setting up serverless apps is slow and confusing. You might forget a permission or misconfigure a function, causing errors that are hard to find.

Every change means updating many parts, increasing the chance of mistakes and delays.

The Solution

The Serverless Application Model (SAM) lets you describe your whole app in one simple file. It automatically creates all the pieces for you, like functions, APIs, and permissions.

This saves time, reduces errors, and makes your app easy to update and manage.

Before vs After

✗ Before

Create Lambda function
Set API Gateway
Assign permissions
Deploy manually

✓ After

Define SAM template with functions and APIs
Run 'sam deploy'
All resources created automatically

What It Enables

You can quickly build and update cloud apps without worrying about the complex setup behind the scenes.

Real Life Example

A startup launches a new feature by writing a SAM template. They deploy it in minutes, avoiding server setup and focusing on the app itself.

Key Takeaways

Manual setup of serverless apps is complex and error-prone.

SAM simplifies app definition with one easy template.

SAM automates deployment, saving time and reducing mistakes.

Practice

1. What is the main purpose of AWS Serverless Application Model (SAM)?

easy

A. To simplify building and deploying serverless applications using a single template

B. To manage virtual machines in the cloud

C. To create relational databases automatically

D. To monitor network traffic in AWS

Solution

1. Step 1: Understand SAM's role

   SAM is designed to help developers define serverless functions and their triggers in one file.

2. Step 2: Compare options

   Options A, B, and C describe unrelated AWS services or functions, while D correctly describes SAM's purpose.

3. Final Answer:

   To simplify building and deploying serverless applications using a single template -> Option A

4. Quick Check:

   SAM purpose = Simplify serverless apps [OK]

Hint: SAM = single template for serverless apps [OK]

Common Mistakes:

• Confusing SAM with EC2 or database services
• Thinking SAM manages infrastructure like VMs
• Assuming SAM is for monitoring

2. Which of the following is the correct syntax to define a Lambda function in a SAM template?

easy

A. MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: python3.8

B. MyFunction:
Type: AWS::Lambda::Function
Properties:
Handler: index.handler
Runtime: python3.8

C. MyFunction:
Type: AWS::EC2::Instance
Properties:
Handler: index.handler
Runtime: python3.8

D. MyFunction:
Type: AWS::S3::Bucket
Properties:
Handler: index.handler
Runtime: python3.8

Solution

1. Step 1: Identify SAM Lambda function resource type

   SAM uses the resource type AWS::Serverless::Function to define Lambda functions.

2. Step 2: Check other options

   MyFunction: Type: AWS::Lambda::Function Properties: Handler: index.handler Runtime: python3.8 uses AWS::Lambda::Function which is CloudFormation but not SAM shorthand. Options C and D are unrelated resource types.

3. Final Answer:

   MyFunction with Type AWS::Serverless::Function and correct properties -> Option A

4. Quick Check:

   SAM Lambda function type = AWS::Serverless::Function [OK]

Hint: SAM Lambda uses AWS::Serverless::Function type [OK]

Common Mistakes:

• Using AWS::Lambda::Function instead of AWS::Serverless::Function
• Confusing resource types like EC2 or S3 for Lambda
• Missing required properties like Handler or Runtime

3. Given this SAM template snippet, what event triggers the Lambda function?

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: app.lambda_handler
    Runtime: python3.8
    Events:
      ApiEvent:
        Type: Api
        Properties:
          Path: /hello
          Method: get

medium

A. A scheduled timer triggers the Lambda

B. An S3 file upload triggers the Lambda

C. A DynamoDB table update triggers the Lambda

D. An HTTP GET request to /hello triggers the Lambda

Solution

1. Step 1: Identify event type in template

   The event type is Api with Path /hello and Method get, meaning an HTTP GET request triggers the function.

2. Step 2: Eliminate other event types

   S3 upload, scheduled timer, and DynamoDB update are different event types not shown here.

3. Final Answer:

   An HTTP GET request to /hello triggers the Lambda -> Option D

4. Quick Check:

   Api event with GET /hello = HTTP trigger [OK]

Hint: Api event with Method get means HTTP GET trigger [OK]

Common Mistakes:

• Confusing Api event with S3 or timer events
• Ignoring the Method and Path properties
• Assuming default triggers without checking Events

4. You wrote this SAM template but deployment fails. What is the error?

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: app.lambda_handler
    Runtime: python3.8
    Events:
      S3Event:
        Type: S3
        Properties:
          Bucket: my-bucket
          Events: s3:ObjectCreated:Put

medium

A. The Runtime python3.8 is not supported

B. The Handler property is missing

C. The Events property under S3Event should be a list, not a string

D. The Bucket name cannot be hardcoded

Solution

1. Step 1: Check S3 event syntax

   The Events property for S3 event must be a list of event types, but here it is a string.

2. Step 2: Verify other properties

   Handler is present, python3.8 is supported, and bucket names can be hardcoded in SAM templates.

3. Final Answer:

   The Events property under S3Event should be a list, not a string -> Option C

4. Quick Check:

   S3 Events property = list, not string [OK]

Hint: S3 Events must be a list, not a single string [OK]

Common Mistakes:

• Using string instead of list for S3 Events
• Removing required Handler property
• Assuming runtime version is invalid without checking

5. You want to deploy a serverless app with two Lambda functions triggered by different events: one by HTTP GET /users and another by S3 file upload to bucket 'data-bucket'. Which SAM template snippet correctly defines both functions?

hard

A. UserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

UploadFunction:
Type: AWS::Serverless::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: get

B. UserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: get

UploadFunction:
Type: AWS::Serverless::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

C. UserFunction:
Type: AWS::Lambda::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: get

UploadFunction:
Type: AWS::Lambda::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

D. UserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: post

UploadFunction:
Type: AWS::Serverless::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

Solution

1. Step 1: Verify UserFunction HTTP event

   UserFunction must have Api event with Path /users and Method get. UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put matches this exactly.

2. Step 2: Verify UploadFunction S3 event

   UploadFunction must have S3 event with Bucket data-bucket and Events as a list including s3:ObjectCreated:Put. UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put correctly defines this.

3. Step 3: Check other options

   UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get swaps triggers between functions. UserFunction: Type: AWS::Lambda::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Lambda::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put uses AWS::Lambda::Function instead of AWS::Serverless::Function. UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: post UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put uses Method post instead of get for UserFunction.

4. Final Answer:

   Correctly defines both functions with proper triggers -> Option B

5. Quick Check:

   Correct event types and methods = UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put [OK]

Hint: Match event types and methods exactly for each function [OK]

Common Mistakes:

• Swapping event triggers between functions
• Using AWS::Lambda::Function instead of AWS::Serverless::Function
• Wrong HTTP method for API event