Visual overview
An event source invokes code; CloudWatch receives operational telemetry.
Technical reference
Serverless still has technical parameters. Memory affects CPU allocation; timeout bounds an invocation.
Configured in 1 MB increments; CPU power is allocated proportionally to memory.
AWS documents proportional CPU allocation at this reference point.
One invocation can run for at most the configured timeout; 900 seconds is 15 minutes.
Reserved and provisioned concurrency address different capacity and latency controls.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
Compute without managing servers
AWS Lambda runs code in response to events or direct invocations without requiring the customer to provision or manage a server fleet. You package function code, select runtime and resource configuration, assign permissions, and connect the function to event sources or callers. Lambda manages execution environments, infrastructure scaling, routing and fault tolerance beneath that function abstraction.
The serverless label does not mean that servers stop existing; it means server lifecycle and capacity management are moved behind the service boundary. That changes the operational unit from 'a machine that stays running' to 'a function that is invoked when work arrives.' This is a strong fit for event processing, lightweight APIs, automation, asynchronous workflows and integrations where work naturally arrives as discrete requests or events.
Invocations, execution environments and concurrency
A Lambda invocation is one request to run a function. AWS creates and reuses execution environments to process invocations. Reuse can improve performance, but code must not depend on in-memory state persisting between separate invocations. Durable application state belongs in an external service such as a database or object store, while local temporary storage is best treated as execution-scoped or opportunistic cache state according to the function design.
Concurrency represents the number of function invocations being processed at the same time. Lambda can create additional execution environments as concurrent demand grows, subject to quotas and configured concurrency controls. Reserved concurrency can protect or cap a function's share of concurrency; provisioned concurrency can keep initialized environments ready when latency requirements justify the additional cost. Scaling behavior should therefore be designed alongside downstream limits so a rapidly scaling function does not overwhelm a database or third-party dependency.
Events and integration patterns
Lambda integrates with a broad set of AWS services. An API can invoke a function synchronously; Amazon S3 can trigger processing after object events; Amazon SQS can supply queued messages; EventBridge can route events; streams can be processed in batches. The invocation model differs by integration, so retry behavior, ordering, batching and failure handling should be designed for the actual event source rather than assumed to be identical everywhere.
Event-driven systems should be idempotent where duplicate processing is possible, observable through logs and metrics, and explicit about failure destinations or retries. Lambda reduces infrastructure operations, but application correctness still requires careful design around permissions, downstream capacity, timeouts, error paths and event semantics.
Cost and service boundaries
Lambda pricing is consumption-oriented and includes dimensions such as requests and execution duration according to the selected resources and architecture. This can be economical for intermittent or bursty event-driven work because there is no need to keep a general-purpose server fleet running solely to wait for requests. High, continuous utilization can change the cost comparison, so architecture should be evaluated using real traffic and performance requirements.
Lambda is intentionally constrained compared with EC2. It is not the right default for every long-running process, software package, custom operating-system dependency or specialized host requirement. Containers or EC2 may fit better when execution needs a different lifecycle or infrastructure control. Conversely, choosing EC2 for a small event handler can create unnecessary patching, capacity and availability work that Lambda already abstracts.
Key takeaways
- 01
Lambda runs event-driven function code while AWS manages the underlying servers and execution infrastructure.
- 02
Concurrency measures simultaneous executions; scaling should account for quotas and downstream system capacity.
- 03
Function code should not depend on execution-environment memory persisting across invocations.
- 04
Choose Lambda when the event-driven function abstraction matches the workload, not simply because 'serverless' is desirable.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.