Serverless

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

Aurora DSQL – Serverless Distributed SQL Database

~ Last updated on : ~ Kiro Agent

Amazon Aurora DSQL

  • Amazon Aurora DSQL is a serverless, distributed relational database service optimized for transactional (OLTP) workloads.
  • Aurora DSQL was previewed at AWS re:Invent 2024 and became generally available on May 27, 2025.
  • It offers virtually unlimited scale, the highest availability, and zero infrastructure management.
  • Aurora DSQL is PostgreSQL-compatible (currently PostgreSQL 16), enabling developers to use familiar drivers, ORMs, tools, and SQL features.
  • It is designed for 99.99% availability in single-Region configuration and 99.999% availability in multi-Region configuration.
  • Aurora DSQL uses Optimistic Concurrency Control (OCC) instead of traditional pessimistic locking, eliminating deadlocks and lock contention.
  • It supports active-active multi-Region deployments with strongly consistent reads and writes from any Region.
  • Aurora DSQL scales to zero when idle — no compute charges when no queries are running.
  • It eliminates all operational burden including patching, upgrades, maintenance downtime, capacity planning, and database sharding.

Aurora DSQL Architecture

  • Aurora DSQL uses a disaggregated architecture where the database is separated into four independent, multi-tenant components that scale independently:
    • Query Processors (Firecracker MicroVMs) – Stateless compute units that handle SQL parsing, query planning, and execution. They run in AWS Firecracker MicroVMs (same technology as AWS Lambda), enabling true scale-to-zero behavior.
    • Adjudicators – The conflict detection layer that validates write transactions at commit time using Optimistic Concurrency Control. If conflicts are detected, the transaction is rejected with SQLSTATE 40001.
    • Journal (Paxos-Based Log) – A distributed write-ahead log using Paxos consensus that provides cross-AZ durability. Every committed transaction is written to the Journal before being acknowledged.
    • MVCC Storage Replicas – Multi-Version Concurrency Control storage that maintains table data across three Availability Zones in each active Region.
  • A control plane coordinates all components, providing redundancy across three AZs with automatic scaling and self-healing.
  • Each component scales independently — query processing, commit, and storage layers adapt to workloads of any shape including different read/write ratios, data sizes, and query complexities.

Single-Region Clusters

  • Active-active across three Availability Zones, minimizing replication lag and eliminating traditional failover operations.
  • All write transactions are committed to a distributed transaction log and synchronously replicated to storage replicas in three AZs.
  • Designed for 99.99% availability.
  • When a component or AZ becomes impaired, requests are automatically redirected to healthy infrastructure without manual intervention.

Multi-Region Clusters

  • Provides 99.999% availability with active-active multi-Region deployment.
  • Two Regional endpoints present a single logical database, both available for concurrent read and write operations with strong data consistency.
  • Aurora DSQL synchronously replicates writes across Regions, enabling strongly consistent reads and writes from any linked cluster.
  • A third Region acts as a witness Region — stores only encrypted transaction logs for Paxos quorum, not full data copies.
  • Multi-Region clusters must be created within the same Region set (same continent):
    • US Regions: US East (N. Virginia), US East (Ohio), US West (Oregon)
    • Asia Pacific: Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Tokyo)
    • Europe: Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris)
  • Cross-continent multi-Region clusters are not currently supported.

