Database

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

    AWS Certified Database – Specialty (DBS-C01) Exam Learning Path

    AWS Database - Specialty Certificate
    ~ Last updated on : ~ jayendrapatil ~ 19 Comments

    AWS Certified Database – Specialty (DBS-C01) Exam Learning Path

    ⚠️ CERTIFICATION RETIRED

    AWS Certified Database – Specialty (DBS-C01) was retired on April 30, 2024. The last day to take this exam was April 29, 2024.

    Certifications earned before retirement remain active for the standard three-year period but cannot be renewed.

    Recommended Alternatives:

    This content remains valuable as a study guide for AWS database services regardless of certification status.

    I recently revalidated my AWS Certified Database – Specialty (DBS-C01) certification just before it expired. The format and domains are pretty much the same as the previous exam, however, it has been enhanced to cover a lot of new services.

    AWS Certified Database – Specialty (DBS-C01) Exam Content

    AWS Certified Database – Specialty (DBS-C01) exam validates your understanding of databases, including the concepts of design, migration, deployment, access, maintenance, automation, monitoring, security, and troubleshooting, and covers the following tasks:

    • Understand and differentiate the key features of AWS database services.
    • Analyze needs and requirements to design and recommend appropriate database solutions using AWS services

    Refer to AWS Database – Specialty Exam Guide

    DBS-C01 Domains

    AWS Certified Database – Specialty (DBS-C01) Exam Summary

    • Specialty exams are tough, lengthy, and tiresome. Most of the questions and answers options have a lot of prose and a lot of reading that needs to be done, so be sure you are prepared and manage your time well.
    • DBS-C01 exam has 65 questions to be solved in 170 minutes which gives you roughly 2 1/2 minutes to attempt each question.
    • DBS-C01 exam includes two types of questions, multiple-choice and multiple-response.
    • DBS-C01 has a scaled score between 100 and 1,000. The scaled score needed to pass the exam is 750.
    • Specialty exams currently cost $ 300 + tax.
    • You can get an additional 30 minutes if English is your second language by requesting Exam Accommodations. It might not be needed for Associate exams but is helpful for Professional and Specialty ones.
    • As always, mark the questions for review, move on, and come back to them after you are done with all.
    • As always, having a rough architecture or mental picture of the setup helps focus on the areas that you need to improve. Trust me, you will be able to eliminate 2 answers for sure and then need to focus on only the other two. Read the other 2 answers to check the difference area and that would help you reach the right answer or at least have a 50% chance of getting it right.
    • AWS exams can be taken either remotely or online, I prefer to take them online as it provides a lot of flexibility. Just make sure you have a proper place to take the exam with no disturbance and nothing around you.
    • Also, if you are taking the AWS Online exam for the first time try to join at least 30 minutes before the actual time as I have had issues with both PSI and Pearson with long wait times.

    AWS Certified Database – Specialty (DBS-C01) Exam Resources

    AWS Certified Data Engineer – Associate (DEA-C01)

    💡 Recommended Replacement Certification

    The AWS Certified Data Engineer – Associate (DEA-C01) launched in March 2024 and is the closest active certification covering database and data services.

    • Exam domains: Data Ingestion & Transformation (34%), Data Store Management (26%), Data Operations & Support (22%), Data Security & Governance (18%)
    • Format: 65 questions, 130 minutes, $150 + tax, passing score 720
    • Key services: DynamoDB, Aurora, RDS, Redshift, S3, Glue, Kinesis, MSK, Lake Formation, DMS

    AWS Database Services – Study Summary

    • AWS Certified Database – Specialty exam focuses completely on AWS Data services from relational, non-relational, graph, caching, and data warehousing. It also covers deployments, automation, migration, security, monitoring, and troubleshooting aspects of them.

    Database Services

    • Make sure you know and cover all the services in-depth, as 80% of the exam is focused on topics like Aurora, RDS, DynamoDB
    • DynamoDB
      • is a fully managed NoSQL database service providing single-digit millisecond latency.
      • DynamoDB provisioned throughput supports On-demand and provisioned throughput capacity modes.
        • On-demand mode
          • provides a flexible billing option capable of serving thousands of requests per second without capacity planning
          • does not support reserved capacity
          • [Updated 2024] AWS reduced DynamoDB on-demand pricing by 50% (November 2024), making on-demand mode significantly more cost-effective.
        • Provisioned mode
          • requires you to specify the number of reads and writes per second as required by the application
          • Understand the provisioned capacity calculations
      • DynamoDB Auto Scaling uses the AWS Application Auto Scaling service to dynamically adjust provisioned throughput capacity on your behalf, in response to actual traffic patterns.
      • Know DynamoDB Burst capacity, Adaptive capacity
      • DynamoDB Consistency mode determines the manner and timing in which the successful write or update of a data item is reflected in a subsequent read operation of that same item.
        • supports eventual and strongly consistent reads.
        • Eventual requires less throughput but might return stale data, whereas, Strongly consistent reads require higher throughput but would always return correct data.
      • DynamoDB secondary indexes provide efficient access to data with attributes other than the primary key.
        • LSI uses the same partition key but a different sort key, whereas, GSI is a separate table with a different partition key and/or sort key.
        • GSI can cause primary table throttling if under-provisioned.
        • Make sure you understand the difference between the Local Secondary Index and the Global Secondary Index
      • DynamoDB Global Tables is a multi-active, cross-region replication capability of DynamoDB to support data access locality and regional fault tolerance for database workloads.
      • DynamoDB Time to Live – TTL enables a per-item timestamp to determine when an item is no longer needed. (hint: know TTL can expire the data and this can be captured by using DynamoDB Streams)
      • DynamoDB cross-region replication allows identical copies (called replicas) of a DynamoDB table (called master table) to be maintained in one or more AWS regions.
      • DynamoDB Streams provides a time-ordered sequence of item-level changes made to data in a table.
      • DynamoDB Triggers (just like database triggers) is a feature that allows the execution of custom actions based on item-level updates on a table.
      • DynamoDB Accelerator – DAX is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement even at millions of requests per second.
        • DAX does not support fine-grained access control like DynamoDB.
      • DynamoDB Backups support PITR
        • AWS Backup can be used to backup and restore, and it supports cross-region snapshot copy as well.
      • VPC Gateway Endpoints provide private access to DynamoDB from within a VPC without the need for an internet gateway or NAT gateway
      • Understand DynamoDB Best practices (hint: selection of keys to avoid hot partitions and creation of LSI and GSI)
      • [New 2024] DynamoDB supports zero-ETL integration with Amazon Redshift (GA October 2024), enabling near real-time analytics on DynamoDB data without building ETL pipelines.
    • Aurora
      • is a relational database engine that combines the speed and reliability with the simplicity and cost-effectiveness of open-source databases.
      • provides MySQL and PostgreSQL compatibility
      • Aurora Disaster Recovery & High Availability can be achieved using Read Replicas with very minimal downtime.
        • Aurora promotes read replicas as per the priority tier (tier 0 is the highest), the largest size if the tier matches
      • Aurora Global Database provides cross-region read replicas for low-latency reads. Remember it is not multi-master and would not provide low latency writes across regions as DynamoDB Global tables.
      • Aurora Connection endpoints support
        • Cluster for primary read/write
        • Reader for read replicas
        • Custom for a specific group of instances
        • Instance for specific single instance – Not recommended
      • Aurora Fast Failover techniques
        • set TCP keepalives low
        • set Java DNS caching timeouts low
        • Set the timeout variables used in the JDBC connection string as low
        • Use the provided read and write Aurora endpoints
        • Use cluster cache management for Aurora PostgreSQL. Cluster cache management ensures that application performance is maintained if there’s a failover.
      • Aurora Serverless is an on-demand, autoscaling configuration for the MySQL-compatible and PostgreSQL-compatible editions of Aurora.
        • [Updated 2024-2025] Aurora Serverless v2 now supports scaling from 0 to 256 ACUs (Aurora Capacity Units). Scale-to-zero (November 2024) eliminates costs during inactivity, while the 256 ACU maximum (October 2024) supports larger workloads.
        • [New 2025] Aurora Serverless v2 platform version 4 delivers up to 30% better performance and 45% faster scaling at no additional cost.
      • Aurora Backtrack feature helps rewind the DB cluster to the specified time. It is not a replacement for backups.
      • Aurora Server Auditing Events for different activities cover log-in, DML, permission changes DCL, schema changes DDL, etc.
      • Aurora Cluster Cache management feature which helps fast failover
      • Aurora Clone feature which allows you to create quick and cost-effective clones
      • Aurora supports fault injection queries to simulate various failovers like node down, primary failover, etc.
      • RDS PostgreSQL and MySQL can be migrated to Aurora, by creating an Aurora Read Replica from the instance. Once the replica lag is zero, switch the DNS with no data loss
      • Aurora Database Activity Streams help stream audit logs to external services like Kinesis
      • Supports stored procedures calling lambda functions
      • [New 2024] Aurora PostgreSQL Limitless Database (GA November 2024) enables horizontal write scaling by distributing workloads across multiple Aurora writer instances while maintaining single-database semantics and transactional consistency.
      • [New 2024] Aurora supports zero-ETL integration with Amazon Redshift, enabling near real-time analytics without building ETL pipelines.
    • Relational Database Service (RDS)
      • provides a relational database in the cloud with multiple database options.
      • RDS Snapshots, Backups, and Restore
        • restoring a DB from a snapshot does not retain the parameter group and security group
        • automated snapshots cannot be shared. Make a manual backup from the snapshot before sharing the same.
      • RDS Read Replicas
        • allow elastic scaling beyond the capacity constraints of a single DB instance for read-heavy database workloads.
        • increased scalability and database availability in the case of an AZ failure.
        • supports cross-region replicas.
      • RDS Multi-AZ provides high availability and automatic failover support for DB instances.
      • Understand the differences between RDS Multi-AZ vs Read Replicas
        • Multi-AZ failover can be simulated using Reboot with Failure option
        • Read Replicas require automated backups enabled
      • [New] RDS Multi-AZ DB Cluster deployments provide a primary and two readable standby instances across three AZs, offering lower write latency, faster failover (~35 seconds), and readable standbys compared to traditional Multi-AZ.
      • Understand DB components esp. DB parameter group, DB options groups
        • Dynamic parameters are applied immediately
        • Static parameters need manual reboot.
        • Default parameter group cannot be modified. Need to create custom parameter group and associate to RDS
        • Know max connections also depends on DB instance size
      • RDS Custom automates database administration tasks and operations. while making it possible for you as a database administrator to access and customize the database environment and operating system.
      • RDS Performance Insights is a database performance tuning and monitoring feature that helps you quickly assess the load on the database, and determine when and where to take action.
      • RDS Security
        • RDS supports security groups to control who can access RDS instances
        • RDS supports data at rest encryption and SSL for data in transit encryption
        • RDS supports IAM database authentication with temporary credentials.
        • Existing RDS instance cannot be encrypted, create a snapshot -> encrypt it –> restore as encrypted DB
        • RDS PostgreSQL requires rds.force_ssl=1 and sslmode=ca/verify-full to enable SSL encryption
        • Know RDS Encrypted Database limitations
      • Understand RDS Monitoring and Notification
        • Know RDS supports notification events through SNS for events like database creation, deletion, snapshot creation, etc.
        • CloudWatch gathers metrics about CPU utilization from the hypervisor for a DB instance, and Enhanced Monitoring gathers its metrics from an agent on the instance.
        • Enhanced Monitoring metrics are useful to understand how different processes or threads on a DB instance use the CPU.
        • RDS Performance Insights is a database performance tuning and monitoring feature that helps illustrate the database’s performance and help analyze any issues that affect it
      • RDS instance cannot be stopped if with read replicas
      • [New 2024] RDS supports zero-ETL integration with Amazon Redshift for MySQL and PostgreSQL, enabling near real-time analytics.
      • [New 2026] RDS now supports ENA Express for Multi-AZ replication, improving replication performance through multiple network paths.
    • ElastiCache
      • is a managed web service that helps deploy and run Memcached or Redis protocol-compliant cache clusters in the cloud easily.
      • Understand the differences between Redis vs. Memcached
      • [New 2024] ElastiCache now supports Valkey, a community-driven, open-source fork of Redis. Valkey is the recommended engine on ElastiCache with 33% lower Serverless pricing and 20% lower node-based pricing than other engines.
      • [Updated 2026] Valkey 9.0 is now available for ElastiCache, offering improved performance. Valkey has become the default high-performance key-value datastore across major cloud providers.
      • [New] ElastiCache Serverless enables creating a cache in under a minute with automatic scaling based on traffic patterns, eliminating the need to right-size clusters.
    • Neptune
      • is a fully managed database service built for the cloud that makes it easier to build and run graph applications. Neptune provides built-in security, continuous backups, serverless compute, and integrations with other AWS services.
      • provides Neptune loader to quickly import data from S3
      • supports VPC endpoints
      • [New 2024] Neptune Analytics provides a serverless graph analytics engine for running algorithms on large graphs without managing infrastructure. Supports NetworkX integration for Python-based graph workflows.
      • Neptune Serverless automatically scales capacity based on workload demands.
    • Amazon Keyspaces (for Apache Cassandra) is a scalable, highly available, and managed Apache Cassandra–compatible database service.
    • Amazon Quantum Ledger Database (Amazon QLDB) is a fully managed ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log.
      ⚠️ Amazon QLDB reached End of Support on July 31, 2025. All data not migrated was permanently deleted. AWS recommends migrating to Amazon Aurora PostgreSQL for audit use cases using the ledger functionality with cryptographic verification.
    • Redshift
      • is a fully managed, fast, and powerful, petabyte-scale data warehouse service. It is not covered in depth.
      • Know Redshift Best Practices w.r.t selection of Distribution style, Sort key, importing/exporting data
        • COPY command which allows parallelism, and performs better than multiple COPY commands
        • COPY command can use manifest files to load data
        • COPY command handles encrypted data
      • Know Redshift cross region encrypted snapshot copy
        • Create a new key in destination region
        • Use CreateSnapshotCopyGrant to allow Amazon Redshift to use the KMS key from the destination region.
        • In the source region, enable cross-region replication and specify the name of the copy grant created.
      • Know Redshift supports Audit logging which covers authentication attempts, connections and disconnections usually for compliance reasons.
      • [New 2024-2025] Redshift supports zero-ETL integrations from Aurora MySQL/PostgreSQL, RDS MySQL, DynamoDB, and SaaS applications (Salesforce, SAP, Zendesk), eliminating the need for custom ETL pipelines.
      • [New] Redshift Serverless provides automatic scaling and pay-per-use pricing without managing clusters.
    • Data Migration Service (DMS)
      • DMS helps in migration of homogeneous and heterogeneous database
      • DMS with Full load plus Change Data Capture (CDC) migration capability can be used to migrate databases with zero downtime and no data loss.
      • DMS with SCT (Schema Conversion Tool) can be used to migrate heterogeneous databases.
      • Premigration Assessment evaluates specified components of a database migration task to help identify any problems that might prevent a migration task from running as expected.
      • Multiserver assessment report evaluates multiple servers based on input that you provide for each schema definition that you want to assess.
      • DMS provides support for data validation to ensure that your data was migrated accurately from the source to the target.
      • DMS supports LOB migration as a 2-step process. It can do a full or limited LOB migration
        • In full LOB mode, AWS DMS migrates all LOBs from source to target regardless of size. Full LOB mode can be quite slow.
        • In limited LOB mode, a maximum LOB size can be set that AWS DMS should accept. Doing so allows AWS DMS to pre-allocate memory and load the LOB data in bulk. LOBs that exceed the maximum LOB size are truncated and a warning is issued to the log file. In limited LOB mode, you get significant performance gains over full LOB mode.
        • Recommended to use limited LOB mode whenever possible.
      • [New 2024] DMS Homogeneous Data Migrations is a serverless feature for like-to-like migrations (e.g., PostgreSQL to Aurora PostgreSQL) that uses native database tooling. No replication instances to manage. Supports PostgreSQL, MySQL, MariaDB, and MongoDB.
      • [New 2024] DMS Schema Conversion now uses generative AI to automatically convert up to 90% of schema objects from commercial databases to PostgreSQL.
      • [Deprecated 2026] AWS DMS Fleet Advisor reached end of support on May 20, 2026.

    Security, Identity & Compliance

    • Identity and Access Management (IAM)
    • Key Management Services
      • is a managed encryption service that allows the creation and control of encryption keys to enable data encryption.
      • provides data at rest encryption for the databases.
    • AWS Secrets Manager
      • protects secrets needed to access applications, services, etc.
      • enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle
      • supports automatic rotation of credentials for RDS, DocumentDB, etc.
    • Secrets Manager vs. Systems Manager Parameter Store
      • Secrets Manager supports automatic rotation while SSM Parameter Store does not
      • Parameter Store is cost-effective as compared to Secrets Manager.
    • Trusted Advisor provides RDS Idle instances

    Management & Governance Tools

    • Understand AWS CloudWatch for Logs and Metrics.
      • EventBridge (CloudWatch Events) provides real-time alerts
      • CloudWatch can be used to store RDS logs with a custom retention period, which is indefinite by default.
      • CloudWatch Application Insights support .Net and SQL Server monitoring
    • Know CloudFormation for provisioning, in terms of
      • Stack drifts – to understand the difference between current state and on actual environment with any manual changes
      • Change Set – allows you to verify the changes before being propagated
      • parameters – allows you to configure variables or environment-specific values
      • Stack policy defines the update actions that can be performed on designated resources.
      • Deletion policy for RDS allows you to configure if the resources are retained, snapshot, or deleted once destroy is initiated
      • Supports secrets manager for DB credentials generation, storage, and easy rotation
      • System parameter store for environment-specific parameters

    Whitepapers and articles

    On the Exam Day

    • Make sure you are relaxed and get some good night’s sleep. The exam is not tough if you are well-prepared.
    • If you are taking the AWS Online exam
      • Try to join at least 30 minutes before the actual time as I have had issues with both PSI and Pearson with long wait times.
      • The online verification process does take some time and usually, there are glitches.
      • Remember, you would not be allowed to take the take if you are late by more than 30 minutes.
      • Make sure you have your desk clear, no hand-watches, or external monitors, keep your phones away, and nobody can enter the room.

    Finally, All the Best 🙂