Lambda

Lambda Durable Functions – Stateful Serverless

~ Last updated on : ~ Kiro Agent

📢 New Service – Announced at re:Invent 2025

AWS Lambda Durable Functions were announced at re:Invent 2025 (December 2025) and are now generally available across ~31 AWS Regions as of mid-2026. They support Python, JavaScript/TypeScript, and Java runtimes.

Certification Relevance: DVA-C02 (Developer Associate), SAA-C03 (Solutions Architect Associate) — expect questions on choosing between Durable Functions, Step Functions, and SQS+Lambda patterns.

What are AWS Lambda Durable Functions?

  • Lambda Durable Functions extend the Lambda programming model to build fault-tolerant, multi-step, stateful applications and AI workflows using familiar programming languages.
  • They enable multi-step coordination without idle compute costs — functions can suspend execution (wait) for up to one year without incurring compute charges.
  • Durable Functions use a checkpoint and replay mechanism (durable execution) to track progress, automatically recover from failures, and resume from where they left off.
  • You write sequential code in your preferred language (Python, JavaScript/TypeScript, Java), and the SDK handles state management, retries, and orchestration transparently.
  • Durable execution must be enabled at function creation time — it cannot be added to existing Lambda functions.
  • The open-source AWS Durable Execution SDK provides the primitives (steps, waits, callbacks, parallel, map) needed to build resilient workflows.
Lambda Durable Functions — Checkpoint/Replay
Step 1
Validate Order
→
Step 2
Charge Payment
→
⏸ Wait
Human Approval
(up to 1 year)
→
Step 3
Ship Order
→
✅ Done
💾 State checkpointed after each step —
💰 No charge during waits

Architecture – Checkpoint and Replay Pattern

  • Orchestrator Pattern: A durable function acts as an orchestrator that coordinates multiple steps in a workflow using sequential code.
  • Durable Execution: The complete lifecycle of a durable function run — from start to completion — is called a durable execution.
  • Checkpointing: Each durable operation (step, wait) creates a checkpoint that records the result. Progress is persisted automatically.
  • Replay: When execution resumes after a pause or failure, the function replays from the beginning, skipping completed checkpoints using stored results instead of re-executing them.
  • Sub-invocations: A single durable execution may involve multiple Lambda invocations (sub-invocations) — the initial invocation plus resumptions after waits, retries, or infrastructure failures.
  • Determinism Requirement: Code between durable operations must be deterministic — the replay mechanism depends on consistent execution paths across replays.

Core Primitives (Durable Operations)

  • Steps (context.step()) — Execute business logic with built-in retries and automatic checkpointing. Once completed, steps are skipped during replay.
  • Waits (context.wait()) — Suspend execution for a specified duration (seconds to one year). The function terminates and does not incur compute charges during the wait.
  • Callbacks (context.create_callback()) — Pause execution until an external event (API call, human approval) signals completion via the Lambda API.
  • Wait for Condition (context.wait_for_condition()) — Suspend until a specific condition is met, such as polling a REST API for process completion.
  • Parallel (context.parallel()) — Execute different independent operations concurrently.
  • Map (context.map()) — Apply the same operation to every item in a collection concurrently (fan-out/fan-in).

How It Works – Flow

  1. Create a Lambda function with durable execution enabled at creation time.
  2. Add the Durable Execution SDK to your function code.
  3. Wrap your handler with @durable_execution decorator (Python) or equivalent.
  4. Use context.step() for business logic with automatic checkpointing and retries.
  5. Use context.wait() or context.create_callback() to suspend execution without compute charges.
  6. On resume, the SDK replays from the beginning, skipping completed steps using stored results.
  7. Monitor execution progress in the Lambda console Durable executions tab.

Key Features

Automatic State Persistence

  • Every durable operation automatically checkpoints its result to durable storage.
  • No need to manually manage state in DynamoDB, S3, or external databases.
  • State is retained for a configurable period (1–90 days, default 14 days) after execution completes.
  • Execution history is available via the GetDurableExecutionHistory API for debugging and auditing.

Exactly-Once Execution Semantics

  • Steps that complete successfully are never re-executed during replay — their stored results are used instead.
  • Built-in idempotency: invoking a function twice with the same execution name returns the existing execution result instead of creating a duplicate.
  • Configurable retry strategies with max attempts, backoff rate, and custom error handling per step.

Timer and Wait Support

  • Waits can suspend execution from seconds up to one year (max ExecutionTimeout: 31,622,400 seconds).
  • During wait operations, on-demand functions do not incur compute charges — you only pay for storage.
  • Ideal for scheduled delays, polling intervals, and time-based business rules.

Human Approval Workflows

  • Callbacks allow execution to pause until an external system (or human) signals completion.
  • External systems call SendDurableExecutionCallbackSuccess or SendDurableExecutionCallbackFailure APIs.
  • Callbacks support configurable timeouts — if no response within the timeout, execution can handle the timeout gracefully.
  • Can be sent directly from the Lambda console for testing.

Sub-Orchestrations and Concurrency

  • Parallel: Execute different independent tasks concurrently and collect results.
  • Map: Fan-out the same operation across a collection of items and fan-in the results.
  • Child contexts: Compose complex workflows from smaller, reusable durable function patterns.
  • All concurrent operations are checkpointed and replayed correctly.

EventBridge Integration

  • Lambda automatically sends Durable Execution Status Change events to the default EventBridge bus.
  • Build downstream workflows, notifications, or monitoring based on execution state changes.
  • Event source: aws.lambda, detail-type: Durable Execution Status Change.

Lambda Versions for Safe Deployments

  • Use Lambda versions to ensure replay always happens on the same code version that started the execution.
  • Prevents inconsistencies from code changes during long-running workflows.
  • Critical for production deployments where executions may be suspended for days or weeks.

Lambda Durable Functions vs Step Functions

Feature Lambda Durable Functions AWS Step Functions
Primary Focus Application development within Lambda Workflow orchestration across AWS services
Service Type Runs within Lambda Standalone, dedicated workflow service
Programming Model Standard languages (Python, JS/TS, Java) Amazon States Language (ASL) / Visual Designer
Development Tools IDE, LLM agents, unit test frameworks, SAM, CDK Visual Workflow Builder, CDK, Toolkit
AWS Integrations Lambda event sources 220+ AWS services, 16,000+ APIs natively
Max Execution Duration Up to 1 year Up to 1 year (Standard Workflows)
Pricing Model Lambda compute + $8/million durable operations + data written + data retention $25/million state transitions (Standard) or per-request (Express)
Wait Cost No compute charges during waits (storage only) No charges during waits
Visual Design No — code-first approach Yes — Workflow Studio visual designer
Stakeholder Visibility Requires code reading Visual graph for non-technical stakeholders
Infrastructure Management Managed within Lambda (SDK updates needed) Fully managed, zero maintenance
Best For Distributed transactions, stateful app logic, AI workflows Business process automation, multi-service orchestration

When to Use Lambda Durable Functions

  • Your team prefers writing workflows in standard programming languages.
  • Application logic is primarily within Lambda functions (Lambda-centric).
  • You want fine-grained control over execution state in code.
  • Business logic and workflow are tightly coupled.
  • You want to iterate quickly without switching between code and visual/JSON designers.
  • You’re building AI agent orchestration that requires code-level control.

