Serverless Application Model (SAM) in AWS - Time & Space Complexity

Time Complexity: Serverless Application Model (SAM)

O(n)

Understanding Time Complexity

We want to understand how the time to deploy a serverless app changes as the app grows.

Specifically, how does adding more functions or resources affect deployment time?

Scenario Under Consideration

Analyze the time complexity of deploying a SAM template with multiple Lambda functions.

sam deploy --template-file template.yaml --stack-name my-stack --capabilities CAPABILITY_IAM

# template.yaml defines multiple AWS::Serverless::Function resources
# Each function has its own code and configuration
# Deployment packages and CloudFormation stack updates happen here

This sequence deploys a serverless app with several Lambda functions using SAM.

Identify Repeating Operations

Look at what happens repeatedly during deployment:

• Primary operation: Packaging and uploading each Lambda function's code to S3.
• How many times: Once per function defined in the template.
• Secondary operation: CloudFormation stack update calls to create or update each resource.
• How many times: Depends on the number of resources, including functions and others.

How Execution Grows With Input

As you add more functions, the deployment time grows roughly in direct proportion.

Input Size (n)	Approx. API Calls/Operations
10	About 10 package uploads + 1 stack update
100	About 100 package uploads + 1 stack update
1000	About 1000 package uploads + 1 stack update

Pattern observation: Each added function adds one packaging and upload operation, so time grows linearly.

Final Time Complexity

Time Complexity: O(n)

This means deployment time grows roughly in direct proportion to the number of functions you deploy.

Common Mistake

[X] Wrong: "Adding more functions won't affect deployment time much because it's all one command."

[OK] Correct: Each function's code must be packaged and uploaded separately, so more functions mean more work and longer deployment.

Interview Connect

Understanding how deployment time grows helps you plan and explain scaling serverless apps clearly and confidently.

Self-Check

"What if we used a single shared deployment package for multiple functions? How would the time complexity change?"

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