Serverless computing flips the traditional deployment model. Instead of provisioning servers, configuring operating systems, and managing capacity, you write a function and hand it to a cloud provider. The provider runs your code in response to events, scales it automatically, and bills you only for the milliseconds your code actually executes. You never see a server, never patch an OS, never configure autoscaling rules. The infrastructure is invisible.

The core abstraction is Function as a Service (FaaS). AWS Lambda, Google Cloud Functions, and Azure Functions all implement this model. You upload a function (a single entry point with defined input and output), configure a trigger (an HTTP request, a queue message, a file upload), and the platform handles everything else: provisioning compute, routing events, scaling instances, and recycling resources when idle.

The Execution Model

Every function invocation runs inside an isolated container. The platform provisions this container, loads your code, initializes the runtime (Node.js, Python, Java, Go), and calls your handler function. Your handler receives the event payload and a context object, does its work, and returns a response. The entire execution is stateless: each invocation is independent, shares no memory with other invocations, and cannot assume any local state persists between calls.

1// AWS Lambda handler structure
2exports.handler = async (event, context) => {
3  // event: the trigger payload (HTTP request body, S3 event, etc.)
4  // context: metadata (request ID, remaining time, memory limit)
5
6  const result = processEvent(event);
7
8  return {
9    statusCode: 200,
10    body: JSON.stringify(result)
11  };
12};

This statelessness is the reason serverless scales so simply. The platform can run 1 instance or 1,000 instances of your function simultaneously. There is no shared state to coordinate, no session affinity to maintain, no distributed lock to acquire. Each invocation is a completely isolated unit of work.

Resource Constraints

Functions are not general-purpose compute. They operate within strict limits designed to enforce the short-lived, event-driven model:

Time limit: AWS Lambda allows a maximum of 15 minutes per invocation. Google Cloud Functions allows 9 minutes (HTTP) or 10 minutes (event-driven). Azure Functions allows 10 minutes by default. If your workload needs to run for hours, serverless is the wrong tool.

Memory: Configurable from 128 MB to 10 GB on Lambda. Memory allocation also determines CPU allocation proportionally. A 1,792 MB Lambda gets 1 full vCPU. A 128 MB Lambda gets a fraction. This coupling means you sometimes increase memory not because you need the RAM, but because you need the CPU.

Package size: Lambda allows 50 MB zipped (250 MB unzipped) for direct upload, or 10 GB via container images. Larger packages mean slower cold starts because the platform must download and extract your code before the first invocation. Container image support is significant because it lets teams use familiar Docker workflows while still getting Lambda's event-driven scaling and per-invocation pricing.

Concurrency: Each AWS account has a default concurrency limit of 1,000 simultaneous Lambda executions across all functions. Individual functions can reserve concurrency from this pool. A function that consumes all available concurrency starves every other function in the account.

Pricing Model

Serverless pricing is granular. AWS Lambda charges per request ($0.20 per million) plus per GB-second of compute time ($0.0000166667 per GB-second). A function using 512 MB for 200ms costs $0.0000016667 per invocation. At 1 million invocations per month, that is $1.67 in compute plus $0.20 in request fees. Total: $1.87.

Compare that to a t3.medium EC2 instance running 24/7: roughly $30 per month. If your function only runs 1 million times at 200ms each, that is 200,000 seconds of compute, about 55 hours out of 730 hours in a month. You are paying for 7.5% utilization on EC2 but 100% utilization on Lambda. This is why serverless dominates for bursty, low-volume workloads.

The pricing breaks down at sustained high volume. At 100 million invocations per month, Lambda costs $187 in compute. An equivalent fleet of containers might cost $120. The crossover point depends on your specific workload, but the principle is consistent: serverless wins on cost when utilization is low and loses when utilization is high and constant.

There are also hidden costs beyond compute. API Gateway adds $1.00-$3.50 per million requests. Data transfer between Lambda and other AWS services is free within the same region, but cross-region or internet-bound transfers add bandwidth charges. CloudWatch Logs ingestion charges $0.50 per GB, and verbose Lambda logging at high volume can exceed the compute cost itself. A complete cost analysis must include these ancillary charges, not just the Lambda compute bill.