Aurora DSQL Key Features

  • Serverless & Zero Infrastructure Management
    • No servers to provision, patch, upgrade, or manage.
    • No maintenance downtime — eliminates traditional database failover.
    • Automatically manages storage optimization, statistics collection, and performance tuning.
    • Scales to zero when idle with no compute charges.
  • Active-Active Multi-Region
    • Both Regions accept concurrent reads and writes.
    • Single logical database across Regions with strong consistency.
    • No eventual consistency or missing data during failovers.
  • Strongly Consistent Reads
    • Provides strong read-after-write consistency.
    • Readers always see the same data regardless of which Region they connect to.
    • Zero data loss for both single and multi-Region clusters due to synchronous replication.
  • Optimistic Concurrency Control (OCC)
    • Transactions execute without acquiring locks.
    • Conflicts are detected at commit time, not during execution.
    • Eliminates deadlocks and prevents slow transactions from blocking others.
    • If conflicts occur, the later transaction receives SQLSTATE 40001 and must be retried by the application.
    • Read-only transactions are conflict-free and never fail due to OCC.
  • Auto-Scaling
    • Scales compute, I/O, and storage automatically based on workload.
    • No database sharding or instance upgrades required.
    • Query processing, commit, and storage layers scale independently.
  • 99.999% Multi-Region Availability
    • Active-active architecture with automatic failure recovery.
    • No manual failover or switchover operations.
    • Multi-AZ and multi-Region availability built-in.
  • PostgreSQL Compatibility
    • Compatible with PostgreSQL 16 wire protocol.
    • Supports standard drivers: psycopg2, asyncpg, node-postgres, JDBC.
    • Supports ACID transactions, SQL queries, secondary indexes, joins, CTEs, window functions, aggregations.
    • IAM-based token authentication (no password-based authentication).
  • ACID Transactions
    • Full ACID properties even across multiple Regions.
    • Strong snapshot isolation (equivalent to PostgreSQL REPEATABLE READ).
    • Cross-AZ and cross-Region durability.
  • Change Data Capture (CDC)
    • Supports streaming changes to Amazon Kinesis Data Streams.
    • Billed as StreamDPU — scales with volume of changes captured.
  • Security
    • Full integration with AWS IAM and AWS CloudTrail.
    • Token-based authentication using IAM (blocks standard password-based auth).
    • Encrypted transaction logs in witness Region.

Aurora DSQL Pricing

  • Aurora DSQL uses a pay-per-use pricing model with no upfront costs.
  • Billing is based on two primary components:
    • Database Activity (DPUs) – Distributed Processing Units measure all work done by the system including compute, I/O reads, I/O writes, and CDC streaming.
    • Storage (GB-month) – Based on total data stored, replicated across 3 AZs (you pay for one logical copy per Region).
  • DPU Rate: $8.00 per million DPUs (in US East regions).
  • Storage Rate: $0.33 per GB-month.
  • Free Tier (permanent, no 12-month expiry):
    • 100,000 DPUs per month (~700,000 TPC-C transactions)
    • 1 GB of storage per month
  • Multi-Region Write Replication: Incurs extra DPU charges equal to the cost of originating writes (approximately 50% premium on write DPUs). No separate data transfer charges.
  • Scale to Zero: When the cluster is idle, DPU usage scales to zero — $0.00 compute charges. Only storage is billed continuously.
  • DPU Sub-components (visible in CloudWatch, all billed at same rate):
    • ComputeDPU – SQL query execution (joins, functions, aggregations)
    • ReadDPU – Data read from storage
    • WriteDPU – Data written to storage
    • MultiRegionWriteDPU – Replication to peered clusters
    • StreamDPU – Change data capture streaming
  • Aurora DSQL usage may be eligible for Database Savings Plans.
  • Inter-AZ replication within a Region is included at no additional charge.

Aurora DSQL vs Aurora Serverless v2 vs Aurora Global Database vs DynamoDB Global Tables

