Serverless functions

01The idea: functions instead of servers

On a classic server, your app runs all the time and you pay for the machine whether it is busy or not. Serverless (more precisely Functions as a Service, FaaS) flips that: you deploy a function, the platform keeps it dormant, and when an event arrives it starts an execution environment, runs your handler and later freezes or discards it. Think of it like a taxi instead of owning a car: no parking, no maintenance, you pay per trip, but each trip has a short wait for pickup and you follow the taxi company's rules. 'Serverless' does not mean no servers; it means servers are the provider's problem. The main platforms are AWS Lambda, Google Cloud Run functions, Azure Functions, and edge platforms such as Cloudflare Workers, Vercel Functions and Netlify Functions.

02How an invocation works under the hood

When an event arrives and no warm environment is free, the platform does a cold start: it provisions a micro-VM (Lambda uses Firecracker) or a V8 isolate (Cloudflare Workers), downloads your code, starts the runtime and runs your initialisation code outside the handler. Then it calls the handler with the event. After the response, the environment stays warm for a while and may serve the next request without the init cost. Each environment handles one request at a time on classic Lambda, so 100 concurrent requests mean 100 environments. Code at module level runs once per environment, which is where you create database clients and load configuration. Anything in memory or /tmp may survive between calls but is never guaranteed.

• Cold start: init + first invoke, often 100 ms to over 1 s depending on runtime and package size.
• Warm start: handler only, usually a few milliseconds of overhead.
• Concurrency: number of environments running at the same moment.

03Writing an AWS Lambda function

A Lambda function is a handler that receives an event and a context. For HTTP, you put it behind a Function URL or API Gateway, which turns the HTTP request into an event object and your return value back into a response. Current managed runtimes include Node.js 24 (nodejs24.x) and Python 3.14 on Amazon Linux 2023, on x86_64 or arm64 (Graviton, usually cheaper). Memory is configurable from 128 MB to 10,240 MB and CPU scales with it; the maximum timeout is 15 minutes; synchronous request and response payloads are limited to 6 MB. Initialise SDK clients outside the handler so warm invocations reuse them.

1// index.mjs  (runtime: nodejs24.x, handler: index.handler)
2import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
3 
4const db = new DynamoDBClient({}); // created once per environment
5 
6export const handler = async (event) => {
7  const id = event.pathParameters?.id;
8  if (!id) return { statusCode: 400, body: JSON.stringify({ error: "id required" }) };
9 
10  const res = await db.send(new GetItemCommand({
11    TableName: process.env.TABLE_NAME,
12    Key: { pk: { S: `product#${id}` } },
13  }));
14  if (!res.Item) return { statusCode: 404, body: "{}" };
15  return { statusCode: 200, headers: { "content-type": "application/json" },
16           body: JSON.stringify({ id, name: res.Item.name.S }) };
17};

04Event triggers: more than HTTP

The real power of serverless is reacting to events across a cloud. On AWS, a function can run when an object lands in S3, a message arrives in SQS, a row changes in DynamoDB Streams, an EventBridge rule or schedule fires, or a Kinesis stream gets records. Invocations are synchronous (the caller waits, as with HTTP), asynchronous (the platform queues the event and retries on error, with a dead-letter destination), or via event source mappings that poll a queue or stream and deliver batches. Because asynchronous and queue triggers retry, the same event can be processed more than once: handlers must be idempotent. For SQS batches, report partial failures so only failed messages are retried.

1// SQS trigger with partial batch failures
2// (enable ReportBatchItemFailures on the event source mapping)
3export const handler = async (event) => {
4  const batchItemFailures = [];
5  for (const record of event.Records) {
6    try {
7      const job = JSON.parse(record.body);
8      await processOnce(job.id, job); // idempotent: skips already-done ids
9    } catch (err) {
10      console.error({ messageId: record.messageId, err: String(err) });
11      batchItemFailures.push({ itemIdentifier: record.messageId });
12    }
13  }
14  return { batchItemFailures };
15};

05Edge functions: code close to the user

Edge functions run in many locations worldwide, near the user, instead of one region. Cloudflare Workers use V8 isolates rather than containers: an isolate starts in milliseconds, so cold starts are nearly invisible, but the environment is a web-standard runtime (fetch, Request, Response, Web Crypto) with limited Node.js APIs and tighter CPU limits. They are ideal for redirects, auth checks, A/B testing, header rewriting, geolocation and lightweight APIs backed by edge storage (KV, D1, R2, Durable Objects). For heavy database work, a far-away database cancels the benefit: an edge function in Sydney calling a database in Frankfurt is slower than a regional function next to the database. Vercel's Functions now default to a Node.js runtime with 'Fluid compute', which lets one instance serve several concurrent requests.

1// Cloudflare Worker: geo-based redirect at the edge
2export default {
3  async fetch(request: Request): Promise<Response> {
4    const url = new URL(request.url);
5    const country = (request as any).cf?.country ?? "US";
6    if (url.pathname === "/" && country === "DE") {
7      return Response.redirect(new URL("/de", url).toString(), 302);
8    }
9    return fetch(request); // pass through to origin
10  },
11};

