AWS Lambda is the function as a service offering of Amazon Web Services: it runs code in response to events without requiring the user to provision or manage servers, and it bills per request and per millisecond of execution. In serverless computing, it is the reference implementation of the model, in which the cloud provider handles capacity, scaling, patching and availability.
A Lambda function is a unit of code with a handler, a runtime, a memory setting and an execution role. It stays dormant until an event source invokes it, for example an HTTP request through API Gateway, a file upload to S3, a message in a queue or a scheduled rule. Lambda then creates or reuses an isolated execution environment, runs the handler and scales out automatically as events arrive.
How AWS Lambda runs a function
Each invocation runs inside an execution environment, a lightweight micro virtual machine built on the Firecracker hypervisor. The environment holds the runtime, the function code, its layers and a writable /tmp directory. One environment processes one request at a time; when more requests arrive concurrently, Lambda starts additional environments.
The environment lifecycle has three phases: init, in which the runtime starts and code outside the handler runs; invoke, in which the handler processes an event; and shutdown. After an invocation, the environment is kept warm for reuse, so later requests skip the init phase. A request that must wait for a new environment experiences a cold start, which is the main latency trade-off of the platform.
| Invocation type | Typical sources | Error handling |
|---|---|---|
| Synchronous | API Gateway, function URLs, direct SDK calls | Caller receives the error and decides to retry |
| Asynchronous | S3 events, SNS, EventBridge | Lambda retries up to two times, then a failure destination |
| Event source mapping | SQS, Kinesis, DynamoDB Streams, Kafka | Lambda polls in batches and retries by batch |
Configuration limits and parameters
Lambda exposes few settings, but each has direct effects on performance and cost. Memory is the main performance knob: CPU power is allocated in proportion to memory, reaching roughly one full vCPU at about 1,769 MB and up to six vCPUs at the maximum.
| Parameter | Range or limit | What it affects |
|---|---|---|
| Memory | 128 MB to 10,240 MB | CPU share, network throughput and price |
| Timeout | Up to 900 seconds (15 minutes) | Maximum duration of one invocation |
| Ephemeral storage | 512 MB default, up to 10,240 MB | Space in /tmp for temporary files |
| Deployment package | 250 MB unzipped, or 10 GB as a container image | Code size and dependencies |
| Synchronous payload | 6 MB request and response | Size of data passed directly |
| Concurrency | Account quota per region, commonly 1,000 by default | How many environments run at once |
Two options reduce cold start impact. Provisioned concurrency keeps a fixed number of environments initialized at an extra hourly charge. SnapStart takes a snapshot of an initialized environment and restores it on demand, which helps runtimes with long startup times. Reserved concurrency does the opposite of scaling up: it caps a function so it cannot exhaust a downstream database or the account quota.
AWS Lambda compared with other compute options
Lambda is one point on a spectrum between full control and full abstraction. The right choice depends on request duration, traffic shape and how much operational work the team accepts.
| Option | Unit of deployment | Scaling | Best suited for |
|---|---|---|---|
| AWS Lambda | Function or container image | Per request, automatic | Event-driven and spiky workloads |
| Fargate containers | Container task | Per task, rule-based | Long-running services without server management |
| EC2 instances | Virtual machine | Autoscaling groups | Steady load and full operating system control |
| Step Functions | State machine of steps | Per execution | Coordinating several functions and retries |
At high and constant utilization, per-request pricing can exceed the cost of always-on containers or instances. Lambda tends to be most economical when traffic is irregular, idle periods are long or the workload is a burst of parallel jobs.
Designing functions well
Good Lambda design keeps handlers small, stateless and idempotent. Any state that must survive an invocation belongs in an external service such as DynamoDB, S3 or a cache, because an environment can be discarded at any time.
- Initialize clients outside the handler so warm invocations reuse connections.
- Make handlers idempotent, because asynchronous and stream sources deliver events at least once.
- Grant least-privilege execution roles scoped to the exact resources each function needs.
- Tune memory with measurements, since more memory often shortens duration enough to lower the bill.
- Use RDS Proxy or a pooled connection layer when many functions access a relational database.
Limitations and failure modes
Most production incidents with Lambda come from interaction with other systems, not from the service itself. The table lists the most frequent problems and their usual remedies.
| Symptom | Likely cause | Typical fix |
|---|---|---|
| Occasional slow responses | Cold starts after scale-out or idle periods | Smaller packages, SnapStart or provisioned concurrency |
| Throttling errors | Concurrency quota exhausted | Reserved concurrency per function or a quota increase |
| Database connection exhaustion | Each environment opens its own connections | Connection proxy and reserved concurrency limits |
| Duplicate processing | At-least-once delivery and retries | Idempotency keys stored in a table |
| Tasks cut off mid-way | Work exceeds the 15-minute timeout | Split into steps or move to containers |
Functions running inside a VPC can reach private resources, but they need a NAT gateway or VPC endpoints to call public AWS APIs. Forgetting this is a classic cause of functions that time out silently after deployment.
Stripped to the essentials
AWS Lambda lets developers upload a piece of code and have Amazon run it only when something happens, such as a customer uploading a photo or a website receiving a request. There is no server to install, update or keep running.
It works like a taxi instead of a privately owned car. The user pays only for the trips actually taken, and when many people need a ride at once, more taxis appear automatically. The trade-off is that the first ride after a quiet period may take a moment to arrive.
Where it is applied
A real estate platform lets agents upload property photos, often hundreds at once after a viewing. Each upload to an S3 bucket triggers a Lambda function with 1,536 MB of memory that creates three resized versions and a watermarked copy, then records the results in a database table.
On quiet days the function runs a few dozen times; after a busy weekend it processes tens of thousands of images within minutes as Lambda scales out in parallel. Reserved concurrency of 200 protects the database from overload. The company runs no image servers at all and pays only for the seconds of processing actually used.