Feature Aurora DSQL Aurora Serverless v2 Aurora Global Database DynamoDB Global Tables
Architecture Disaggregated, distributed, OCC Standard Aurora engine, ACU-based scaling Provisioned/Serverless instances with cross-Region replication Fully managed NoSQL, partitioned
Data Model Relational (SQL) Relational (SQL) Relational (SQL) Key-Value / Document (NoSQL)
Multi-Region Writes Active-Active (built-in) Not supported (single-Region only) Active-Passive (single writer, read replicas in other Regions) Active-Active (all Regions accept writes)
Consistency Strong consistency (reads and writes) Strong consistency (single-Region) Eventual consistency for cross-Region reads; strong in primary Eventual consistency (cross-Region); strong consistency for single-Region reads
Availability SLA 99.99% (single-Region), 99.999% (multi-Region) 99.99% 99.99% with <1 min RTO for cross-Region failover 99.999%
Scaling Serverless, scales to zero, virtually unlimited Serverless, 0.5-128 ACUs, scales to zero Provisioned instances or Serverless v2; manual scaling On-demand or provisioned; auto-scaling
PostgreSQL Compatibility Subset (no FK, triggers, sequences, stored procs, views) Full Aurora PostgreSQL/MySQL Full Aurora PostgreSQL/MySQL Not applicable (NoSQL)
Concurrency Control Optimistic (OCC) — no locks, retry on conflict Pessimistic locking (traditional) Pessimistic locking (traditional) Last-writer-wins or conditional writes
Infrastructure Management Zero (fully serverless) Minimal (serverless but cluster management needed) Moderate (instance sizing, replica management, failover config) Zero (fully serverless)
Pricing Model Per DPU ($8/million) + storage ($0.33/GB-month) Per ACU-hour ($0.12/hr) + storage + I/O Instance hours + storage + I/O + data transfer Per WRU/RRU (on-demand) or provisioned WCU/RCU + storage
Free Tier 100K DPUs + 1 GB/month (permanent) None (beyond general AWS Free Tier) None 25 GB storage + 25 WCU/RCU (provisioned, 12-month)
Transaction Limits 3,000 rows per transaction Standard PostgreSQL limits Standard PostgreSQL limits 25 items / 4 MB per transaction
Best For Global OLTP, low-contention writes, serverless backends, new apps Variable workloads, existing PostgreSQL apps, single-Region Disaster recovery, read scaling, cross-Region with single writer High-throughput key-value access, global apps not needing SQL

Aurora DSQL Limitations

  • PostgreSQL Feature Gaps:
    • No foreign keys (referential integrity must be enforced in application code)
    • No triggers
    • No views or materialized views
    • No sequences or SERIAL/IDENTITY columns (use UUIDs via gen_random_uuid())
    • No stored procedures (PL/pgSQL not supported; SQL functions are supported)
    • No PostgreSQL extensions (PostGIS, pgvector, etc.)
    • No explicit locking (SELECT FOR UPDATE not supported)
    • No temporary tables (use CTEs or regular tables with unique naming)
  • Transaction Constraints:
    • Maximum of 3,000 rows modified per transaction (INSERT, UPDATE, DELETE)
    • DDL and DML operations require separate transactions
    • Only 1 DDL statement per transaction
    • Fixed isolation level: REPEATABLE READ only (no SERIALIZABLE, no READ COMMITTED)
  • Operational Constraints:
    • Single database per cluster (named postgres) — use schemas for logical separation
    • Database connections time out after 1 hour
    • UTF-8 encoding only with C collation only
    • UTC system timezone
    • No password-based authentication (IAM token-based only)
  • Multi-Region Constraints:
    • Cross-continent multi-Region clusters not supported
    • Multi-Region clusters must be within the same Region set
    • Multi-Region writes incur additional DPU charges (~50% premium)
  • OCC Requirements:
    • Applications must implement retry logic for write transactions (handle SQLSTATE 40001)
    • Not suitable for high write-contention workloads (inventory counters, hot-row updates)
    • Each retry attempt consumes additional DPUs

Aurora DSQL Use Cases

Financial Transactions

  • Global-scale financial transaction processing across multiple AWS Regions.
  • Core banking systems requiring strong consistency without choosing between consistency and low latency.
  • Spend management systems and digital currency infrastructure.
  • Payment processing with ACID guarantees across Regions.
  • The low-contention nature of financial transactions (each transaction typically touches unique records) makes OCC highly effective.

Global Applications

  • Multi-Region SaaS applications requiring active-active writes with strong consistency.
  • Global scheduling and booking systems (e.g., Frontdoor home services marketplace).
  • Collaborative tools where users in different Regions need consistent data views.
  • Multi-Region authentication and session management services.
  • Microservices and event-driven architectures with serverless backends (Lambda + API Gateway + DSQL).

Gaming

  • Global game state — maintaining consistent world state across geographically distributed players.
  • Player inventory — managing in-game items and purchases with ACID guarantees preventing duplication exploits.
  • In-game purchases — transactional integrity for virtual currency and item transactions.
  • Live events — consistent event state across all Regions simultaneously.
  • Real-time player interactions — ensuring consistent data for trades, gifts, and cooperative actions.
  • Note: For high-contention leaderboard updates (many players updating the same row), DynamoDB or Aurora with pessimistic locking may be more appropriate. DSQL works well for leaderboards designed with per-player rows.

