Why serverless architecture matters in AWS - Why It Works

Introduction

Serverless architecture lets you run applications without managing servers. It solves the problem of spending time and money on server setup and maintenance by letting cloud providers handle it for you.

When you want to build a website that can handle sudden traffic spikes without manual scaling.

When you need to run small pieces of code in response to events like file uploads or database changes.

When you want to save costs by paying only for the exact compute time your code uses.

When you want to focus on writing code instead of managing infrastructure.

When you want automatic scaling without configuring servers or load balancers.

Commands

This command creates a new AWS Lambda function named 'my-function' using Python 3.9 runtime. It specifies the execution role and the code package to run. This step deploys your serverless code to AWS.

Terminal

aws lambda create-function --function-name my-function --runtime python3.9 --role arn:aws:iam::123456789012:role/lambda-execution-role --handler lambda_function.lambda_handler --zip-file fileb://function.zip

Expected Output

{

    "FunctionName": "my-function",

    "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function",

    "Runtime": "python3.9",

    "Role": "arn:aws:iam::123456789012:role/lambda-execution-role",

    "Handler": "lambda_function.lambda_handler",

    "CodeSize": 12345,

    "Description": "",

    "Timeout": 3,

    "MemorySize": 128,

    "LastModified": "2024-06-01T12:00:00.000+0000",

    "CodeSha256": "abc123def456ghi789",

    "Version": "$LATEST",

    "TracingConfig": {

        "Mode": "PassThrough"

    },

    "RevisionId": "1a2b3c4d-5678-90ab-cdef-1234567890ab"

}

→

--function-name - Sets the name of the Lambda function

→

--runtime - Specifies the programming language runtime

→

--role - Defines the IAM role Lambda assumes to run

This command runs the Lambda function 'my-function' and saves the output to a file named output.txt. It tests that your serverless function works as expected.

Terminal

aws lambda invoke --function-name my-function output.txt

Expected Output

{

    "StatusCode": 200,

    "ExecutedVersion": "$LATEST"

}

→

--function-name - Specifies which Lambda function to invoke

This command fetches the last 5 log events from the Lambda function's log group. It helps you see what happened during function execution for debugging or monitoring.

Terminal

aws logs filter-log-events --log-group-name /aws/lambda/my-function --limit 5

Expected Output

{

    "events": [

        {

            "timestamp": 1685616000000,

            "message": "START RequestId: abcdef12-3456-7890-abcd-ef1234567890 Version: $LATEST",

            "ingestionTime": 1685616001000

        },

        {

            "timestamp": 1685616000100,

            "message": "END RequestId: abcdef12-3456-7890-abcd-ef1234567890",

            "ingestionTime": 1685616001100

        }

    ]

}

→

--log-group-name - Specifies the CloudWatch log group to query

→

--limit - Limits the number of log events returned

Key Concept

If you remember nothing else from this pattern, remember: serverless lets you run code without managing servers, automatically scaling and charging only for actual use.

Common Mistakes

Not assigning the correct IAM role to the Lambda function

The function will not have permission to run or access resources, causing failures.

Create and assign an IAM role with the necessary permissions before deploying the function.

Trying to run Lambda functions without packaging the code properly

AWS Lambda requires code to be zipped or uploaded correctly; otherwise, deployment fails.

Zip your function code and dependencies into a single package before deployment.

Ignoring logs and not checking CloudWatch for errors

Without logs, you cannot troubleshoot why your function failed or behaved unexpectedly.

Always check CloudWatch logs after invoking your Lambda to verify execution and debug issues.

Summary

Create a Lambda function with the AWS CLI by specifying the function name, runtime, role, handler, and code package.

Invoke the Lambda function to test that it runs correctly and returns expected results.

Use CloudWatch logs to monitor and debug your serverless function executions.

Practice

1. What is the main benefit of using serverless architecture in cloud computing?

easy

A. You don't need to manage or provision servers.

B. You get unlimited free storage.

C. You must manually scale your application.

D. You pay a fixed monthly fee regardless of usage.

