Serverless with AWS Lambda

Why serverless?

With EC2 you rent a server by the hour. You choose its size, patch its operating system, and pay for it even at 3 am when nobody uses your app. Serverless is a different deal. There are still servers, but AWS owns and manages them completely. You give AWS a small piece of code and say when it should run. AWS starts it, runs it, and stops it.

Three ideas make serverless attractive. First, no servers to manage: no operating system patches and no capacity planning. Second, automatic scaling: one request or ten thousand, AWS starts as many copies as needed. Third, scale to zero and pay per use: when there are no requests, there is no compute bill.

A Lambda function: handler, event and context

A Lambda function is your code plus its settings: the runtime, memory, timeout and permissions. The runtime is the language environment that runs your code. AWS provides managed runtimes for Python, Node.js, Java, .NET and Ruby. Go and Rust run on the OS-only runtime, and you can also package a function as a container image.

The handler is the function Lambda calls each time. It receives two things. The event is a JSON object that describes what happened: an HTTP request, a file upload, a queue message. The context is an object with details about this run, such as the request ID and how many milliseconds are left before the timeout.

import json

def handler(event, context):
    params = event.get("queryStringParameters") or {}
    name = params.get("name", "friend")
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": f"Namaste, {name}!"}),
    }

Triggers: what makes a function run

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  ThumbnailFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: app.handler
      CodeUri: src/
      MemorySize: 512
      Timeout: 30
      Environment:
        Variables:
          OUTPUT_PREFIX: thumbnails/
      Events:
        PhotoUploaded:
          Type: S3
          Properties:
            Bucket: !Ref PhotosBucket
            Events: s3:ObjectCreated:*
        Nightly:
          Type: Schedule
          Properties:
            Schedule: cron(30 20 * * ? *)
  PhotosBucket:
    Type: AWS::S3::Bucket

Limits you must know

How Lambda is priced

You pay for two things. Requests: about US$0.20 per million. Duration, measured in GB-seconds: the memory you chose in GB multiplied by the seconds your code ran. On x86 in us-east-1 one GB-second costs about US$0.0000166667; Arm (Graviton) functions cost less. Every month the always-free allowance covers 1 million requests and 400,000 GB-seconds. Prices change and differ by Region, so always check the current pricing page.

Worked example: a function with 512 MB (0.5 GB) runs for 200 ms (0.2 s) and gets 3 million requests a month. Duration is 3,000,000 × 0.5 × 0.2 = 300,000 GB-seconds, which fits inside the free 400,000. Requests: 3 million minus 1 million free leaves 2 million, which is 2 × US$0.20 = US$0.40 for the month.

Cold starts

When a request arrives and no copy of your function is ready, Lambda must create a new execution environment: download your code, start the runtime, and run your setup code. This extra delay is a cold start. It can be under 100 ms for a small Python function or a few seconds for a large Java app. Later requests reuse the warm environment and are fast.

• Keep the package small and avoid heavy frameworks you do not need.
• Create SDK clients and database connections outside the handler, so warm runs reuse them.
• Give more memory: you also get more CPU, so setup finishes sooner.
• Use provisioned concurrency (copies kept warm, charged even when idle) for latency-sensitive APIs.
• Use SnapStart where your runtime supports it (Java, and newer Python and .NET versions; check the docs).

Execution role and environment variables

Every function has an execution role: an IAM role Lambda takes on when your code runs. If the code reads from DynamoDB, the role needs that permission and nothing more. The managed policy AWSLambdaBasicExecutionRole lets the function write its logs to CloudWatch. Environment variables hold settings such as a table name or a stage name, so the same code runs in dev and prod.

aws lambda invoke --function-name hello-api \
  --cli-binary-format raw-in-base64-out \
  --payload '{"queryStringParameters":{"name":"Asha"}}' out.json
cat out.json

aws lambda update-function-configuration --function-name hello-api \
  --memory-size 512 --timeout 30 \
  --environment "Variables={STAGE=dev,TABLE_NAME=orders-dev}"

When NOT to use Lambda

• Jobs longer than 15 minutes, such as a two-hour video render. Use ECS with Fargate or AWS Batch, or split the job with Step Functions.
• A steady, heavy load all day and night. A right-sized EC2 or container fleet with a Savings Plan is often cheaper.
• Work that needs a GPU, or a lot of local state kept between requests.
• APIs where even an occasional cold start of a second is not acceptable, unless you pay for provisioned concurrency.