Other Use Cases

  • Order management systems and e-commerce transaction processing.
  • User profile and account management (low-contention per-user updates).
  • Appointment and resource scheduling systems.
  • Event logging and audit trail systems (append-only patterns).
  • Development and testing environments (leveraging permanent free tier).

Aurora DSQL Region Availability

  • GA Regions (May 2025 launch): US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Osaka), Asia Pacific (Tokyo), Europe (Ireland), Europe (London), Europe (Paris)
  • Added July 2025: Asia Pacific (Seoul)
  • Added October 2025: Europe (Frankfurt)
  • Added February 2026: Additional Regions
  • Added May 2026: Asia Pacific (Hong Kong), Asia Pacific (Mumbai), Asia Pacific (Singapore), Europe (Stockholm), South America (São Paulo)
  • Region expansion continues through 2026.

AWS Certification Exam Relevance

  • AWS Solutions Architect Associate (SAA-C03)
    • Understanding when to choose Aurora DSQL vs Aurora Serverless v2 vs DynamoDB Global Tables for multi-Region architectures.
    • Knowing the availability SLAs (99.99% single-Region, 99.999% multi-Region).
    • Understanding serverless database options and their trade-offs.
  • AWS Solutions Architect Professional (SAP-C02)
    • Designing global, active-active architectures with strong consistency.
    • Understanding OCC implications for application design.
    • Comparing multi-Region database strategies: Aurora DSQL vs Aurora Global Database vs DynamoDB Global Tables.
    • Cost optimization for global database architectures.
  • AWS Database Specialty (DBS-C01)
    • Deep understanding of Aurora DSQL architecture (disaggregated components, Paxos journal, Adjudicators).
    • PostgreSQL compatibility limitations and migration considerations.
    • OCC conflict resolution and retry patterns.
    • DPU pricing model and cost estimation.
    • When to use DSQL vs other Aurora variants vs DynamoDB.

Amazon Aurora DSQL Practice Questions

Question 1:

A company is building a global financial application that requires active-active writes in multiple AWS Regions with strong consistency for all reads. The application uses a relational data model with SQL queries and ACID transactions. Which database service is MOST appropriate?

  1. Amazon Aurora Global Database
  2. Amazon DynamoDB Global Tables
  3. Amazon Aurora DSQL multi-Region cluster
  4. Amazon Aurora Serverless v2 with cross-Region read replicas
Show Answer

Answer: C –

  • Aurora DSQL multi-Region clusters provide active-active writes with strong consistency across Regions using a relational/SQL data model — exactly what this scenario requires.
  • Aurora Global Database (Option A) supports only active-passive (single writer Region with read replicas in other Regions).
  • DynamoDB Global Tables (Option B) provides active-active but with eventual consistency and a NoSQL data model, not relational SQL.
  • Aurora Serverless v2 (Option D) is single-Region only and does not support cross-Region writes.

Question 2:

A development team is migrating an existing PostgreSQL application to Aurora DSQL. The application heavily uses foreign keys, database triggers for audit logging, and stored procedures for business logic. What should the team do?

  1. Migrate directly — Aurora DSQL supports all PostgreSQL features
  2. Refactor the application to enforce referential integrity in application code, move trigger logic to EventBridge/application layer, and move stored procedure logic to the application or Lambda functions
  3. Use Aurora DSQL with PostgreSQL extensions to enable missing features
  4. Use Aurora Serverless v2 instead, which provides full PostgreSQL compatibility without requiring application changes
Show Answer