When to Use Step Functions

  • You need visual workflow representation for cross-team visibility.
  • You’re orchestrating multiple AWS services and want native integrations without custom SDK code.
  • Non-technical stakeholders need to understand and validate workflow logic.
  • You want fully managed, zero-maintenance infrastructure (no patching, runtime updates, SDK bundling).
  • You need integration with 220+ AWS services without writing Lambda functions for each.

Hybrid Architectures

  • Many applications benefit from using both services together.
  • Common pattern: Use durable functions for application-level logic within Lambda, while Step Functions coordinates high-level workflows across multiple AWS services.
  • Start with durable functions for Lambda-centric workflows; add Step Functions when multi-service orchestration is needed.

Lambda Durable Functions vs SQS + Lambda Pattern

Aspect Lambda Durable Functions SQS + Lambda
State Management Automatic via SDK checkpoints Manual (DynamoDB, S3, or message attributes)
Error Handling Built-in retries, automatic recovery Dead-letter queues, manual retry logic
Workflow Visibility Execution history in Lambda console CloudWatch logs, custom tracing
Long Waits Native wait up to 1 year, no compute cost SQS delay (max 15 min), needs workarounds
Ordering Sequential by default, parallel when needed FIFO queues or custom ordering
Code Complexity Single function, sequential code Multiple functions, queue config, DLQ setup
Idempotency Built-in via execution names Must implement manually
Best For Multi-step workflows, long-running processes Decoupled event-driven processing, high throughput message processing

Use Cases

Saga Pattern (Distributed Transactions)

  • Coordinate payments, inventory, and shipping across multiple services with automatic rollback on failures.
  • Each step is checkpointed — if a later step fails, compensating actions can be triggered for earlier steps.
  • Example: Order processing → Payment authorization → Inventory allocation → Fulfillment, with compensation logic.

Human Approval Workflows

  • Suspend execution waiting for human decisions (loan approvals, expense reports, content moderation).
  • Use callbacks to pause for days or weeks without compute charges.
  • External approval systems call the Lambda API to resume execution with approval/rejection results.

Fan-Out / Fan-In

  • Use map() to process a collection of items concurrently (e.g., batch image processing, parallel API calls).
  • Use parallel() for different independent tasks that must all complete before proceeding.
  • Results are automatically collected and available after all concurrent operations complete.

Long-Running Processes

  • Employee onboarding workflows spanning days or weeks (account creation → training assignments → equipment provisioning → check-ins).
  • Insurance claim processing with document analysis, human review (7+ days), and payment processing.
  • Compliance workflows with scheduled checks and waiting periods.

AI Agent Orchestration

  • Chain multiple LLM calls with intermediate processing, human feedback loops, and tool use.
  • Build multi-agent workflows where agents collaborate asynchronously.
  • Integrate with Amazon Bedrock for AI-powered analysis steps within durable workflows.
  • Handle long-running AI tasks (model training jobs, batch inference) with wait-and-resume patterns.

Polling and Condition-Based Workflows

  • Poll external APIs or systems until a condition is met (e.g., payment settlement, third-party processing).
  • Use wait_for_condition() to efficiently check conditions at intervals without continuous compute.

Pricing

  • Pay only for active compute: During wait operations, on-demand functions suspend and do not incur duration charges.
  • Standard Lambda charges apply: Requests ($0.20/million) and compute duration (per GB-second) for active execution time, including sub-invocations from replays.
  • Durable Operations: $8.00 per million operations (start execution, complete step, create wait, etc.).
  • Data Written: $0.25 per GB of data written by durable operations (step results, invocation payloads).
  • Data Retention: $0.15 per GB-month for data stored during execution and after completion (configurable 1–90 days, default 14 days, prorated).
  • Free Tier: Standard Lambda free tier (1M requests + 400,000 GB-seconds) applies to the compute portion.

Pricing Example

  • 1 million claims processed/month, each with: 30s analysis step + 7-day human review wait + 2s payment step.
  • Compute: ~$421 (32M GB-seconds at 1GB memory).
  • Durable Operations: $32 (4M operations — 1 start + 2 steps + 1 wait per execution).
  • Data Written: $26 (104GB at $0.25/GB).
  • Data Retention: ~$11 (during wait + 14-day post-completion retention).
  • Total: ~$490/month for 1M executions with 7-day waits — no compute charges during the wait period.

Limitations

  • Immutable configuration: Durable execution can only be enabled at function creation time — cannot be added to or removed from existing functions.
  • Language support: Currently supports Python (3.13/3.14), JavaScript/TypeScript (Node.js 22/24), and Java. No support for Go, .NET, or Ruby as of mid-2026.
  • Determinism requirement: Code between durable operations must be deterministic — no random values, timestamps, or non-deterministic API calls outside of steps.
  • SDK dependency: Requires bundling the open-source Durable Execution SDK with your function code and managing SDK version updates.
  • Max execution timeout: 31,622,400 seconds (~1 year). Executions exceeding this are terminated.
  • Retention period: Execution history retained 1–90 days after completion (default 14 days).
  • State size: Large state objects increase storage costs and can impact replay performance. Keep state minimal.
  • Replay overhead: On resume, the entire handler replays from the beginning (skipping completed steps). Complex workflows with many steps incur replay compute costs.
  • No visual designer: Unlike Step Functions, there is no graphical workflow builder — code-only approach.
  • Cold starts: Each sub-invocation (resume) is subject to normal Lambda cold start behavior.

Supported Runtimes and Availability

  • Languages: Python 3.13/3.14, Node.js 22/24 (JavaScript/TypeScript), Java (bundled SDK).
  • Regions: Available in ~31 AWS Regions as of mid-2026.
  • SDK: Open source — Python SDK, JavaScript/TypeScript SDK.
  • IaC Support: AWS CloudFormation, AWS SAM, AWS CDK.
  • Testing: Local testing SDK available (pytest integration) + AWS SAM CLI for integration testing.

AWS Certification Exam Relevance

DVA-C02 (Developer Associate)

  • Understand when to use Durable Functions vs Step Functions vs SQS+Lambda.
  • Know the checkpoint/replay mechanism and determinism requirements.
  • Understand durable operations: steps, waits, callbacks, parallel, map.
  • Know that durable execution must be enabled at creation time.
  • Understand idempotency via execution names.

SAA-C03 (Solutions Architect Associate)

  • Architecture decisions: choosing the right orchestration service for workflow requirements.
  • Cost optimization: no compute charges during waits vs Step Functions pricing model.
  • Use case mapping: saga pattern, approval workflows, long-running processes.
  • Hybrid architectures: combining Durable Functions with Step Functions.

Practice Questions

Question 1

A company needs to build an order processing workflow that coordinates payment authorization, inventory allocation, and shipping across three microservices. The workflow must automatically roll back completed steps if a later step fails. The development team prefers writing workflow logic in Python rather than using a visual designer. Which solution meets these requirements with the LEAST operational overhead?

  1. AWS Step Functions with Lambda tasks and error handling states
  2. AWS Lambda durable functions with steps and compensation logic
  3. Amazon SQS queues between Lambda functions with DynamoDB for state tracking
  4. Amazon EventBridge with Lambda targets and Step Functions for rollback
Show Answer

Answer: B –

Lambda durable functions provide automatic state management, built-in retries, and a code-first approach in Python. The saga pattern with compensation logic can be implemented as sequential code with steps and error handling, meeting the requirement for Python-based workflow logic with minimal operational overhead.

Question 2

