λ AWS Lambda Function Development

What Is AWS Lambda?

AWS Lambda runs your code in response to events without any server for you to provision or manage. You upload a function, tell Lambda what should trigger it, and Lambda handles running it — from a handful of calls a day to thousands per second — billing you only for the milliseconds it actually executes.

💡 Analogy — an on-demand chef. Running your own server is like keeping a restaurant kitchen staffed around the clock: you pay for the space, the ovens, and the cooks whether or not anyone orders. Lambda is a delivery service with on-demand chefs: a chef (a function instance) appears the moment an order (an event) arrives, cooks in isolation, and clocks out when done. Ten orders at once? Ten chefs. No orders? No bill.

The Handler Model

Every Lambda function has a handler: the entry point Lambda calls with two arguments — the event (the payload describing what triggered the function) and the context (runtime metadata like the request ID and remaining time). Here is a modern handler using ES modules on a current Node.js runtime:

// index.mjs  — deployed on the nodejs20.x runtime
export const handler = async (event, context) => {
  console.log('event:', JSON.stringify(event));
  console.log('requestId:', context.awsRequestId);

  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message: 'Hello from Lambda!' }),
  };
};

The same idea in Python:

import json

def lambda_handler(event, context):
    print("event:", json.dumps(event))
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": "Hello from Lambda!"}),
    }

The Execution Environment

Understanding how Lambda runs your code is the difference between a snappy function and a sluggish one. Each invocation goes through two phases:

• Init phase — Lambda creates the execution environment, loads your code, and runs everything outside the handler (imports, client construction, top-level code). This happens on a cold start.
• Invoke phase — Lambda runs the handler itself. On a warm invocation the environment already exists, so only this phase runs.

Because warm environments are reused, anything you set up outside the handler survives between invocations. Do expensive work — building SDK clients, opening connection pools, loading config — once at the module top level:

import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, QueryCommand } from '@aws-sdk/lib-dynamodb';

// Built ONCE during init and reused by every warm invocation
const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const TABLE = process.env.TABLE_NAME;

export const handler = async (event, context) => {
  console.log('remaining ms:', context.getRemainingTimeInMillis());

  const { Items } = await ddb.send(new QueryCommand({
    TableName: TABLE,
    KeyConditionExpression: 'id = :id',
    ExpressionAttributeValues: { ':id': event.id },
  }));

  return { statusCode: 200, body: JSON.stringify(Items) };
};

Memory, CPU & Cost

Lambda has a single performance dial: memory. Crucially, CPU is allocated proportionally to memory — more memory means a faster vCPU, not just more RAM. That produces a counter-intuitive result: bumping memory up can make a function both faster and cheaper, because it finishes in far less billed time.

Event Sources & Triggers

Lambda functions are invoked in three models, each with different retry and response behaviour.

Synchronous — the caller waits

Used by API Gateway, Application Load Balancer, and direct SDK calls. The caller blocks until your function returns, and your return value is the response. A single handler can route by HTTP method:

export const handler = async (event) => {
  const { httpMethod, pathParameters, body } = event;
  const id = pathParameters?.id;

  let result;
  switch (httpMethod) {
    case 'GET':    result = id ? await getItem(id) : await listItems(); break;
    case 'POST':   result = await createItem(JSON.parse(body)); break;
    case 'PUT':    result = await updateItem(id, JSON.parse(body)); break;
    case 'DELETE': result = await deleteItem(id); break;
    default:
      return { statusCode: 405, body: JSON.stringify({ message: 'Method not allowed' }) };
  }

  return {
    statusCode: result.statusCode,
    headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' },
    body: JSON.stringify(result.body),
  };
};

Asynchronous — fire and forget

Used by S3 events, SNS, and EventBridge. Lambda queues the event, returns immediately to the caller, and retries automatically on failure (typically twice), routing exhausted events to a Dead Letter Queue if configured. A thrown error here signals "retry me":

// Triggered when a new object lands in an S3 bucket
export const handler = async (event) => {
  for (const record of event.Records) {
    const bucket = record.s3.bucket.name;
    const key = decodeURIComponent(record.s3.object.key.replace(/\+/g, ' '));

    if (/\.(jpe?g|png)$/i.test(key)) {
      await processImage(bucket, key);
    } else {
      console.log(`Skipping unsupported file: ${key}`);
    }
  }
  // Throwing here would let Lambda retry the whole event
};