Solution

1. Step 1: Understand serverless basics

   Serverless means the cloud provider manages servers, so you don't have to.

2. Step 2: Identify the key benefit

   This removes the need for manual server management and provisioning.

3. Final Answer:

   You don't need to manage or provision servers. -> Option A

4. Quick Check:

   Serverless = No server management [OK]

Hint: Serverless means no server setup or maintenance needed [OK]

Common Mistakes:

• Thinking serverless means free unlimited resources
• Assuming you must scale servers manually
• Believing serverless has fixed monthly costs

2. Which AWS service is an example of serverless compute?

easy

A. Amazon EC2

B. AWS Lambda

C. Amazon RDS

D. Amazon S3

Solution

1. Step 1: Identify serverless compute services

   AWS Lambda runs code without managing servers, fitting serverless compute.

2. Step 2: Compare options

   EC2 requires server management, RDS is managed database, S3 is storage.

3. Final Answer:

   AWS Lambda -> Option B

4. Quick Check:

   Serverless compute = AWS Lambda [OK]

Hint: Lambda runs code without servers, EC2 does not [OK]

Common Mistakes:

• Choosing EC2 which requires server management
• Confusing storage (S3) with compute
• Selecting RDS which is managed database, not compute

3. Consider this AWS Lambda function code snippet:

exports.handler = async (event) => {
  return { statusCode: 200, body: 'Hello Serverless!' };
};

What will be the output when this Lambda function is invoked?

medium

A. Runtime error because of missing callback

B. SyntaxError due to arrow function

C. { statusCode: 200, body: 'Hello Serverless!' }

D. Empty response with statusCode 500

Solution

1. Step 1: Analyze the Lambda handler syntax

   The handler is an async arrow function returning a valid response object.

2. Step 2: Understand Lambda response behavior

   Returning an object with statusCode and body is correct for API Gateway integration.

3. Final Answer:

   { statusCode: 200, body: 'Hello Serverless!' } -> Option C

4. Quick Check:

   Async handler returns response object [OK]

Hint: Async arrow functions can return response objects directly [OK]

Common Mistakes:

• Thinking arrow functions cause syntax errors
• Assuming callback is required in async handlers
• Expecting empty or error responses without cause

4. You wrote this AWS Lambda function but it always times out:

exports.handler = (event, context) => {
  while(true) {}
};

What is the main reason for the timeout?

medium

A. Lambda functions cannot use arrow functions.

B. Missing async keyword causes timeout.

C. The event parameter is not used.

D. The infinite loop blocks the function from returning.

Solution

1. Step 1: Identify the code behavior

   The while(true) creates an infinite loop that never ends or returns.

2. Step 2: Understand Lambda timeout cause

   Without returning or ending, Lambda runs until timeout is reached.

3. Final Answer:

   The infinite loop blocks the function from returning. -> Option D

4. Quick Check:

   Infinite loop causes timeout [OK]

Hint: Infinite loops cause Lambda to never finish [OK]

Common Mistakes:

• Blaming missing async keyword for timeout
• Thinking arrow functions are unsupported
• Assuming unused parameters cause timeout

5. You want to build a web app that scales automatically and only charges you when users interact. Which serverless feature best supports this?

hard

A. Automatic scaling with pay-per-use billing

B. Reserved instances with fixed monthly cost

C. Manual server provisioning for control

D. Pre-allocated capacity to avoid cold starts

Solution

1. Step 1: Identify serverless scaling and billing

   Serverless automatically scales with demand and charges only for actual usage.

2. Step 2: Compare options for cost and scaling

   Reserved instances and manual provisioning do not scale automatically or charge per use.

3. Final Answer:

   Automatic scaling with pay-per-use billing -> Option A

4. Quick Check:

   Serverless = scale automatically + pay per use [OK]

Hint: Serverless scales automatically and bills only when used [OK]

Common Mistakes:

• Choosing reserved instances which have fixed costs
• Thinking manual provisioning is needed for scaling
• Believing pre-allocated capacity is required in serverless