A healthcare company is building a patient referral system where a referral is submitted, requires physician approval (which may take up to 2 weeks), and then triggers appointment scheduling. The solution must minimize costs during the waiting period. Which approach is MOST cost-effective?

  1. AWS Step Functions Standard Workflow with a Wait state
  2. Lambda function polling DynamoDB every hour using EventBridge Scheduler
  3. AWS Lambda durable functions with a callback that suspends execution until approval
  4. Amazon SQS with a delay queue and Lambda consumer
Show Answer

Answer: C –

Lambda durable functions with callbacks suspend execution without incurring compute charges during the wait. The function resumes only when the physician approval triggers the callback API. This is the most cost-effective approach as there are no compute charges during the 2-week wait — only minimal data retention costs. Step Functions Standard Workflows also don’t charge during waits, but durable functions eliminate the per-state-transition cost for simple workflows.

Question 3

A solutions architect is designing a workflow that coordinates image processing across 10 AWS services including S3, Rekognition, DynamoDB, SNS, and SQS. The workflow needs to be understood by non-technical business stakeholders and must require minimal custom code. Which service is MOST appropriate?

  1. AWS Lambda durable functions with parallel and map operations
  2. AWS Step Functions with native service integrations
  3. Amazon EventBridge Pipes connecting the services
  4. AWS Lambda durable functions with AWS SDK calls in steps
Show Answer

Answer: B –

AWS Step Functions provides native integrations with 220+ AWS services without requiring custom Lambda code, and offers a visual workflow designer that non-technical stakeholders can understand. Lambda durable functions would require writing SDK calls for each service integration and doesn’t provide a visual representation.

Question 4

A developer is implementing a Lambda durable function that processes financial transactions. During testing, the function occasionally produces different results when replayed. What is the MOST likely cause?

  1. The function’s memory configuration is too low for replay operations
  2. The function contains non-deterministic code (random values, timestamps) outside of durable steps
  3. The ExecutionTimeout is configured incorrectly
  4. The function is using an unsupported runtime version
Show Answer

Answer: B –

Lambda durable functions use a replay mechanism that re-executes code from the beginning on resume. Code between durable operations must be deterministic — any non-deterministic operations (random number generation, current timestamps, external API calls) must be wrapped inside context.step() to be checkpointed and skipped during replay.

Question 5

A company wants to add durable execution capabilities to their existing production Lambda function that processes insurance claims. The function currently runs on Python 3.13 and handles 500,000 invocations per day. What should the developer do?

  1. Update the function configuration to enable DurableConfig with the appropriate ExecutionTimeout
  2. Create a new Lambda function with durable execution enabled, migrate the code, and redirect traffic
  3. Add the Durable Execution SDK to the existing function and use the @durable_execution decorator
  4. Enable durable execution on the existing function using the UpdateFunctionConfiguration API
Show Answer

Answer: B –

Durable execution can only be enabled at function creation time — it cannot be added to or modified on existing Lambda functions. The developer must create a new function with durable execution enabled in the DurableConfig, migrate the code to use the Durable Execution SDK, and redirect traffic to the new function.

Frequently Asked Questions

What are AWS Lambda Durable Functions?

Lambda Durable Functions let you build multi-step stateful workflows directly in Lambda code. They automatically checkpoint state, can wait for up to one year for external events, and you only pay for active compute time — not idle waiting.

How do Durable Functions differ from Step Functions?

Durable Functions define workflows in code (Python/Node.js) with inline orchestration logic. Step Functions use a visual designer with JSON/YAML state machine definitions. Use Durable Functions for code-first teams; Step Functions for visual workflows with 200+ service integrations.

Do Durable Functions charge for wait time?

No. Unlike Step Functions which charge per state transition including waits, Durable Functions only charge for active compute. Waiting for a human approval or external event costs nothing beyond state storage.

References

AWS Lambda

~ Last updated on : ~ jayendrapatil ~ 19 Comments

AWS Lambda

  • AWS Lambda offers Serverless computing that allows applications and services to be built and run without thinking about servers.
  • With serverless computing, the application still runs on servers, but all the server management is done by AWS.
  • helps run code without provisioning or managing servers, where you pay only for the compute time when the code is running.
  • is priced on a pay-per-use basis and there are no charges when the code is not running.
  • allows the running of code for any type of application or backend service with zero administration.
  • performs all the operational and administrative activities on your behalf, including capacity provisioning, monitoring fleet health, applying security patches to the underlying compute resources, deploying code, running a web service front end, and monitoring and logging the code.
  • does not provide access to the underlying compute infrastructure.
  • handles scalability and availability as it
    • provides easy scaling and high availability to the code without additional effort on your part.
    • is designed to process events within milliseconds.
    • is designed to run many instances of the functions in parallel.
    • is designed to use replication and redundancy to provide high availability for both the service and the functions it operates.
    • has no maintenance windows or scheduled downtimes for either.
    • has a default safety throttle for the number of concurrent executions per account per region (default 1,000 concurrent executions).
    • scales by 1,000 concurrent executions every 10 seconds until the account’s concurrency limit is reached (12x faster scaling announced Nov 2023).
    • has a higher latency immediately after a function is created, or updated, or if it has not been used recently.
    • for any function updates, there is a brief window of time, less than a minute, when requests would be served by both versions
  • Security
    • stores code in S3 and encrypts it at rest and performs additional integrity checks while the code is in use.
    • each function runs in its own isolated environment, with its own resources and file system view
    • supports Code Signing using AWS Signer, which offers trust and integrity controls that enable you to verify that only unaltered code from approved developers is deployed in the functions.
  • Functions must complete execution within 900 seconds (15 minutes). The default timeout is 3 seconds. The timeout can be set to any value between 1 and 900 seconds.
  • AWS Step Functions can help coordinate a series of Lambda functions in a specific order. Multiple functions can be invoked sequentially, passing the output of one to the other, and/or in parallel, while the state is being maintained by Step Functions.
  • AWS X-Ray helps to trace functions, which provides insights such as service overhead, function init time, and function execution time.
  • Lambda Provisioned Concurrency provides greater control over the performance of serverless applications.
  • Lambda SnapStart reduces cold start latency to sub-second for Java, Python, and .NET functions without code changes or additional cost.
  • Lambda Durable Functions enable multi-step applications and AI workflows with automatic checkpointing, failure recovery, and execution suspension for up to one year.
  • Lambda Managed Instances allow running Lambda functions on EC2 instances with serverless operational simplicity, enabling access to specialized compute and EC2 commitment-based pricing (up to 72% savings).
  • Lambda@Edge allows you to run code across AWS locations globally without provisioning or managing servers, responding to end-users at the lowest network latency.
  • Lambda Extensions allow integration of Lambda with other third-party tools for monitoring, observability, security, and governance.
  • Compute Savings Plan can help save money for Lambda executions.
  • CodePipeline and CodeDeploy can be used to automate the serverless application release process.
  • RDS Proxy provides a highly available database proxy that manages thousands of concurrent connections to relational databases.
  • Supports Elastic File Store, to provide a shared, external, persistent, scalable volume using a fully managed elastic NFS file system without the need for provisioning or capacity management.
  • supports Function URLs, a built-in HTTPS endpoint that can be invoked using the browser, curl, and any HTTP client.
  • supports Response Streaming, allowing functions to send response data to callers as it becomes available, enabling larger payloads and long-running operations with incremental progress reporting.
  • supports Graviton2 (ARM64) architecture, delivering up to 34% better price-performance compared to x86_64 functions.
  • supports configurable ephemeral storage (/tmp) between 512 MB and 10,240 MB (10 GB) for data-intensive workloads.
  • supports up to 10,240 MB (10 GB) of memory with up to 6 vCPUs proportionally allocated.
  • supports asynchronous invocation payload sizes up to 1 MB (increased from 256 KB in Oct 2025).
  • supports Advanced Logging Controls with native JSON structured logging for easier search, filter, and analysis of function logs.
  • supports Recursive Loop Detection that automatically detects and stops recursive invocations between Lambda and supported services (SQS, SNS, S3) to prevent runaway costs.

