Despite its name, serverless doesn’t mean servers are absent. Code still needs to run somewhere. What serverless actually means is that you stop worrying about where and how that code runs—infrastructure provisioning, scaling, and maintenance are handled entirely by the cloud provider.
This article covers the history of the serverless model, how AWS Lambda implements Functions as a Service (FaaS), and the hard constraints you need to design around before going all-in on Lambda.
The History of Serverless Computing
To understand serverless, it helps to trace the evolution of how applications have been hosted and operated.
On-Premises: Full Ownership, Full Burden
Early application deployment meant physically racking servers, configuring operating systems, managing hardware failure, and planning capacity months in advance. Teams required dedicated infrastructure staff, and delivery cycles were slow. Every scaling decision was a capital expenditure.
Infrastructure as a Service (IaaS)
The shift to rented virtual machines—Infrastructure as a Service—was a significant improvement. Providers took responsibility for the physical hardware, redundancy, and data center operations. Teams could provision a server in minutes rather than weeks, and costs shifted from capital to operational expenditure.
IaaS remains widely used today, particularly for complex workloads that require specific OS configurations, legacy software stacks, or fine-grained network control. But engineering teams still owned everything above the hypervisor: the OS, runtime, middleware, and application stack.
Platform as a Service (PaaS)
Platform as a Service abstracted the operating system and runtime away from developers. Services such as Google App Engine (launched 2008) and AWS Elastic Beanstalk (launched 2011) let engineers deploy a Python, Java, or PHP application without configuring the underlying environment. Scaling policies, patching, and load balancing became the platform’s responsibility.
PaaS shifted the engineering focus from infrastructure to application business logic—a meaningful productivity gain for teams building standard web applications.
Serverless and Functions as a Service (FaaS)
Serverless is the next step in this progression. Martin Fowler describes serverless architectures as application designs that incorporate third-party Backend as a Service (BaaS) providers and/or custom code run in managed, ephemeral containers on a Functions as a Service (FaaS) platform.
In practical terms: if a significant portion of your application’s business logic is delegated to managed third-party services—authentication, storage, messaging, payments—you are already operating in a serverless style. The FaaS component takes this further by letting you deploy individual functions that execute in response to events, with no server provisioning at all.
AWS Lambda, launched in 2015, was the event that brought FaaS into mainstream use for production workloads.
AWS Lambda: How It Works
AWS Lambda is a managed compute service that executes your code in response to events. You supply the function code and its dependencies; AWS handles everything else—availability, auto-scaling, OS patching, and hardware maintenance.
The Billing Model
Lambda uses a pay-per-use pricing model. You are charged based on two dimensions:
- Number of invocations — each time your function is triggered counts as one request.
- Duration — the time your function runs, measured in milliseconds and rounded up to the nearest 1 ms increment (note: billing granularity has changed over Lambda’s lifetime; verify current pricing in the AWS documentation).
When a function is not executing, you pay nothing. This makes Lambda particularly cost-effective for workloads with irregular or spiky traffic patterns, compared to running an always-on EC2 instance.
What a Lambda Function Is
A Lambda function is a discrete unit of code responsible for handling one type of event or task. You package the code with its dependencies and upload it to AWS. When an event occurs, Lambda instantiates a container, runs the handler, and then exits—either returning a response or completing silently.
A typical function might:
- Receive an HTTP request via API Gateway and write a record to DynamoDB.
- Process a file uploaded to S3—resize an image, parse a CSV, or trigger a downstream workflow.
- React to an SNS notification and send an email via SES.
- Stream records from a DynamoDB or Kinesis stream for real-time processing.
Supported Event Sources
Lambda integrates natively with a wide range of AWS services as event sources, including:
- Amazon API Gateway — trigger functions via HTTP/HTTPS requests.
- Amazon S3 — react to object creation, deletion, or modification events.
- Amazon DynamoDB Streams — process table change records in near real time.
- Amazon SNS and SQS — handle messages and queue-based workloads.
- Amazon EventBridge — scheduled or rule-based invocations.
- AWS Step Functions — orchestrate Lambda functions as steps in a workflow.
The full list of supported event sources is maintained in the AWS Lambda documentation.
Supported Runtimes
Lambda natively supports Node.js, Python, Java, Go, Ruby, C#, and PowerShell. For languages or runtimes not on this list, you can use a custom runtime via the Lambda Runtime API, which allows you to run virtually any language on top of the underlying Amazon Linux environment.
Limitations of AWS Lambda
Lambda’s constraints are not arbitrary—they are fundamental to how the service achieves elasticity and cost efficiency. Understanding them is essential before committing to a serverless architecture.
Maximum Execution Timeout
A Lambda function can run for a maximum of 900 seconds (15 minutes). Any workload that requires longer execution—large batch jobs, video transcoding, complex machine learning inference—must be decomposed or offloaded. Common approaches include:
- Job splitting — break long-running work into chunks, each handled by a separate invocation.
- Recursive invocation — the function re-invokes itself with state about what work remains.
- Step Functions orchestration — use AWS Step Functions to coordinate multiple Lambda executions as a workflow.
- Dedicated compute — fall back to EC2, ECS, or AWS Batch for genuinely long-running processes.
Ephemeral, Stateless Execution Containers
Lambda functions run in ephemeral containers that AWS provisions and destroys as needed. You must never rely on local state persisting between invocations. A warm container may be reused for a subsequent invocation (allowing /tmp caching as an optimization), but you cannot depend on this behavior.
Each execution environment has 512 MB of writable space in the /tmp directory. This is intended only for temporary files needed within a single invocation—not as durable storage. All persistent state must be stored in an external service such as DynamoDB, S3, ElastiCache, or RDS.
Binary and Native Dependency Compilation
Because Lambda runs on Amazon Linux, any native binaries or compiled extensions bundled with your function must be built for that environment. A binary compiled on macOS or Windows will not work. Use Docker with an Amazon Linux base image (AWS provides public.ecr.aws/lambda/* images for this purpose) to compile dependencies before packaging your deployment artifact.
Cold Starts
When Lambda needs to provision a new execution container—either because no warm container is available or because concurrency has scaled out—there is an initialization latency known as a cold start. Cold start duration varies by runtime, package size, and VPC configuration. For latency-sensitive workloads, strategies to mitigate cold starts include:
- Using Provisioned Concurrency to keep a set number of execution environments initialized and ready.
- Keeping deployment packages small to reduce initialization time.
- Choosing a runtime with lower cold-start overhead (Node.js and Python generally initialize faster than Java-based runtimes under equivalent conditions).
Concurrency and Throttling
Lambda scales by running multiple concurrent function instances. However, each AWS account has a default regional concurrency limit. Exceeding this limit causes throttling. If your workload can generate very high burst traffic, verify your account’s concurrency quota and request an increase via the AWS Service Quotas console before going to production.
When Serverless with AWS Lambda Makes Sense
Lambda is a strong fit when:
- Traffic is unpredictable or bursty and you want to avoid paying for idle capacity.
- Individual units of work are discrete, short-lived, and can be modeled as event-driven functions.
- Your team wants to minimize operational overhead and focus on application logic.
- You are building event-driven pipelines: file processing, stream processing, webhook handlers, or scheduled tasks.
Lambda is a poor fit when:
- Workloads run continuously or require execution times longer than 15 minutes.
- Latency requirements are extremely tight and cold starts cannot be tolerated even with Provisioned Concurrency.
- You need persistent local state or low-level OS control.
- Existing applications are tightly coupled to long-lived server processes.
Watch: Getting Started with AWS Lambda
Summary
Serverless computing—and AWS Lambda in particular—represents a genuine shift in how applications are built and operated. By delegating infrastructure management entirely to AWS, teams can ship features faster and pay only for the compute they actually use. However, Lambda’s constraints around execution time, statelessness, cold starts, and native dependencies require deliberate architectural decisions. Understanding these trade-offs upfront is the difference between a successful serverless migration and a painful one.