Introduction
Amazon Web Services Lambda, commonly written as AWS Lambda, is a serverless compute service. The term serverless describes a model in which the underlying servers are provisioned, scaled, and maintained by the cloud provider, and the customer is charged only for the compute that is actually consumed. The term compute refers to the processing capacity that is used to run application code. This guide explains what AWS Lambda is, the problem it was created to solve, how it operates internally, and the situations in which its use is and is not appropriate.
What is it?
AWS Lambda is a service on which code is run in response to events, without any server being provisioned or managed by the developer. A single unit of deployed code is called a function. A function is executed only when it is triggered by an event, which is a structured message that describes something that has happened, for example an HTTP request arriving at an endpoint or a file being uploaded to storage. When no events are being processed, no function instances are run and no charge is incurred.
Because the developer supplies only the function code and its configuration, the responsibility for the operating system, the servers, and the scaling of capacity is transferred to AWS. The developer is left to focus on the logic of the function itself.
Why does it exist?
Before serverless compute became widely available, application code was typically run on servers that had to be arranged in advance. A server had to be sized for peak demand, kept running continuously, patched for security, and paid for even while it remained idle. Scaling was performed manually or through additional configuration, and a sudden increase in traffic could overwhelm a fixed set of servers.
AWS Lambda was created to remove this operational burden. Capacity is allocated automatically as demand rises and is released as demand falls. Billing is based on the number of requests and the duration of each execution rather than on reserved server time. As a result, small workloads can be run at very low cost, and large workloads can be scaled without capacity being planned in advance.
How it works
When an event is delivered to Lambda, an execution environment for the corresponding function is located or created. An execution environment is an isolated, temporary container that holds the language runtime and the function code. A runtime is the software that interprets and runs code written in a particular language, such as Node.js, Python, or Java. The function code contains a handler, which is the specific method that Lambda calls and to which the event is passed.
If a warm execution environment is already available, the handler is invoked immediately. If no environment is available, a new one is initialized first. This initialization step is known as a cold start, and it adds delay to the first invocation. This delay is referred to as latency, which is the time that passes between a request being made and a response being produced.
Scaling is achieved by many execution environments being run in parallel. The number of environments that are active at the same moment is called concurrency. If one thousand events arrive at once, up to one thousand environments may be run concurrently, subject to the limits that have been configured for the account. Each function is billed according to the number of invocations and the total execution duration, which is measured in milliseconds and multiplied by the amount of memory that has been allocated.
Architecture diagram
The relationship between an event source, the Lambda service, and the downstream services that a function calls is shown below. An event source is any service or client that produces the events that trigger a function.
Advantages
- No server management. Provisioning, patching, and capacity planning are handled by AWS.
- Automatic scaling. Capacity is matched to demand, from a single request to many thousands of concurrent requests.
- Pay for use. Charges apply only while code is running, so idle capacity is not paid for.
- Deep event integration. Functions can be triggered directly by many AWS services, which reduces the amount of connecting code that must be written.
- Fast iteration. Small, independent functions can be deployed and updated quickly.
Disadvantages
- Cold start latency. The first invocation into a new environment is slower, which may matter for latency-sensitive workloads.
- Execution time limit. A single invocation may run for a maximum of fifteen minutes, so long-running work must be restructured.
- Statelessness. No state is guaranteed to persist between invocations, so data that must be retained has to be written to an external store.
- Resource limits. Memory, temporary storage, and package size are bounded, which can constrain heavy workloads.
- Distributed complexity. A system that is composed of many small functions can be harder to trace and reason about than a single application.
Common use cases
- Web and mobile backends, in which requests are received through Amazon API Gateway and processed by functions.
- File processing, in which a function is triggered when an object is uploaded to Amazon Simple Storage Service, known as Amazon S3.
- Stream processing, in which records from a data stream are processed as they arrive.
- Scheduled tasks, in which a function is run on a fixed schedule to perform maintenance or reporting.
- Event-driven integration, in which functions connect services together in response to events.
Best practices
- Each function should be given a single, clearly defined responsibility.
- Deployment packages should be kept small so that initialization remains fast.
- Connections to databases and other services should be created outside the handler so that they can be reused across invocations.
- Memory should be sized appropriately, because processing power is allocated in proportion to memory.
- A least-privilege permission policy should be applied. Least privilege is the practice of granting only the permissions that are strictly required. Permissions in AWS are managed through Identity and Access Management, known as IAM.
- Operations that may be retried should be made idempotent, which means that repeating the same operation produces the same result and causes no additional side effects.
- Logs and metrics should be collected through Amazon CloudWatch, the AWS monitoring service, so that behavior can be observed and problems diagnosed.
Common mistakes
- Long-running or continuously busy work is placed in a function that is better suited to a container or server-based service.
- Retries are not accounted for, so duplicate events cause duplicated effects.
- Overly broad permissions are granted, which increases the security risk if a function is compromised.
- Cold starts are ignored on paths where low and predictable latency is required.
- A function is placed inside a private network, known as a Virtual Private Cloud or VPC, when it does not need to be, which can add configuration and, in some cases, additional start-up delay.
Related AWS services
AWS Lambda is rarely used in isolation. It is most often combined with the services below. Dedicated guides for each are being added to this library.
- Amazon API Gateway receives HTTP requests and forwards them to functions, which allows an application programming interface, known as an API, to be served without a server.
- Amazon DynamoDB is a managed database in which data that must persist between invocations can be stored.
- Amazon EventBridge routes events between services and can trigger functions.
- AWS Step Functions coordinates multiple functions into a reliable workflow and is well suited to work that exceeds the fifteen-minute limit.
- Amazon Cognito provides authentication so that the identity of a caller can be verified before a function is run.
- Amazon CloudWatch collects the logs and metrics that a function produces.
Frequently Asked Questions
- Which programming languages are supported by AWS Lambda?
- AWS Lambda provides managed runtimes for Node.js, Python, Java, .NET, Go, and Ruby. Languages that are not provided as managed runtimes can be supported through a custom runtime or a container image.
- How is AWS Lambda priced?
- Charges are based on the number of requests and on the duration of each execution. Duration is measured in milliseconds and is multiplied by the amount of memory that is allocated. When no events are being processed, no charge is incurred.
- What is a cold start, and how can it be reduced?
- A cold start is the additional delay that occurs when a new execution environment must be initialized because no warm environment is available. It can be reduced by keeping deployment packages small, by choosing a runtime that initializes quickly, and, for latency-sensitive workloads, by using provisioned concurrency, which keeps a number of environments initialized in advance.
- What is the maximum execution time of a Lambda function?
- A single invocation may run for a maximum of fifteen minutes. Work that is expected to exceed this limit should be divided into smaller steps or coordinated by AWS Step Functions.
- Is AWS Lambda always the cheapest option?
- No. For intermittent or unpredictable workloads, Lambda is often the most cost-effective choice. For workloads that run continuously at high, steady volume, a container or server-based service may be less expensive.
This article is the summary. The book is the full, continuously updated reference: production patterns, security, cost control, and complete architectures for Lambda and the wider serverless stack.
View the book