Functions & Event Sources

  • Core components of Lambda are functions and event sources.
    • Event source – an AWS service or custom application that publishes events.
    • Function – a custom code that processes the events.

Lambda Functions

  • Each function has associated configuration information, such as its name, description, runtime, entry point, and resource requirements
  • Lambda functions should be designed as stateless
    • to allow launching of as many copies of the function as needed as per the demand.
    • Local file system access, child processes, and similar artifacts may not extend beyond the lifetime of the request
    • The state can be maintained externally in DynamoDB or S3
  • Lambda Execution role can be assigned to the function to grant permission to access other resources.
  • Functions have the following restrictions
    • Inbound network connections are blocked
    • Outbound connections only TCP/IP sockets are supported
    • ptrace (debugging) system calls are blocked
    • TCP port 25 traffic is also blocked as an anti-spam measure.
  • Lambda may choose to retain an instance of the function and reuse it to serve a subsequent request, rather than creating a new copy.
  • Lambda Layers provide a convenient way to package libraries and other dependencies that you can use with your Lambda functions.
  • Function versions can be used to manage the deployment of the functions.
  • Function Alias supports creating aliases, which are mutable, for each function version.
  • Functions are automatically monitored, and real-time metrics are reported through CloudWatch, including total requests, latency, error rates, etc.
  • Lambda automatically integrates with CloudWatch logs, creating a log group for each function and providing basic application lifecycle event log entries, including logging the resources consumed for each use of that function.
  • Functions support code written in
    • Node.js (Node.js 22, Node.js 24)
    • Python (Python 3.12, 3.13, 3.14)
    • Java (Java 21, Java 25)
    • C# (.NET 8, .NET 10)
    • Ruby (Ruby 3.3, 3.4, 4.0)
    • Go (using OS-only runtime provided.al2023)
    • Rust (using OS-only runtime provided.al2023)
    • Custom runtime (provided.al2023)
  • Container images are also supported.
  • Supports both x86_64 and arm64 (Graviton2) architectures for all managed runtimes.
  • Failure Handling
    • For S3 bucket notifications and custom events, Lambda will attempt execution of the function three times in the event of an error condition in the code or if a service or resource limit is exceeded.
    • For ordered event sources that Lambda polls, e.g. DynamoDB Streams and Kinesis streams, it will continue attempting execution in the event of a developer code error until the data expires.
    • Kinesis and DynamoDB Streams retain data for a minimum of 24 hours
    • Dead Letter Queues (SNS or SQS) can be configured for events to be placed, once the retry policy for asynchronous invocations is exceeded
    • Lambda Destinations can be configured for successful and failed asynchronous invocations (recommended over DLQ).

Read in-depth @ Lambda Functions

Lambda Event Sources

  • Event Source is an AWS service or developer-created application that produces events that trigger an AWS Lambda function to run
  • Event source mapping refers to the configuration which maps an event source to a Lambda function.
  • Event sources can be both push and pull sources
    • Services like S3, and SNS publish events to Lambda by invoking the cloud function directly.
    • Lambda can also poll resources in services like Kafka, and Kinesis streams that do not publish events to Lambda.

Read in-depth @ Event Sources

Lambda Execution Environment

  • Lambda invokes the function in an execution environment, which provides a secure and isolated runtime environment.
  • Execution Context is a temporary runtime environment that initializes any external dependencies of the Lambda function code, e.g. database connections or HTTP endpoints.
  • When a function is invoked, the Execution environment is launched based on the provided configuration settings i.e. memory and execution time.
  • After a Lambda function is executed, Lambda maintains the execution environment for some time in anticipation of another function invocation which allows it to reuse the /tmp directory and objects declared outside of the function’s handler method e.g. database connection.
  • When a Lambda function is invoked for the first time or after it has been updated there is latency for bootstrapping as Lambda tries to reuse the Execution Context for subsequent invocations of the Lambda function
  • Subsequent invocations perform better performance as there is no need to “cold-start” or initialize those external dependencies
  • Execution environment
    • takes care of provisioning and managing the resources needed to run the function.
    • provides lifecycle support for the function’s runtime and any external extensions associated with the function.
  • Function’s runtime communicates with Lambda using the Runtime API.
  • Extensions communicate with Lambda using the Extensions API.
  • Extensions can also receive log messages from the function by subscribing to logs using the Logs API.
  • Lambda manages Execution Environment creations and deletion, there is no AWS Lambda API to manage Execution Environment.
  • Execution environments support both standard functions (up to 15 minutes) and Durable Functions (up to one year).

Lambda Execution Environment

Lambda in VPC

  • Lambda function always runs inside a VPC owned by the Lambda service which isn’t connected to your account’s default VPC
  • Lambda applies network access and security rules to this VPC and maintains and monitors the VPC automatically.
  • A function can be configured to be launched in private subnets in a VPC in your AWS account.
  • Function connected to VPC can access private resources databases, cache instances, or internal services during the execution.
  • To enable the function to access resources inside the private VPC, additional VPC-specific configuration information that includes private subnet IDs and security group IDs must be provided.
  • Lambda uses this information to set up ENIs that enables the function to connect securely to other resources within your private VPC.
  • Functions connected to VPC can’t access the Internet and need a NAT Gateway to access any external resources outside of AWS.
  • Functions cannot connect directly to a VPC with dedicated instance tenancy, instead, peer it to a second VPC with default tenancy.

Lambda Security

  • All data stored in ephemeral storage is encrypted at rest with a key managed by AWS.
  • Lambda functions provide access only to a single VPC. If multiple subnets are specified, they must all be in the same VPC. Other VPCs can be connected using VPC Peering.
  • Supports Code Signing using AWS Signer, which offers trust and integrity controls that enable you to verify that only unaltered code from approved developers is deployed in the functions.
  • AWS Lambda can perform the following signature checks at deployment:
    • Corrupt signature – This occurs if the code artifact has been altered since signing.
    • Mismatched signature – This occurs if the code artifact is signed by a signing profile that is not approved.
    • Expired signature – This occurs if the signature is past the configured expiry date.
    • Revoked signature – This occurs if the signing profile owner revokes the signing jobs.
  • For sensitive information, for e.g. passwords, AWS recommends using client-side encryption using AWS Key Management Service – KMS and store the resulting values as ciphertext in your environment variable.
  • Function code should include the logic to decrypt these values.

Lambda Permissions

  • IAM – Use IAM to manage access to the Lambda API and resources like functions and layers.
  • Execution Role – A Lambda function can be provided with an Execution Role, that grants it permission to access AWS services and resources e.g. send logs to CloudWatch and upload trace data to AWS X-Ray.
  • Function Policy – Resource-based Policies
    • Use resource-based policies to give other accounts and AWS services permission to use the Lambda resources.
    • Resource-based permissions policies are supported for functions and layers.

