AWS Lambda and Serverless Computing

AWS Lambda is a serverless compute service that runs code without requiring servers to be managed. Code is uploaded to Lambda, and AWS handles everything — the servers, the operating system, the scaling, and the availability. Lambda runs the code only when triggered and charges only for the actual execution time — down to the millisecond.

What Does "Serverless" Mean?

Serverless does not mean there are no servers. It means the servers are invisible — AWS manages them entirely. From a developer's perspective, there is no server to configure, patch, or monitor. The focus stays on writing code, not managing infrastructure.

Traditional approach: Launch an EC2 server, configure it, deploy the application, keep it running 24/7, pay for it even when no users are active.

Serverless approach: Write the function, upload to Lambda, it runs only when triggered, pay only for execution time.

How AWS Lambda Works

[Trigger] → [Lambda Function Runs] → [Returns Result / Takes Action]

Examples of triggers:
- HTTP request via API Gateway
- File uploaded to S3
- Record inserted into DynamoDB
- Message in SQS queue
- Scheduled time (like a cron job)
- CloudWatch alarm triggered

Lambda functions are event-driven. Nothing runs until a trigger fires. When triggered, Lambda spins up a container, runs the code, returns the result, and shuts down. This entire process can complete in milliseconds.

Lambda Key Concepts

Function

A Lambda function is the code unit. It contains the business logic to execute. Lambda supports multiple programming languages:

• Python
• Node.js (JavaScript)
• Java
• Go
• Ruby
• C# (.NET)
• Custom runtimes (any language via container images)

Handler

The handler is the entry point of a Lambda function — the specific function within the code file that Lambda calls when triggered.

Example Python Lambda function that returns a greeting:

def lambda_handler(event, context):
    name = event.get('name', 'World')
    return {
        'statusCode': 200,
        'body': f'Hello, {name}!'
    }

When triggered with {"name": "Ravi"}, this returns Hello, Ravi!.

Event and Context

• event: The data passed to the function from the trigger. For an API Gateway trigger, this contains HTTP request data. For an S3 trigger, it contains bucket and object details.
• context: Contains metadata about the invocation — function name, memory limit, remaining time, etc.

Execution Role

A Lambda function needs permissions to interact with other AWS services. These permissions are granted through an IAM Role attached to the function. Example: A function that reads from S3 and writes to DynamoDB needs a role with s3:GetObject and dynamodb:PutItem permissions.

Lambda Limits and Configuration

Lambda automatically increases memory allocation to increase CPU power. There is no way to directly configure CPU — it scales proportionally with memory.

Lambda Pricing

Lambda charges are based on two factors:

• Number of requests: $0.20 per 1 million requests (after the free tier).
• Execution duration: Charged per GB-second — the amount of memory used multiplied by the time the function ran.

Example: A function with 512 MB memory runs for 200ms. Cost = 0.5 GB × 0.2 seconds = 0.1 GB-second. At $0.0000166667 per GB-second, this costs a fraction of a cent. Lambda is extremely cost-efficient for intermittent workloads.

Common Lambda Use Cases

Lambda with API Gateway — Building a REST API

[Client / Browser]
       |
  HTTP Request: GET /products
       |
[API Gateway] ← manages HTTP routing, auth, rate limiting
       |
[Lambda Function: getProducts]
       |
[DynamoDB: products table]
       |
  Returns product list as JSON
       |
[API Gateway] → sends response back to client

This entire backend requires no server. API Gateway handles HTTP. Lambda runs the code. DynamoDB stores the data. It scales to millions of requests automatically.

Cold Starts vs Warm Starts

When a Lambda function runs for the first time (or after a period of inactivity), AWS must prepare a new container. This initialization takes extra time — called a cold start. Typically, this adds 100ms to a few seconds of latency depending on the language and package size.

If the same function runs again quickly, AWS reuses the existing container — called a warm start — which has no initialization delay.

Solutions for cold start problems:

• Provisioned Concurrency: Pre-warms a defined number of Lambda instances so they are always ready.
• Keep functions small and simple: Smaller packages initialize faster.
• Use lightweight languages: Python and Node.js have faster cold starts than Java or .NET.

Lambda Layers

Lambda Layers are packages of code or libraries that can be shared across multiple Lambda functions. Instead of including common libraries (like pandas or boto3) in every function's deployment package, a layer is created once and referenced by many functions.

Real-World Example — E-Commerce Order Notification

When a customer places an order:

[Customer places order]
           |
[Order saved in DynamoDB]
           |
[DynamoDB Streams event fires]
           |
[Lambda: processOrder function triggered]
           |
  +--------+--------+
  |                 |
[SNS: send email  [SQS: queue for
 confirmation to   warehouse system]
 customer]

No server is running continuously. Lambda fires only when an order is placed, processes it instantly, and stops. The cost is nearly zero for small to medium order volumes.

Summary

• Lambda runs code without server management. AWS handles provisioning, scaling, and maintenance.
• Lambda is event-driven — it runs only when triggered by events from S3, API Gateway, DynamoDB, SQS, and more.
• Pricing is based on number of requests and execution duration — extremely cost-efficient for intermittent workloads.
• Cold starts add latency on first invocation. Provisioned Concurrency eliminates cold starts for critical functions.
• Lambda works best for short-lived tasks (under 15 minutes) — not for long-running processes.