AWS Services
AWS Lambda
Understand Lambda as event-driven serverless compute, including functions, triggers, execution roles, concurrency, cold starts, retries, and exam signals.
After this, you will understand
Lambda makes serverless useful when learners understand the event model, execution limits, permissions, retries, and concurrency boundaries.
Lambda runs code in response to events without you managing servers.
Learners treat Lambda like an always-running server and miss cold starts, timeouts, concurrency, event source behavior, and idempotency.
Use Lambda for event-driven units of work, then design permissions, retries, batch handling, observability, and concurrency controls around it.
Think before readingWhy does idempotency matter so much with Lambda event processing?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Serverless compute
- Lambda functions
- Event sources
- Execution roles
- Resource-based permissions
- Event source mappings
- Concurrency
- Cold starts
- Retries and dead-letter behavior
- CloudWatch Logs and metrics
1. Plain-English Mental Model
AWS Lambda is event-driven serverless compute.
You upload code, configure runtime, memory, timeout, permissions, and event sources. AWS runs the code when it is invoked. You do not manage servers, operating systems, host patches, or instance fleets.
The simple model is:
event -> Lambda function -> result or side effect
Events can come from API Gateway, S3, EventBridge, SQS, SNS, DynamoDB Streams, Kinesis, direct SDK invocation, and many other integrations.
Lambda is not a tiny EC2 instance you keep running. It is a function execution environment that scales with invocations, subject to limits, concurrency, event source behavior, cold starts, and timeout constraints.
2. Why This Service Exists
Many workloads do not need always-on servers.
Image processing happens when an object lands in S3. A webhook handler runs when an HTTP request arrives. A scheduled cleanup job runs once per hour. A queue consumer runs when work exists. A DynamoDB stream processor runs when table items change.
Before Lambda, teams often kept servers running just to wait for occasional events. That adds patching, scaling, deployment, capacity planning, and idle cost.
Lambda exists so teams can run code in response to events with less infrastructure management.
For SAA-C03, Lambda appears in questions about low operational overhead, event-driven processing, serverless APIs, S3 event processing, SQS consumers, DynamoDB Streams, scheduled tasks, short-running background jobs, and glue code between AWS services.
3. The Naive Approach And Where It Breaks
The naive Lambda design treats a function like a normal server process.
That breaks because Lambda has execution time limits, memory settings, deployment package limits, concurrency behavior, and event source-specific retry semantics. It may be started fresh after idle time. It should not rely on local disk as durable storage. It should not assume one execution environment exists forever.
Another naive mistake is ignoring duplicate events. Many event sources use at-least-once delivery. The same event may be processed again after timeout, error, or retry.
Another mistake is granting the function broad IAM permissions because "it is just a small function." Lambda functions often sit near sensitive event paths, so execution roles must be scoped.
Lambda reduces server management. It does not remove architecture design.
4. Core Primitives
A function is the deployed code and configuration.
An execution role is the IAM role the function assumes when it runs. It controls what AWS APIs the function can call.
An event source invokes the function. Some services push events to Lambda. Others, such as SQS, Kinesis, and DynamoDB Streams, use event source mappings where Lambda polls the source and invokes the function with batches.
Concurrency is the number of function instances processing events at the same time. Reserved concurrency can cap or reserve capacity for a function. Provisioned concurrency keeps environments initialized for latency-sensitive workloads.
Timeout controls maximum execution duration. Memory setting also influences CPU allocation.
CloudWatch Logs receives function logs. CloudWatch metrics track invocations, errors, duration, throttles, and concurrency.
5. Architecture Use Cases
Use Lambda for event-driven tasks: image resizing after S3 upload, API handlers behind API Gateway, scheduled jobs through EventBridge, queue consumers from SQS, stream processing from DynamoDB Streams, lightweight ETL, notifications, and automation.
Use Lambda with SQS when work should be buffered and retried. The queue absorbs spikes, and Lambda consumes messages.
Use Lambda with SNS when one published message should trigger one or more subscribed functions or queues.
Use Lambda with DynamoDB Streams to react to item changes.
Use Lambda for glue code between managed services when running a full service would be unnecessary.
Do not force long-running compute, stable socket servers, or heavy stateful applications into Lambda if another compute service fits better.
7. Security Model
Lambda uses IAM in two directions.
The execution role defines what the function can do. For example, a function may write to one DynamoDB table and one CloudWatch log group.
Resource-based policies define who can invoke the function in some cases, such as S3, SNS, EventBridge, API Gateway, or cross-account invocation.
Environment variables can hold configuration, but secrets should usually come from Secrets Manager or Parameter Store and be protected with KMS.
If a Lambda function runs inside a VPC, security groups and subnet placement affect network access. VPC access is needed for private resources such as RDS in private subnets, but not for normal access to public AWS APIs.
Do not grant administrator permissions to function roles.
8. Reliability And Resilience
Lambda scales automatically, but reliability depends on event source behavior.
Synchronous invocations return errors directly to callers. Asynchronous invocations can retry and can send failed events to destinations or dead-letter queues depending on configuration.
SQS event source mappings retry messages by returning them to the queue after visibility timeout. Poison messages should eventually move to a dead-letter queue.
Handlers should be idempotent because events can be delivered more than once.
Concurrency limits can throttle functions. Reserved concurrency can protect downstream systems or guarantee capacity for critical functions.
Use timeouts carefully. A timeout that is too low causes retries. A timeout that is too high can hide stuck work and consume concurrency.
9. Performance And Scaling
Lambda scales with invocations and event source configuration.
Cold starts can add latency when a new execution environment is initialized. Provisioned concurrency can reduce cold start impact for latency-sensitive paths.
Memory configuration affects CPU and network performance. More memory can sometimes reduce duration enough to offset cost.
Batch size matters for SQS, Kinesis, and DynamoDB Streams. Larger batches can improve throughput but increase retry blast radius if the whole batch fails.
Downstream services can become bottlenecks. Lambda can scale faster than an RDS database can accept connections, so use pooling patterns, RDS Proxy, throttling, or concurrency limits when needed.
10. Cost Model
Lambda cost depends on requests, duration, memory size, architecture, provisioned concurrency, and related services.
It can be cost-effective for spiky or intermittent workloads because you do not pay for idle servers.
It can be expensive for always-running high-throughput workloads or long-running jobs where containers or EC2 are more efficient.
Logs, retries, API Gateway, SQS, data transfer, and other integration costs are part of the full architecture.
Optimizing Lambda cost often means reducing duration, choosing appropriate memory, avoiding runaway retries, and controlling log volume.
12. SAA-C03 Exam Signals
"Run code without provisioning servers" points to Lambda.
"Trigger processing when an S3 object is uploaded" points to S3 event notification and Lambda.
"Process SQS messages with automatic scaling" points to Lambda event source mapping.
"Need long-running workload over Lambda timeout" points away from Lambda.
"Function needs AWS API access" points to execution role.
"Duplicate events possible" points to idempotency.
"Reduce cold start latency" may point to provisioned concurrency.
13. Common Exam Traps
Do not use Lambda for workloads that exceed timeout limits.
Do not assume exactly-once processing. Design for retries and duplicates.
Do not put a Lambda function in a VPC just to access AWS public APIs.
Do not grant broad IAM permissions to every function.
Do not ignore downstream capacity. Lambda scaling can overload databases.
Do not store durable state in the function's local temporary storage.
15. Related Topics
Review Amazon SQS, Amazon SNS, Amazon CloudWatch, and IAM Foundations.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.