Invoking Lambda Functions

  • Lambda functions can be invoked
    • directly using the Lambda console or API, a function URL HTTP(S) endpoint, an AWS SDK, the AWS CLI, and AWS toolkits.
    • other AWS services like S3 and SNS invoke the function.
    • to read from a stream or queue and invoke the function.
  • Functions can be invoked
    • Synchronously
      • You wait for the function to process the event and return a response.
      • Error handling and retries need to be handled by the Client.
      • Invocation includes API, and SDK for calls from API Gateway.
      • Maximum request/response payload size is 6 MB.
    • Asynchronously
      • queues the event for processing and returns a response immediately.
      • handles retries and can send invocation records to a destination for successful and failed events.
      • Invocation includes S3, SNS, and CloudWatch Events
      • can define DLQ for handling failed events. AWS recommends using destinations instead of DLQ.
      • Maximum payload size is 1 MB (increased from 256 KB in Oct 2025).

Lambda SnapStart

  • Lambda SnapStart reduces cold start latency from several seconds to as low as sub-second, typically with no or minimal code changes.
  • Supported for Java, Python, and .NET runtimes (Python and .NET became GA in November 2024).
  • Works by taking a snapshot of the initialized execution environment (memory and disk state) after initialization completes.
  • When the function is invoked, Lambda resumes the execution environment from the cached snapshot instead of initializing from scratch.
  • Can improve startup performance by up to 10x for Java functions.
  • SnapStart is an opt-in capability configured at the function level.
  • For SnapStart-enabled functions, initialization code can run for up to 15 minutes when creating a snapshot.
  • Available in most AWS Regions (expanded to 23+ additional regions in 2025).
  • Unlike Provisioned Concurrency, SnapStart does not incur additional charges for pre-initialized environments.

Lambda Provisioned Concurrency

  • Lambda Provisioned Concurrency provides greater control over the performance of serverless applications.
  • When enabled, Provisioned Concurrency keeps functions initialized and hyper-ready to respond in double-digit milliseconds.
  • Provisioned Concurrency is ideal for building latency-sensitive applications, such as web or mobile backends, synchronously invoked APIs, and interactive microservices.
  • The amount of concurrency can be increased during times of high demand and lowered or turn it off completely when demand decreases.
  • If the concurrency of a function reaches the configured level, subsequent invocations of the function have the latency and scale characteristics of regular functions.
  • Application Auto Scaling can be used to automatically manage provisioned concurrency based on utilization.

Lambda Durable Functions

  • Lambda Durable Functions (announced Dec 2025) enable multi-step applications and AI workflows with automatic checkpointing and failure recovery.
  • Durable functions use a checkpoint and replay mechanism (durable execution) to persist progress at specific points in code.
  • Key capabilities:
    • Checkpoints – act as save points, persisting progress at specific moments in the execution.
    • Steps – define logical units of work that are automatically checkpointed upon completion.
    • Waits – allow pausing execution for up to one year without incurring compute charges (for on-demand functions).
    • Automatic Failure Recovery – when a failure occurs, execution resumes from the most recent checkpoint rather than starting over.
  • Requires the open source Durable Execution SDK (available for Node.js and Python runtimes).
  • When a function resumes, it replays from the beginning but skips completed work using saved checkpoint results.
  • Ideal for:
    • Human-in-the-loop processes
    • AI and LLM orchestration workflows
    • Multi-step data processing pipelines
    • Long-running approval workflows
  • Available in 14+ AWS Regions.
  • Does not require managing additional infrastructure or writing custom state management code.

Lambda Managed Instances

  • Lambda Managed Instances (announced Nov 2025, re:Invent) allow running Lambda functions on Amazon EC2 instances while maintaining serverless operational simplicity.
  • AWS handles all infrastructure tasks: instance lifecycle, OS and runtime patching, routing, load balancing, and auto scaling.
  • Key benefits:
    • EC2 Pricing Models – Access to Compute Savings Plans and Reserved Instances for up to 72% discount over On-Demand pricing.
    • Specialized Compute – Access to latest-generation EC2 instances including Graviton4, network-optimized, and large-memory instances.
    • Multi-concurrency – Each execution environment can handle multiple concurrent requests, improving resource utilization.
    • No Cold Starts – Pre-provisioned execution environments eliminate cold start latency.
  • Organized into Capacity Providers that define compute characteristics (instance type, networking, scaling parameters).
  • Instances have a maximum 14-day lifetime for security and compliance.
  • Pricing: Standard Lambda request charges + EC2 instance charges + 15% compute management fee.
  • Supports Node.js, Java, .NET, and Python runtimes.
  • Existing Lambda functions can be migrated without code changes (must validate thread safety for multi-concurrency).
  • Available in US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland).

Lambda@Edge

Read in-depth @ Lambda@Edge

Lambda Extensions

  • Lambda Extensions allow integration of Lambda with other third-party tools for monitoring, observability, security, and governance.
  • Extensions run as companion processes within the Lambda execution environment.
  • Internal extensions run as part of the runtime process; external extensions run as separate processes.
  • Extensions can run during the invocation phase and up to 2 seconds during the shutdown phase.

Lambda Concurrency and Scaling

  • Default account concurrency limit is 1,000 concurrent executions across all functions per region (can be increased via Service Quotas).
  • Lambda scales by 1,000 concurrent executions every 10 seconds until the account limit is reached (12x faster than previous scaling model).
  • Each function scales independently from other functions in the same account.
  • Reserved Concurrency – Guarantees a set number of concurrent executions for a specific function; also acts as a maximum concurrency limit for that function.
  • Provisioned Concurrency – Pre-initializes execution environments to eliminate cold starts.
  • Maximum Concurrency for SQS – Allows setting a maximum number of concurrent function invocations when using SQS as an event source.
  • New AWS accounts may have reduced concurrency quotas that are raised automatically based on usage.