Stream / poll-based — batches of records

Used by DynamoDB Streams, Kinesis, and SQS. Lambda polls the source and delivers batches of records. Your handler loops over event.Records:

import { unmarshall } from '@aws-sdk/util-dynamodb';

export const handler = async (event) => {
  for (const record of event.Records) {
    const type = record.eventName; // INSERT | MODIFY | REMOVE
    const newImage = record.dynamodb.NewImage ? unmarshall(record.dynamodb.NewImage) : null;

    if (type === 'INSERT') await onInsert(newImage);
    if (type === 'MODIFY') await onUpdate(newImage);
    if (type === 'REMOVE') await onDelete(record.dynamodb.Keys);
  }
  return { processed: event.Records.length };
};

IAM & Configuration

Execution roles & least privilege

Every function runs with an IAM execution role that defines exactly which AWS resources it may touch. Grant only what the function needs — nothing more. This policy lets a function write logs and read/write one specific DynamoDB table:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Notes"
    }
  ]
}

Environment variables & secrets

Use environment variables for configuration — table names, feature flags, endpoints — and give them sensible defaults. Do not store secrets in plain environment variables; fetch them from AWS Secrets Manager or SSM Parameter Store instead.

const stage = process.env.STAGE ?? 'dev';
const table = process.env.TABLE_NAME;        // config — fine as an env var
// const dbPassword = process.env.DB_PASSWORD;  // ❌ don't do this for secrets

Deploying a Function

Quick path — the AWS CLI

For a single function, zip the code and create it directly:

# Package the code
zip function.zip index.mjs

# Create the function
aws lambda create-function \
  --function-name hello-notes \
  --runtime nodejs20.x \
  --role arn:aws:iam::123456789012:role/lambda-notes-role \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --timeout 10 \
  --memory-size 256

# Later, ship a code change
aws lambda update-function-code \
  --function-name hello-notes \
  --zip-file fileb://function.zip

Repeatable path — AWS SAM

Clicking around the console doesn't scale. AWS SAM (Serverless Application Model) is infrastructure-as-code: one template declares the function, its trigger, its permissions, and the table it uses. This is how real projects ship.

# template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  NotesFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./src/
      Handler: index.handler
      Runtime: nodejs20.x
      MemorySize: 256
      Timeout: 10
      Environment:
        Variables:
          TABLE_NAME: !Ref NotesTable
      Policies:
        - DynamoDBCrudPolicy:            # scoped managed policy — least privilege
            TableName: !Ref NotesTable
      Events:
        Api:
          Type: Api
          Properties:
            Path: /notes
            Method: get

  NotesTable:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: id
        Type: String

Outputs:
  ApiUrl:
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/notes/"

# Build, then deploy interactively the first time
sam build
sam deploy --guided

Hands-on Exercise

import { randomUUID } from 'node:crypto';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, PutCommand } from '@aws-sdk/lib-dynamodb';

// init phase — reused by warm invocations
const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const TABLE = process.env.TABLE_NAME;

export const handler = async (event) => {
  try {
    const body = JSON.parse(event.body ?? '{}');
    if (!body.title || typeof body.title !== 'string') {
      return { statusCode: 400, body: JSON.stringify({ message: 'title is required' }) };
    }

    const now = new Date().toISOString();
    const note = {
      id: randomUUID(),
      title: body.title,
      content: body.content ?? '',
      completed: false,
      createdAt: now,
      updatedAt: now,
    };

    await ddb.send(new PutCommand({ TableName: TABLE, Item: note }));

    return { statusCode: 201, headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(note) };
  } catch (err) {
    console.error('createNote failed:', err);
    return { statusCode: 500, body: JSON.stringify({ message: 'Could not create note' }) };
  }
};

Quiz

Summary & Next Steps

📚 Further Reading

• AWS Lambda Developer Guide
• AWS SAM Developer Guide
• Powertools for AWS Lambda (TypeScript)

🚀 What's Next?

Writing functions one at a time gets tedious fast. Next, in Building APIs with the Serverless Framework, you'll wire many functions, a database, and an API together from a single config file — and deploy the whole stack with one command.