06Deploying with infrastructure as code

Clicking functions together in a console does not scale or survive a team change. Define functions, triggers, permissions and environment in code: AWS SAM, the Serverless Framework, AWS CDK, SST or Terraform. Each function should have its own IAM role with only the permissions it needs. Secrets come from Secrets Manager or Parameter Store, not plain environment variables in the repository. Package dependencies carefully: smaller bundles start faster, so bundle with esbuild and exclude the AWS SDK if the runtime already provides it (Node.js runtimes include SDK v3).

1# template.yaml (AWS SAM)
2AWSTemplateFormatVersion: "2010-09-09"
3Transform: AWS::Serverless-2016-10-31
4Resources:
5  GetProduct:
6    Type: AWS::Serverless::Function
7    Properties:
8      Runtime: nodejs24.x
9      Architectures: [arm64]
10      Handler: index.handler
11      MemorySize: 512
12      Timeout: 10
13      Environment: { Variables: { TABLE_NAME: !Ref Products } }
14      Policies: [ { DynamoDBReadPolicy: { TableName: !Ref Products } } ]
15      Events:
16        Api: { Type: HttpApi, Properties: { Path: /products/{id}, Method: get } }
17  Products:
18    Type: AWS::Serverless::SimpleTable

07Cost, limits and when it stops being cheap

Lambda bills per request plus GB-seconds (memory times duration, in 1 ms increments), with a monthly free tier. For bursty or low traffic this is far cheaper than an always-on server. For steady, high traffic, a function running constantly can cost more than a container or VPS doing the same work, and API Gateway, NAT gateways and logging often cost more than the function itself. Watch account concurrency limits (1,000 per region by default, raisable), reserved concurrency to protect downstream databases, and timeouts. A useful rule of thumb: serverless is ideal for event glue, webhooks, scheduled jobs and spiky APIs; long-running, connection-heavy or steady workloads fit containers better.

08Inside the execution environment lifecycle

A Lambda execution environment has three phases. Init: the platform starts extensions, the runtime, and runs your module-level code; this phase has its own 10-second limit. Invoke: the handler runs for each event, one at a time per environment. Shutdown: when the platform recycles the environment, extensions get a short window to flush. Between invokes the environment is frozen, so background work started without await (an un-awaited promise, a timer) may pause mid-flight and resume in a later invoke, which causes confusing bugs. Always await everything before returning, or use response streaming when you want to send bytes early. SnapStart, available for Java, Python and .NET, snapshots the initialised environment and resumes from it, so unique values such as random seeds and connections must be refreshed after restore.

09Concurrency, scaling and throttling

Concurrency is roughly requests per second multiplied by average duration: 200 req/s at 250 ms needs about 50 concurrent environments. Each region has an account-level concurrency quota shared by all functions, so one runaway function can throttle the rest. Reserved concurrency sets both a guaranteed slice and a maximum for a function, protecting fragile downstream systems. Provisioned concurrency keeps a number of environments initialised, removing cold starts for that capacity, at an hourly cost. When throttled, synchronous callers get 429 errors, while asynchronous events are retried for up to six hours by default. For queue triggers, maximum concurrency on the event source mapping is the safer way to limit consumers than reserved concurrency, which can cause messages to bounce back to the queue.

1# Cap a function at 50 concurrent executions
2aws lambda put-function-concurrency \
3  --function-name get-product --reserved-concurrent-executions 50
4 
5# Keep 10 environments warm on the "live" alias
6aws lambda put-provisioned-concurrency-config \
7  --function-name get-product --qualifier live \
8  --provisioned-concurrent-executions 10

10Performance tuning: memory, architecture and bundling

On Lambda, CPU is allocated in proportion to memory; at 1,769 MB a function gets the equivalent of one full vCPU. So raising memory often makes CPU-bound functions both faster and cheaper, because duration drops more than price rises. Measure with AWS Lambda Power Tuning, which runs your function at several memory sizes and plots cost against speed. arm64 (Graviton) is priced lower per GB-second and is faster for many workloads. For Node.js, bundle with esbuild, mark the AWS SDK as external, use ES modules with top-level await for initialisation, and avoid importing whole SDKs or ORMs on cold paths. For Python, trim dependencies and avoid heavy imports at module level unless they are needed on every call.

11Security model and common attack surfaces

Each function's IAM execution role is its identity; a compromised function can do anything that role allows, so scope it to specific resources and actions. Event data is untrusted input even when it comes from inside AWS: an S3 object key or SQS body can carry injection payloads. Function URLs with auth type NONE are publicly callable; use AWS_IAM auth, or validate a signature or token yourself. Secrets should be fetched from Secrets Manager or Parameter Store with caching (the AWS Parameters and Secrets Lambda Extension helps), not baked into environment variables visible in the console. Pin dependencies and scan them, because supply-chain risk is concentrated in small bundles that ship directly to production.