Lambda Best Practices

  • Lambda function code should be stateless and ensure there is no affinity between the code and the underlying compute infrastructure.
  • Instantiate AWS clients outside the scope of the handler to take advantage of connection re-use.
  • Make sure you have set +rx permissions on your files in the uploaded ZIP to ensure Lambda can execute code on your behalf.
  • Lower costs and improve performance by minimizing the use of startup code not directly related to processing the current event.
  • Use the built-in CloudWatch monitoring of the Lambda functions to view and optimize request latencies.
  • Delete old Lambda functions that you are no longer using.
  • Use Graviton2 (arm64) architecture for up to 34% better price-performance with minimal code changes.
  • Use SnapStart for Java, Python, and .NET functions to reduce cold start latency without additional cost.
  • Use Lambda Power Tuning to find the optimal memory configuration for cost and performance.
  • Include the AWS SDK in your deployment package rather than relying on the runtime-included version for version consistency.
  • Use structured JSON logging with Advanced Logging Controls for better observability.
  • Keep runtimes up to date – Lambda runtimes are deprecated when the underlying language version reaches end of community LTS support.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your serverless architecture using AWS API Gateway, AWS Lambda, and AWS DynamoDB experienced a large increase in traffic to a sustained 400 requests per second, and dramatically increased in failure rates. Your requests, during normal operation, last 500 milliseconds on average. Your DynamoDB table did not exceed 50% of provisioned throughput, and Table primary keys are designed correctly. What is the most likely issue?
    1. Your API Gateway deployment is throttling your requests.
    2. Your AWS API Gateway Deployment is bottlenecking on request (de)serialization.
    3. You did not request a limit increase on concurrent Lambda function executions. (Lambda has a default account concurrency limit of 1,000. At 500 milliseconds per request, each concurrent execution handles 2 requests/second. The default 1,000 concurrency supports 2,000 requests/second, which exceeds 400 rps. However, new accounts may have lower limits. The key concept is understanding Lambda concurrency limits and requesting increases when needed.)
    4. You used Consistent Read requests on DynamoDB and are experiencing semaphore lock.
  2. A company wants to reduce cold start latency for their Java-based Lambda functions that power a latency-sensitive API. Which TWO approaches can help? (Choose 2)
    1. Enable Lambda SnapStart on the function
    2. Configure Provisioned Concurrency for the function
    3. Increase the function’s memory allocation to 10 GB
    4. Switch the function to asynchronous invocation
    5. Enable Lambda Extensions for the function
    (SnapStart reduces cold starts by up to 10x by caching initialized snapshots. Provisioned Concurrency keeps environments pre-initialized. Both eliminate cold start latency.)
  3. A team needs to build a multi-step workflow that involves calling multiple APIs, waiting for human approval (which may take days), and then processing the results. The team wants to minimize infrastructure management. Which Lambda capability is most suitable?
    1. Lambda Provisioned Concurrency
    2. Lambda Managed Instances
    3. Lambda Durable Functions
    4. AWS Step Functions with Lambda
    (Lambda Durable Functions can checkpoint progress, suspend execution for up to one year during waits like human approvals, and automatically recover from failures—all without additional infrastructure. While Step Functions can also orchestrate workflows, Durable Functions provide this within the Lambda programming model itself.)
  4. A company has steady-state Lambda workloads processing 10,000 requests per second. They want to reduce costs while maintaining the serverless programming model. What should they use?
    1. Lambda Provisioned Concurrency with Compute Savings Plans
    2. Lambda Managed Instances with EC2 Reserved Instances or Compute Savings Plans
    3. Migrate to Amazon ECS with Fargate
    4. Use Lambda with Graviton2 architecture only
    (Lambda Managed Instances allow using EC2 commitment-based pricing (Savings Plans, Reserved Instances) for up to 72% discount while maintaining the Lambda programming model and serverless operational simplicity.)
  5. Which of the following is NOT a supported Lambda runtime as of 2025?
    1. Python 3.13
    2. Node.js 22
    3. Java 21
    4. Go 1.x managed runtime
    (The Go 1.x managed runtime was deprecated on Jan 8, 2024. Go functions should now use the OS-only runtime provided.al2023 with a custom runtime approach.)
  6. A Lambda function processes files uploaded to S3 and writes processed results back to the same S3 bucket. The team notices unexpectedly high Lambda invocations and costs. What AWS feature helps prevent this?
    1. Lambda Reserved Concurrency
    2. S3 Event notification filtering
    3. Lambda Recursive Loop Detection
    4. Lambda function timeout configuration
    (Lambda Recursive Loop Detection automatically detects and stops recursive invocations between Lambda and supported services including S3, SQS, and SNS after 16 invocations, preventing runaway costs.)
  7. A company wants their Lambda functions to send response data progressively to clients as it becomes available, rather than waiting for the entire response. Which feature should they use?
    1. Lambda Provisioned Concurrency
    2. Lambda Response Streaming
    3. Lambda Function URLs with buffered response
    4. Lambda Asynchronous Invocation with Destinations
    (Lambda Response Streaming allows sending response data to callers as it becomes available, supporting larger payloads and enabling progressive rendering for web applications.)

AWS Lambda Event Source

~ Last updated on : ~ jayendrapatil ~ 5 Comments

AWS Lambda Event Source

  • Lambda Event Source is an AWS service or developer-created application that produces events that trigger an AWS Lambda function to run.
  • Event sources can be either AWS Services or Custom applications.
  • Event sources can be both push and pull sources
    • Services like S3, and SNS publish events to Lambda by invoking the cloud function directly.
    • Lambda can also poll resources in services like Kafka, and Kinesis streams that do not publish events to Lambda.
  • Events are passed to a Lambda function as an event input parameter. For batch event sources, such as Kinesis Streams, the event parameter may contain multiple events in a single call, based on the requested batch size

Lambda Event Source Mapping

  • Lambda Event source mapping refers to the configuration which maps an event source to a Lambda function.
  • Event source mapping
    • enables automatic invocation of the Lambda function when events occur.
    • identifies the type of events to publish and the Lambda function to invoke when events occur.
  • Event source mappings support the following services:
    • Amazon DynamoDB Streams
    • Amazon Kinesis
    • Amazon SQS
    • Amazon MSK (Managed Streaming for Apache Kafka)
    • Self-managed Apache Kafka
    • Amazon MQ
    • Amazon DocumentDB (with MongoDB compatibility)

Event Source Mapping – Event Filtering

  • Lambda supports event filtering for event source mappings, allowing you to control which events are sent to your function.
  • Event filtering reduces unnecessary function invocations and can lower costs.
  • Filtering is supported for Amazon SQS, Amazon Kinesis, Amazon DynamoDB Streams, Amazon MSK, Self-managed Apache Kafka, and Amazon MQ.
  • Lambda does not support event filtering for Amazon DocumentDB.
  • Filter criteria can be encrypted with AWS KMS Customer Managed Keys (CMK) for enhanced security (announced August 2024).

Event Source Mapping – Provisioned Mode

  • Provisioned Mode allows you to optimize the throughput of your event source mapping by provisioning event polling resources that remain ready to handle sudden spikes in traffic.
  • In provisioned mode, you define minimum and maximum limits for event pollers dedicated to your ESM.
  • Initially launched for Apache Kafka ESMs (November 2024), and extended to Amazon SQS ESMs (November 2025).
  • For Kafka, each event poller can handle up to 5 MB/sec of throughput.
  • SQS Provisioned Mode provides 3x faster scaling (up to 1,000 concurrent executions per minute) and 16x higher capacity (up to 20,000 concurrency).
  • Kafka ESMs with Provisioned Mode support grouping to optimize costs up to 90% (November 2025).
  • Lambda natively supports Avro and Protobuf formatted Kafka events with Provisioned Mode, with integration to schema registries (June 2025).

Event Source Mapping – CloudWatch Metrics

  • New opt-in CloudWatch metrics for ESMs were introduced in November 2024 for SQS, Kinesis, and DynamoDB event sources.
  • Metrics include: PolledEventCount, InvokedEventCount, FilteredOutEventCount, FailedInvokeEventCount, DeletedEventCount, DroppedEventCount, and OnFailureDestinationDeliveredEventCount.
  • These metrics help diagnose processing issues by tracking events through their processing states.

Event Source Mapping – Failed-Event Destinations

  • Lambda supports on-failure destinations for event source mappings to retain records of failed invocations.
  • Supported destinations include Amazon SQS, Amazon SNS, Kafka topics, and Amazon S3 (added November 2024).
  • S3 destinations include the full invocation record along with metadata, enabling further processing via S3 Event Notifications.
  • For Kafka ESMs, you can configure a Kafka topic as an on-failure destination.

Lambda Event Sources Type

AWS Lambda Event Source Types

Push-based (Triggers)

  • also referred to as the Push model
  • includes services like S3, SNS, SES, API Gateway, EventBridge, etc.
  • Event source mapping maintained on the event source side
  • as the event sources invoke the Lambda function, a resource-based policy should be used to grant the event source the necessary permissions.

Pull-based (Event Source Mappings)

  • also referred to as the Pull model
  • covers stream and queue-based event sources like DynamoDB Streams, Kinesis, MQ, SQS, Kafka (MSK and self-managed), and Amazon DocumentDB
  • Event source mapping maintained on the Lambda side
  • Lambda polls the event source and invokes the function synchronously with a batch of records.