Answer: B (if DSQL is required) or D (if full PG compatibility is the priority) –

  • Aurora DSQL does not support foreign keys, triggers, or stored procedures (PL/pgSQL). These are architectural limitations of the distributed design.
  • Option B is correct if the team must use DSQL — all these features need application-level workarounds.
  • Option D is the simpler path if the requirement is just serverless PostgreSQL without application refactoring.
  • Option A is incorrect — DSQL is a PostgreSQL-compatible subset, not full PostgreSQL.
  • Option C is incorrect — Aurora DSQL does not support PostgreSQL extensions.

    • Question 3:

    An e-commerce company uses Aurora DSQL for its order processing system. During peak sales events, they notice increased transaction failures with SQLSTATE 40001 errors on their inventory update operations where multiple customers try to purchase the last few items simultaneously. What is the MOST likely cause and solution?

    1. The database is running out of capacity; increase the provisioned instances
    2. Aurora DSQL’s Optimistic Concurrency Control is detecting write conflicts on the same inventory rows; redesign to reduce contention or switch to Aurora Serverless v2 with pessimistic locking for the inventory service
    3. The database connection pool is exhausted; increase the connection limit
    4. The transaction isolation level needs to be changed to READ COMMITTED
    Show Answer

    Answer: B –

    • SQLSTATE 40001 is the serialization failure error returned by Aurora DSQL’s OCC when concurrent transactions conflict on the same data.
    • High-contention inventory updates (many writers to the same row) are a known poor fit for OCC — they generate high retry rates.
    • Solutions include redesigning the schema to reduce contention, or using Aurora Serverless v2 with traditional pessimistic locking for high-contention workloads.
    • Option A is incorrect — Aurora DSQL is serverless with no provisioned instances.
    • Option D is incorrect — Aurora DSQL only supports REPEATABLE READ isolation; it cannot be changed.

    Question 4:

    A startup wants to minimize database costs for their development environment while building a globally distributed application. They need a PostgreSQL-compatible database that costs nothing when idle and has a permanent free tier. Which option BEST meets these requirements?

    1. Amazon RDS PostgreSQL with a db.t3.micro instance (free tier)
    2. Amazon Aurora Serverless v2 (scales to zero)
    3. Amazon Aurora DSQL (scales to zero with permanent free tier)
    4. Amazon DynamoDB with on-demand capacity
    Show Answer

    Answer: C –

    • Aurora DSQL has a permanent free tier (100,000 DPUs + 1 GB storage/month with no 12-month expiry) and scales to zero when idle — $0 compute charges when not in use.
    • RDS free tier (Option A) expires after 12 months and the instance runs continuously (always has charges after free tier expires).
    • Aurora Serverless v2 (Option B) can scale to zero but does not have a permanent free tier for compute.
    • DynamoDB (Option D) has a free tier but is NoSQL, not PostgreSQL-compatible.

    Question 5:

    A solutions architect is designing a multi-Region active-active database architecture using Aurora DSQL. The application serves users in the US and Europe. What is a key constraint the architect must consider?

    1. Multi-Region clusters can span any two AWS Regions globally
    2. Multi-Region clusters must be within the same continent/Region set — cross-continent clusters are not supported
    3. Only one Region can accept writes at a time; the other Region is read-only
    4. Multi-Region clusters require manual failover configuration
    Show Answer

    Answer: B –

    • Aurora DSQL multi-Region clusters must be created within the same Region set (US Regions, Asia Pacific Regions, or European Regions). Cross-continent multi-Region clusters are not currently supported.
    • The architect cannot create a cluster spanning US East and Europe — they would need separate single-Region clusters or a different approach for cross-continent active-active.
    • Option A is incorrect — cross-continent is not supported.
    • Option C is incorrect — both Regions accept concurrent reads AND writes (active-active).
    • Option D is incorrect — Aurora DSQL provides automatic failure recovery with no manual failover.

    Frequently Asked Questions

    What is Amazon Aurora DSQL?

    Aurora DSQL is a serverless, distributed SQL database that provides PostgreSQL compatibility with active-active multi-Region replication, strong consistency, and 99.999% availability — all without managing infrastructure.

    How does Aurora DSQL differ from Aurora Global Database?

    Aurora Global Database uses a primary-secondary model with async replication (1-second lag). DSQL provides active-active multi-Region writes with strong consistency and optimistic concurrency control, meaning both Regions can accept writes simultaneously.

    Is Aurora DSQL compatible with PostgreSQL?

    Yes, DSQL is wire-compatible with PostgreSQL and supports standard SQL. However, it has some limitations — it doesn’t support stored procedures, triggers, sequences, or advisory locks due to its distributed architecture.

    Related Posts

    References