Serverless Application Model (SAM) in AWS - Commands & Configuration

Introduction

Building serverless applications can be complex because you need to manage many resources like functions, APIs, and databases. AWS Serverless Application Model (SAM) helps by letting you define all these resources in a simple file, so you can deploy and manage your app easily.

When you want to create a simple API using AWS Lambda and API Gateway without managing servers.

When you need to deploy a function that reacts to events like file uploads or database changes.

When you want to package and deploy your serverless app as one unit instead of separate pieces.

When you want to test your serverless functions locally before deploying to the cloud.

When you want to automate deployment of serverless apps using a single configuration file.

Config File - template.yaml

template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Simple SAM app with one Lambda function and API Gateway
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.lambda_handler
      Runtime: python3.9
      CodeUri: ./src/
      Events:
        HelloWorldApi:
          Type: Api
          Properties:
            Path: /hello
            Method: get

This file defines a serverless app with one Lambda function called HelloWorldFunction. The Transform line tells AWS this is a SAM template. The function uses Python 3.9 and runs code from the src folder. It is triggered by an HTTP GET request to the /hello path via API Gateway.

Commands

This command processes your SAM template and prepares your application for deployment by installing dependencies and packaging your code.

Terminal

sam build

Expected Output

Building codeuri: ./src runtime: python3.9 metadata: {} architecture: x86_64 functions: ['HelloWorldFunction']

Running PythonPipBuilder

Build Succeeded

This command deploys your serverless app to AWS. The --guided flag walks you through configuration options like region and permissions, and saves them for future deploys.

Terminal

sam deploy --stack-name my-sam-app --guided

Expected Output

Configuring SAM deploy

Stack Name [my-sam-app]: 

AWS Region [us-east-1]: 

Confirm changes before deploy [y/N]: N

Allow SAM CLI IAM role creation [Y/n]: Y

Save arguments to samconfig.toml [Y/n]: Y



Deploying with following values

===============================

Stack name                 : my-sam-app

Region                     : us-east-1

Confirm changeset          : false

Deployment s3 bucket       : sam-deployments-bucket

Capabilities               : CAPABILITY_IAM



Waiting for stack create/update to complete

Successfully created/updated stack - my-sam-app

→

--stack-name - Names the CloudFormation stack for your app

→

--guided - Runs interactive setup for deployment options

This command lists all AWS resources created by your deployed SAM app, so you can verify what is running.

Terminal

sam list resources --stack-name my-sam-app

Expected Output

Name                      Type                          LogicalId

HelloWorldFunctionRole     AWS::IAM::Role                HelloWorldFunctionRole

HelloWorldFunction        AWS::Lambda::Function          HelloWorldFunction

HelloWorldApi             AWS::ApiGateway::RestApi       HelloWorldApi

→

--stack-name - Specifies which deployed app's resources to list

This command shows the live logs from your Lambda function, helping you see what happens when it runs.

Terminal

sam logs -n HelloWorldFunction --stack-name my-sam-app --tail

Expected Output

START RequestId: 1234abcd-5678-efgh-9012-ijklmnopqrst Version: $LATEST

2024-06-01T12:00:00.000Z	1234abcd-5678-efgh-9012-ijklmnopqrst	Hello from Lambda!

END RequestId: 1234abcd-5678-efgh-9012-ijklmnopqrst

REPORT RequestId: 1234abcd-5678-efgh-9012-ijklmnopqrst Duration: 3 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 45 MB

→

-n - Specifies the function name to get logs for

→

--tail - Streams logs live as they come

Key Concept

If you remember nothing else from SAM, remember: it lets you define and deploy your serverless app with one simple file and easy commands.

Common Mistakes

Not running 'sam build' before 'sam deploy'

Your code and dependencies won't be packaged correctly, causing deployment errors or broken functions.

Always run 'sam build' first to prepare your app before deploying.

Forgetting to specify the stack name during deployment

SAM won't know which CloudFormation stack to update, causing deployment to fail or create unexpected stacks.

Use the --stack-name flag with a clear name every time you deploy.

Not checking logs after deployment

You miss errors or issues in your function that only appear when it runs in AWS.

Use 'sam logs' to view function output and troubleshoot.

Summary

Use a template.yaml file to define your serverless functions and triggers.

Run 'sam build' to prepare your app, then 'sam deploy --guided' to send it to AWS.

Check your deployed resources with 'sam list resources' and troubleshoot with 'sam logs'.

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