Lambda Event Sources Invocation Model

Synchronously

  • You wait for the function to process the event and return a response.
  • Error handling and retries need to be handled by the Client.
  • Invocation includes API Gateway, ALB, Lambda Function URLs, Cognito, Lex, and SDK calls.

Asynchronously

  • queues the event for processing and returns a response immediately.
  • handles retries and can send invocation records to a destination for successful and failed events.
  • Supported destinations for failed events include SQS, SNS, EventBridge, another Lambda function, or Amazon S3 (added November 2024).
  • Invocation includes S3, SNS, EventBridge, CloudWatch Logs, CloudFormation, SES, IoT, CodeCommit, CodePipeline, and Config.

Lambda Supported Event Sources

AWS Lambda can be configured as an event source for multiple AWS services.

📋 Note (June 2025): The table below has been updated to reflect the current official AWS documentation. Key changes include:

  • Amazon Kinesis Data Firehose renamed to Amazon Data Firehose (Feb 2024)
  • Amazon DocumentDB, AWS Step Functions, and Amazon VPC Lattice added as supported event sources
  • AWS IoT Events deprecated (EOL May 20, 2026)
  • EventBridge now supports both synchronous and asynchronous invocation (via Pipes)
Service Method of invocation
Amazon MSK – Managed Streaming for Apache Kafka Event source mapping
Self-managed Apache Kafka Event source mapping
Amazon API Gateway Event-driven; synchronous invocation
AWS CloudFormation Event-driven; asynchronous invocation
Amazon CloudFront (Lambda@Edge) Event-driven; synchronous invocation
Amazon EventBridge (formerly CloudWatch Events) Event-driven; asynchronous invocation (event buses and schedules), synchronous or asynchronous invocation (Pipes)
Amazon CloudWatch Logs Event-driven; asynchronous invocation
AWS CodeCommit Event-driven; asynchronous invocation
AWS CodePipeline Event-driven; asynchronous invocation
Amazon Cognito Event-driven; synchronous invocation
AWS Config Event-driven; asynchronous invocation
Amazon Connect Event-driven; synchronous invocation
Amazon DocumentDB Event source mapping
Amazon DynamoDB Event source mapping
Elastic Load Balancing (Application Load Balancer) Event-driven; synchronous invocation
AWS IoT Event-driven; asynchronous invocation
Amazon Kinesis Event source mapping
Amazon Data Firehose (formerly Kinesis Data Firehose) Event-driven; synchronous invocation
Amazon Lex Event-driven; synchronous invocation
Amazon MQ Event source mapping
Amazon Simple Email Service Event-driven; asynchronous invocation
Amazon Simple Notification Service Event-driven; asynchronous invocation
Amazon Simple Queue Service Event source mapping
Amazon S3 Event-driven; asynchronous invocation
Amazon Simple Storage Service Batch Event-driven; synchronous invocation
Secrets Manager Secret rotation
AWS Step Functions Event-driven; synchronous or asynchronous invocation
Amazon VPC Lattice Event-driven; synchronous invocation

⚠️ AWS IoT Events – DEPRECATED

AWS IoT Events reached End of Life (EOL) on May 20, 2026. The service no longer accepts new customers (since May 20, 2025) and the console and resources are no longer accessible.

Migration: Use Amazon EventBridge with AWS IoT Core rules to achieve similar event-driven functionality.

Amazon S3

  • S3 bucket events, such as the object-created or object-deleted events can be processed using Lambda functions for e.g., the Lambda function can be invoked when a user uploads a photo to a bucket to read the image and create a thumbnail.
  • S3 bucket notification configuration feature can be configured for the event source mapping, to identify the S3 bucket events and the Lambda function to invoke.
  • S3 events can also be routed through Amazon EventBridge for more advanced filtering and routing capabilities.
  • Error handling for an event source depends on how Lambda is invoked
  • S3 invokes your Lambda function asynchronously.

DynamoDB

  • Lambda functions can be used as triggers for the DynamoDB table to take custom actions in response to updates made to the DynamoDB table.
  • Trigger can be created by
    • Enabling DynamoDB Streams for the table.
    • Lambda polls the stream and processes any updates published to the stream
  • DynamoDB is a stream-based event source and with stream-based service, the event source mapping is created in Lambda, identifying the stream to poll and which Lambda function to invoke.
  • Supports event filtering to only process relevant changes.
  • Supports on-failure destinations (SQS, SNS, S3) for failed event processing.
  • Error handling for an event source depends on how Lambda is invoked

Kinesis Streams

  • AWS Lambda can be configured to automatically poll the Kinesis stream periodically (once per second) for new records.
  • Lambda can process any new records such as social media feeds, IT logs, website click streams, financial transactions, and location-tracking events
  • Kinesis Streams is a stream-based event source and with stream-based service, the event source mapping is created in Lambda, identifying the stream to poll and which Lambda function to invoke.
  • Supports event filtering to only invoke the function for relevant records.
  • Supports on-failure destinations (SQS, SNS, S3) for failed event processing.
  • Error handling for an event source depends on how Lambda is invoked

Simple Notification Service – SNS

  • SNS notifications can be processed using Lambda
  • When a message is published to an SNS topic, the service can invoke Lambda function by passing the message payload as parameter, which can then process the event
  • Lambda function can be triggered in response to CloudWatch alarms and other AWS services that use SNS.
  • SNS via topic subscription configuration feature can be used for the event source mapping, to identify the SNS topic and the Lambda function to invoke
  • Error handling for an event source depends on how Lambda is invoked
  • SNS invokes your Lambda function asynchronously.

Simple Email Service – SES

  • SES can be used to receive messages and can be configured to invoke Lambda function when messages arrive, by passing in the incoming email event as parameter
  • SES using the rule configuration feature can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • SES invokes your Lambda function asynchronously.

Amazon Cognito

  • Cognito Events feature enables Lambda function to run in response to events in Cognito for e.g. Lambda function can be invoked for the Sync Trigger events, that is published each time a dataset is synchronized.
  • Cognito User Pool triggers can invoke Lambda at various points in the authentication flow (pre sign-up, pre authentication, post confirmation, etc.).
  • Cognito event subscription configuration feature can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • Cognito is configured to invoke a Lambda function synchronously

CloudFormation

  • Lambda function can be specified as a custom resource to execute any custom commands as a part of deploying CloudFormation stacks and can be invoked whenever the stacks are created, updated, or deleted.
  • CloudFormation using stack definition can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • CloudFormation invokes the Lambda function asynchronously

CloudWatch Logs

  • Lambda functions can be used to perform custom analysis on CloudWatch Logs using CloudWatch Logs subscriptions.
  • CloudWatch Logs subscriptions provide access to a real-time feed of log events from CloudWatch Logs and deliver it to the AWS Lambda function for custom processing, analysis, or loading to other systems.
  • CloudWatch Logs using the log subscription configuration can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • CloudWatch Logs invokes the Lambda function asynchronously

Amazon EventBridge (formerly CloudWatch Events)

  • Amazon EventBridge (formerly CloudWatch Events) helps respond to state changes in AWS resources and receives events from AWS services, SaaS applications, and custom sources.
  • Rules that match selected events can be created to route them to the Lambda function to take action for e.g., the Lambda function can be invoked to log the state of an EC2 instance or AutoScaling Group.
  • EventBridge by using a rule target definition can be used for the event source mapping
  • EventBridge Pipes can invoke Lambda either synchronously or asynchronously, providing point-to-point integrations between event sources and targets with optional filtering, enrichment, and transformation.
  • EventBridge Scheduler invokes Lambda functions asynchronously on a schedule (replacing the older CloudWatch Events scheduled rules).
  • Error handling for an event source depends on how Lambda is invoked
  • EventBridge event buses invoke Lambda asynchronously; Pipes can invoke synchronously (REQUEST_RESPONSE) or asynchronously (FIRE_AND_FORGET).

CodeCommit

  • Trigger can be created for a CodeCommit repository so that events in the repository will invoke a Lambda function for e.g., Lambda function can be invoked when a branch or tag is created or when a push is made to an existing branch.
  • CodeCommit by using a repository trigger can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • CodeCommit Events invokes the Lambda function asynchronously
ℹ️ Note: CodeCommit was briefly deprecated in July 2024 but returned to General Availability in November 2025. However, the service is in a feature freeze state with no new features planned.

Scheduled Events (powered by Amazon EventBridge)

  • AWS Lambda can be invoked regularly on a scheduled basis using Amazon EventBridge Scheduler or EventBridge rules with schedule expressions.
  • EventBridge Scheduler supports rate and cron expressions for flexible scheduling.
  • EventBridge by using a rule target definition or Scheduler can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • EventBridge Scheduler invokes the Lambda function asynchronously

AWS Config

  • Lambda functions can be used to evaluate whether the AWS resource configurations comply with custom Config rules.
  • As resources are created, deleted, or changed, AWS Config records these changes and sends the information to the Lambda functions, which can then evaluate the changes and report results to AWS Config. AWS Config can be used to assess overall resource compliance
  • AWS Config by using a rule target definition can be used for the event source mapping
  • Error handling for an event source depends on how Lambda is invoked
  • AWS Config invokes the Lambda function asynchronously

Amazon API Gateway

  • Lambda function can be invoked over HTTPS by defining a custom REST API and endpoint using Amazon API Gateway.
  • Individual API operations, such as GET and PUT, can be mapped to specific Lambda functions.
  • When an HTTPS request to the API endpoint is received, the API Gateway service invokes the corresponding Lambda function.
  • Error handling for an event source depends on how Lambda is invoked.
  • API Gateway is configured to invoke a Lambda function synchronously.

Amazon DocumentDB

  • Lambda can process events from Amazon DocumentDB (with MongoDB compatibility) change streams.
  • Lambda polls the DocumentDB change stream and invokes the function with batches of documents.
  • Requires an AWS Secrets Manager secret to store database credentials for the event source mapping.
  • Supports DocumentDB versions 4.0 and 5.0 only (version 3.6 is not supported).
  • Event filtering is not supported for DocumentDB event source mappings.
  • DocumentDB uses the event source mapping model (pull-based).

Amazon VPC Lattice

  • Amazon VPC Lattice can invoke Lambda functions as targets for service network traffic.
  • Enables Lambda functions to be registered as targets in VPC Lattice target groups.
  • Provides service-to-service communication with built-in authentication and authorization.
  • VPC Lattice invokes Lambda functions synchronously.

AWS Step Functions

  • AWS Step Functions can invoke Lambda functions as part of state machine workflows.
  • Supports both synchronous (RequestResponse) and asynchronous (Event) invocation types.
  • Provides orchestration capabilities for complex multi-step workflows involving Lambda functions.

Other Event Sources: Invoking a Lambda Function On Demand

  • Lambda functions can be invoked on-demand without the need to preconfigure any event source mapping in this case.
  • Lambda Function URLs provide a dedicated HTTPS endpoint for your function, enabling direct HTTP invocation without API Gateway.

Lambda Durable Functions (re:Invent 2025)

  • Lambda durable functions enable building reliable, fault-tolerant, multi-step applications that can execute for up to one year.
  • Durable functions automatically checkpoint progress, suspend execution during long-running tasks, and recover from failures without requiring custom state management code.
  • Extends the Lambda programming model with primitives like “steps” and “waits” in your event handler.
  • Durable functions can be used with event source mappings for processing streams or queues with complex multi-step workflows.
  • Compute charges are not incurred during suspension for on-demand functions.
  • Useful for human-in-the-loop processes, AI workflows, and long-running multi-step applications.

Lambda Tenant Isolation Mode (re:Invent 2025)

  • Lambda tenant isolation mode provides per-tenant compute boundaries within a single Lambda function.
  • Reduces operational complexity of managing separate functions per tenant while maintaining strict isolation.
  • Can be integrated with event source mappings to process events with tenant-level isolation.
  • Tenant identifier is available in the function context object for tenant-specific logic.
  • Must be enabled on new functions (cannot be enabled on existing functions).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company needs to process DynamoDB table changes and only invoke Lambda for items where the “status” field equals “COMPLETED”. What is the most efficient approach?
    1. Use a Lambda function to check the status field and return early if not “COMPLETED”
    2. Use DynamoDB Streams with Lambda event source mapping event filtering
    3. Use EventBridge Pipes with DynamoDB as source and Lambda as target
    4. Use a Step Functions workflow to check conditions before invoking Lambda
    Show Answer

    Answer: b – Event source mapping event filtering allows you to define filter criteria so Lambda is only invoked for matching records, reducing costs and unnecessary invocations.

  2. A company has a Kafka-based event pipeline using Amazon MSK that experiences significant traffic spikes. They need to ensure near-real-time processing with minimal lag during spikes. What should they configure?
    1. Increase Lambda concurrency limits
    2. Use Lambda Provisioned Concurrency
    3. Enable Provisioned Mode for the Kafka event source mapping
    4. Add more partitions to the Kafka topic
    Show Answer

    Answer: c – Provisioned Mode for Kafka ESMs provisions event polling resources that remain ready to handle sudden spikes in traffic, providing optimized throughput for the event source mapping.

  3. An application processes events from an SQS queue through Lambda. The team needs visibility into how many events are being filtered out and how many are failing. What should they use?
    1. CloudWatch Lambda function metrics (Invocations, Errors)
    2. SQS queue metrics (ApproximateNumberOfMessagesVisible)
    3. Event Source Mapping CloudWatch metrics (FilteredOutEventCount, FailedInvokeEventCount)
    4. AWS X-Ray tracing
    Show Answer

    Answer: c – The ESM CloudWatch metrics launched in November 2024 provide detailed visibility into event processing states including filtered, failed, and delivered counts.

  4. A company’s Lambda function processes Kinesis stream records. Failed batches need to be preserved for later analysis without blocking stream processing. What is the recommended approach?
    1. Configure a dead-letter queue on the Lambda function
    2. Configure an S3 bucket as an on-failure destination on the event source mapping
    3. Write failed records to DynamoDB from within the function code
    4. Use Kinesis Data Firehose to capture all records
    Show Answer

    Answer: b – S3 as an on-failure destination for stream event source mappings (added Nov 2024) captures the full invocation record with metadata for failed batches.

  5. Which of the following event sources use Lambda’s event source mapping (pull-based) model? (Choose 3)
    1. Amazon S3
    2. Amazon DocumentDB
    3. Amazon SNS
    4. Amazon DynamoDB Streams
    5. Amazon SQS
    6. Amazon EventBridge
    Show Answer

    Answer: b, d, e – DocumentDB, DynamoDB Streams, and SQS all use event source mappings where Lambda polls the source. S3, SNS, and EventBridge use the push model.

References