RDS

Amazon RDS Blue/Green Deployments

RDS Blue/Green Deployment
~ Last updated on : ~ jayendrapatil

Amazon RDS Blue/Green Deployments

  • Amazon RDS Blue/Green Deployments help make and test database changes before implementing them in a production environment.
  • RDS Blue/Green Deployment has the blue environment as the current production environment and the green environment as the staging environment.
  • RDS Blue/Green Deployment creates a staging or green environment that exactly copies the production environment.
  • Green environment is a copy of the topology of the production environment and includes the features used by the DB instance including the Multi-AZ deployment, read replicas, the storage configuration, DB snapshots, automated backups, Performance Insights, and Enhanced Monitoring.
  • Green environment or the staging environment always stays in sync with the current production environment using logical replication.
  • RDS DB instances in the green environment can be changed without affecting production workloads. Changes can include the upgrade of major or minor DB engine versions, upgrade of underlying file system configuration, or change of database parameters in the staging environment.
  • Changes can be thoroughly tested in the green environment and when ready, the environments can be switched over to promote the green environment to be the new production environment.
  • Switchover typically takes under a minute with no data loss and no need for application changes.
  • Blue/Green Deployments are currently supported only for RDS for MariaDB, MySQL, and PostgreSQL.

RDS Blue/Green Deployment

RDS Blue/Green Deployments Benefits

  • Easily create a production-ready staging environment.
  • Automatically replicate database changes from the production environment to the staging environment.
  • Test database changes in a safe staging environment without affecting the production environment.
  • Stay current with database patches and system updates.
  • Implement and test newer database features.
  • Switch over your staging environment to be the new production environment without changes to your application.
  • Safely switch over through the use of built-in switchover guardrails.
  • Eliminate data loss during switchover.
  • Switch over quickly, typically under a minute depending on your workload.

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.

References

Amazon_Blue_Green_Deployments

RDS Automated Backups vs Manual Snapshots

RDS Automated Backups vs Manual Snapshots
~ Last updated on : ~ jayendrapatil ~ 1 Comment

RDS Automated Backups vs Manual Snapshots

  • Amazon RDS Automated Backups are AWS Initiated. Backups are created automatically as per the defined backup window. Backups are also created when a read replica is created.
  • Amazon RDS DB snapshots are manual, user-initiated backups that enable a DB instance backup to be restored to that specific state at any time.

RDS Automated Backups vs Manual Snapshots

Instance Deletion & Backup Retention Period

  • Amazon RDS Backups can be configured with a retention period varying from 0 to 35 days. Setting to 0 disables automated backups (not recommended for production).
  • RDS Automated Backups are deleted when the DB instance is deleted. However, RDS can be configured to retain the automated backups on RDS instance deletion. These backups would be retained only till their retention window.
  • RDS Snapshots don’t expire and RDS keeps all manual DB snapshots until explicitly deleted and aren’t subject to the backup retention period.

Backup Mode

  • RDS Automated Backups are incremental. The first snapshot of a DB instance contains the data for the full database. Subsequent backups of the same database are incremental, meaning only the data that has changed after the most recent backup is saved.
  • RDS Manual Snapshots are also incremental. Only the blocks on the device that have changed after the most recent snapshot are saved, reducing both the time to create the snapshot and storage costs by not duplicating data.

Point In Time Recovery – PITR

  • RDS Automated Backups with transaction logs help support Point In Time Recovery – PITR. You can restore your DB instance to any second during the retention period, up to the LatestRestorableTime (typically within the last 5 minutes).
  • RDS Snapshots restores to saved snapshot data only. It cannot be used for PITR.

Sharing

  • RDS Automated Backups cannot be shared directly. You can copy the automated backup to a manual snapshot to share.
  • RDS Manual Snapshots can be shared with the public and with up to 20 other AWS Accounts.

Cross-Region & Cross-Account Capabilities

  • Cross-Region Automated Backup Replication – RDS can replicate automated backups (snapshots and transaction logs) to a chosen destination AWS Region, enabling PITR in a secondary Region for disaster recovery. You can replicate up to 20 backups to each destination Region per account.
  • Cross-Region and Cross-Account Snapshot Copy (2025) – RDS now supports copying snapshots across Regions and accounts directly using a single copy action, eliminating the need for sequential copying steps.
  • AWS Backup Single-Action Copy (Oct 2025) – AWS Backup supports copying RDS, Aurora, Neptune, and DocumentDB snapshots across Regions and accounts in a single action.

AWS Backup Integration

  • AWS Backup provides centralized backup management for RDS with custom schedules, retention periods, and lifecycle policies beyond native RDS backup capabilities.
  • AWS Backup Vault Lock – Provides WORM (Write Once Read Many) immutability for backups, preventing any user from deleting backups or changing lifecycle settings. Helps meet compliance requirements.
  • Logically Air-Gapped Vault (GA Aug 2024) – A specialized vault type that stores immutable backup copies in service-owned accounts, encrypted with AWS-owned keys. Supports secure sharing across accounts and direct restore for faster recovery.
  • Multi-AZ Cluster Support (March 2026) – AWS Backup expanded support for RDS Multi-AZ clusters to 17 Regions, including automated lifecycle management and immutable backups with Vault Lock.

Backup Configuration on Restore (Feb 2026)

  • RDS and Aurora now allow you to view and modify the backup retention period and preferred backup window prior to and upon restoring database snapshots, providing visibility into backup configurations before initiating restore operations.

Use case

  • RDS Automated Backups are good for disaster recovery and compliance requirements with PITR capability.
  • Cross-Region Automated Backup Replication is ideal for cross-region disaster recovery with minimal RPO.
  • RDS Snapshots can be used for checkpoint before making large changes, non-production/test environments, and final copy before deleting a database.
  • AWS Backup with Vault Lock is recommended for ransomware protection and regulatory compliance requiring immutable backups.

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. You receive a frantic call from a new DBA who accidentally dropped a table containing all your customers. Which Amazon RDS feature will allow you to reliably restore your database within 5 minutes of when the mistake was made?
    1. Multi-AZ RDS
    2. RDS snapshots
    3. RDS read replicas
    4. RDS automated backup
  2. A company requires that their RDS database backups be protected from accidental or malicious deletion, including from administrators with root access. Which AWS solution provides immutable backup protection?
    1. RDS automated backups with 35-day retention
    2. RDS manual snapshots shared to another account
    3. AWS Backup with Vault Lock in compliance mode
    4. Cross-Region automated backup replication
  3. A company needs to restore their RDS database in a secondary AWS Region if the primary Region becomes unavailable, with a Recovery Point Objective (RPO) of minutes. Which feature should they use?
    1. Manual snapshot copy to another Region
    2. Cross-Region Automated Backup Replication
    3. RDS Read Replica in another Region
    4. AWS Backup with cross-account copy

References

RDS Cross-Region Read Replicas – DR & Latency

Cross-Region Read Replicas
~ Last updated on : ~ jayendrapatil

RDS Cross-Region Read Replicas

  • RDS Cross-Region Read Replicas create an asynchronously replicated read-only DB instance in a secondary AWS Region.
  • Supported for MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server
  • Cross-Region Read Replicas help to improve
    • disaster recovery capabilities (reduces RTO and RPO),
    • scale read operations into a region closer to end users,
    • migration from a data center in one region to another region

Cross-Region Read Replicas

RDS Cross-Region Read Replicas Process

  • RDS configures the source DB instance as a replication source and setups the specified read replica in the destination AWS Region.
  • RDS creates an automated DB snapshot of the source DB instance in the source AWS Region.
  • RDS begins a cross-Region snapshot copy for the initial data transfer.
  • RDS then uses the copied DB snapshot for the initial data load on the read replica. When the load is complete the DB snapshot copy is deleted.
  • RDS starts by replicating the changes made to the source instance since the start of the create read replica operation.

RDS Cross-Region Read Replicas Considerations

  • A source DB instance can have cross-region read replicas in multiple AWS Regions.
  • Replica lags are higher for Cross-region replicas. This lag time comes from the longer network channels between regional data centers.
  • RDS can’t guarantee more than five cross-region read replica instances, due to the limit on the number of access control list (ACL) entries for a VPC
  • Read Replica uses the default DB parameter group and DB option group for the specified DB engine when configured from AWS console.
  • Read Replica uses the default security group.
  • Cross-Region RDS read replica can be created from a source RDS DB instance that is not a read replica of another RDS DB instance for Microsoft SQL Server, Oracle, and PostgreSQL DB instances. This limitation doesn’t apply to MariaDB and MySQL DB instances.
  • Deleting the source for a cross-region read replica will result in
    • read replica promotion for MariaDB, MySQL, and Oracle DB instances
    • no read replica promotion for PostgreSQL DB instances and the replication status of the read replica is set to terminated.

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 company has HQ in Tokyo and branch offices worldwide and is using logistics software with a multi-regional deployment on AWS in Japan, Europe, and US. The logistic software has a 3-tier architecture and uses MySQL 5.6 for data persistence. Each region has deployed its database. In the HQ region, you run an hourly batch process reading data from every region to compute cross-regional reports that are sent by email to all offices this batch process must be completed as fast as possible to optimize logistics quickly. How do you build the database architecture to meet the requirements?
    1. For each regional deployment, use RDS MySQL with a master in the region and a read replica in the HQ region
    2. For each regional deployment, use MySQL on EC2 with a master in the region and send hourly EBS snapshots to the HQ region
    3. For each regional deployment, use RDS MySQL with a master in the region and send hourly RDS snapshots to the HQ region
    4. For each regional deployment, use MySQL on EC2 with a master in the region and use S3 to copy data files hourly to the HQ region

AWS RDS Multi-AZ DB Instance

RDS Multi-AZ Instance Deployment
~ Last updated on : ~ jayendrapatil ~ 2 Comments

RDS Multi-AZ DB Instance Deployment

  • RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different AZ.
  • RDS performs an automatic failover to the standby, so that database operations can be resumed as soon as the failover is complete.
  • RDS Multi-AZ deployment maintains the same endpoint for the DB Instance after a failover, so the application can resume database operation without the need for manual administrative intervention.
  • Multi-AZ is a High Availability feature and NOT a scaling solution for read-only scenarios; a standby replica can’t be used to serve read traffic. To service read-only traffic, use a Read Replica or consider Multi-AZ DB Cluster deployment which provides readable standbys.
  • Multi-AZ deployments for MariaDB, MySQL, Oracle, PostgreSQL, and RDS Custom for SQL Server DB instances use Amazon failover technology. SQL Server DB instances use SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs). SQL Server 2022 Web Edition supports Multi-AZ through block-level replication.

RDS Multi-AZ Instance Deployment

  • In a Multi-AZ deployment,
    • RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone.
    • Copies of data are stored in different AZs for greater levels of data durability.
    • Primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide
      • data redundancy,
      • eliminate I/O freezes during snapshots and backups
      • and minimize latency spikes during system backups.
    • DB instances may have increased write and commit latency compared to a Single AZ deployment, due to the synchronous data replication
    • Transaction success is returned only if the commit is successful both on the primary and the standby DB
    • There might be a change in latency if the deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones.
  • When using the BYOL licensing model, a license for both the primary instance and the standby replica is required
  • For production workloads, it is recommended to use Multi-AZ deployment with Provisioned IOPS and DB instance classes optimized for Provisioned IOPS (e.g., current-generation M5, M6g, M6i, R5, R6g, R6i, or newer Graviton-based instances) for fast, consistent performance.
  • When Single-AZ deployment is modified to a Multi-AZ deployment (for engines other than SQL Server or Amazon Aurora)
    • RDS takes a snapshot of the primary DB instance from the deployment and restores the snapshot into another Availability Zone.
    • RDS then sets up synchronous replication between the primary DB instance and the new instance.
    • This avoids downtime during conversion from Single AZ to Multi-AZ.
  • An existing Single AZ instance can be converted into a Multi-AZ instance by modifying the DB instance without any downtime.

ENA Express for Multi-AZ Replication (2026)

  • As of May 2026, Amazon RDS Multi-AZ instances use ENA Express for replication traffic between Availability Zones.
  • ENA Express uses AWS’s Scalable Reliable Datagram (SRD) protocol to optimize network performance.
  • Delivers up to 25 Gbps single-flow bandwidth for cross-AZ replication traffic with advanced congestion control and multi-pathing capabilities.
  • Reduces latency variability for Multi-AZ deployments and delivers increased write throughput and lower write latencies for write-intensive workloads.
  • SRD improves replication by dynamically distributing traffic across multiple network paths and adapting to congestion in real time.
  • Available at no additional charge for RDS for MariaDB, MySQL, PostgreSQL, Db2, and Oracle.
  • To enable on existing instances, perform a start-stop or scale compute action.

RDS Multi-AZ Failover Process

  • In the event of a planned or unplanned outage of the DB instance,
    • RDS automatically switches to a standby replica in another AZ, if enabled for Multi-AZ.
    • The time taken for the failover to complete depends on the database activity and other conditions at the time the primary DB instance became unavailable.
    • Failover times are typically 60-120 secs. However, large transactions or a lengthy recovery process can increase failover time.
    • Failover mechanism automatically changes the DNS record of the DB instance to point to the standby DB instance.
    • DNS propagation can take up to 35 seconds to complete during failover.
    • Multi-AZ switch is seamless to the applications as there is no change in the endpoint URLs but just needs to re-establish any existing connections to the DB instance.
  • RDS handles failover automatically so that database operations can be resumed as quickly as possible without administrative intervention.
  • Primary DB instance switches over automatically to the standby replica if any of the following conditions occur:
    • Primary Availability Zone outage
    • Loss of network connectivity to primary
    • Primary DB instance fails
    • DB instance’s server type is changed
    • Operating system of the DB instance is undergoing software patching
    • Compute unit failure on the primary
    • Storage failure on the primary
    • A manual failover of the DB instance was initiated using Reboot with failover (also referred to as Forced Failover)
  • If the Multi-AZ DB instance has failed over, can be determined by
    • DB event subscriptions can be set up to notify you via email or SMS that a failover has been initiated.
    • DB events can be viewed via the Amazon RDS console or APIs.
    • The current state of the Multi-AZ deployment can be viewed via the RDS console and APIs.

RDS Proxy for Faster Failover

  • Amazon RDS Proxy can significantly reduce failover downtime for Multi-AZ DB instance deployments.
  • RDS Proxy eliminates the 35-second DNS propagation delay by continuously monitoring both primary and standby instances, allowing it to bypass DNS propagation entirely.
  • As of Dec 2024, AWS has optimized the planned failover process with RDS Proxy:
    • Modify instance class — downtime reduced by up to 4.9x (MariaDB), 4.3x (MySQL), 3.3x (PostgreSQL)
    • OS upgrades — downtime reduced by up to 4.8x (MySQL), 4x (MariaDB), 3.4x (PostgreSQL)
    • Reboot with force failover — downtime reduced by up to 3x (MariaDB), 2.5x (MySQL), 1.5x (PostgreSQL)
  • During maintenance operations, RDS performs maintenance on the standby first, then does a planned failover, then completes maintenance on the old primary — minimizing overall downtime.
  • These improvements are available for RDS for MySQL, MariaDB, and PostgreSQL with no changes needed to workloads.

Multi-AZ DB Instance vs Multi-AZ DB Cluster

RDS Multi-AZ DB Instance vs DB Cluster

  • Multi-AZ DB Instance: One primary + one standby (standby NOT readable). Failover typically 60-120 seconds.
  • Multi-AZ DB Cluster: One writer + two reader instances in three AZs. Readers can serve read traffic. Failover typically under 35 seconds. Supports MySQL and PostgreSQL only.
  • Multi-AZ DB Cluster provides improved commit latency, faster failover, readable standby instances, and lower write latency compared to Multi-AZ DB Instance deployment.
  • Choose Multi-AZ DB Cluster when you need both read scaling and fast failover in a single managed deployment.

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.

References

AWS Storage Options – RDS, DynamoDB & Database on EC2

~ Last updated on : ~ jayendrapatil ~ 17 Comments

AWS Storage Options Whitepaper with RDS, DynamoDB & Database on EC2 Cont.

Provides a brief summary for the Ideal Use cases, Anti-Patterns and other factors for Amazon RDS, DynamoDB & Databases on EC2 storage options

📝 Note: The original AWS Storage Services Overview whitepaper has been archived by AWS. This content is maintained and updated with current service capabilities for certification study reference. See the AWS Overview – Storage Services for the latest official guidance.

Amazon RDS

  • RDS is a fully managed relational database service supporting Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server database engines
  • RDS eliminates much of the administrative overhead associated with launching, managing, and scaling your own relational database on Amazon EC2 or in another computing environment.
  • RDS provides automated patching, backups, Multi-AZ high availability, read replicas, and monitoring out of the box.

Key Features (Updated 2024-2026)

  • Multi-AZ DB Cluster Deployments – deploys a primary and two readable standby instances across three AZs, providing faster failover (~35 seconds), improved commit latency via semisynchronous replication, and readable standbys (MySQL/PostgreSQL)
  • Blue/Green Deployments – creates a fully managed staging (green) environment that mirrors production (blue), allowing safe testing of major version upgrades and schema changes with minimal downtime switchover
  • RDS Proxy – a fully managed database proxy that pools and shares connections, improving application scalability, resilience to database failovers, and security via IAM/Secrets Manager authentication
  • RDS Data API – available for Aurora (Serverless v2 and provisioned), enables secure HTTP-based SQL execution without managing database drivers or connections
  • Aurora Serverless v2 – auto-scales database capacity in fine-grained increments based on application demand, scaling to hundreds of thousands of transactions per second
  • Aurora DSQL (launched Dec 2024) – a serverless, distributed SQL database with active-active multi-Region high availability, PostgreSQL-compatible, with strong consistency across all Regional endpoints
  • RDS Custom – provides OS and database access for Oracle and SQL Server when full administrative control is needed (Note: RDS Custom for Oracle reaches end of support March 31, 2027)
  • Graviton (ARM) Instances – M7g, R7g, M7i, R7i instance types offering better price-performance
  • gp3 Storage – baseline of 3,000 IOPS and 125 MiB/s, scalable up to 80,000 IOPS and 2,000 MiB/s per volume (up to 64 TiB per volume)
  • Extended Support – up to 3 additional years of critical security and bug fixes beyond community end-of-life for major engine versions

Ideal Usage Patterns

  • RDS is a great solution for cloud-based fully-managed relational database
  • RDS is also optimal for new applications with structured data that requires more sophisticated querying and joining capabilities than that provided by Amazon’s NoSQL database offering, DynamoDB.
  • RDS provides full compatibility with the databases supported and direct access to native database engines, code and libraries and is ideal for existing applications that rely on these databases
  • Applications requiring zero-downtime upgrades can leverage Blue/Green Deployments for safe major version changes
  • Serverless and event-driven applications benefit from RDS Proxy and Aurora Serverless v2 for connection management and auto-scaling

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate for this needs
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images, etc), it is a better choice to use S3 to store the objects instead of database engines Blob feature and use RDS or DynamoDB only to save the metadata
  • Automated scalability
    • RDS provides vertical scaling (scale up) and limited horizontal scale-out via read replicas. For fully-automated serverless scaling, consider Aurora Serverless v2 or DynamoDB.
  • Complete control
    • RDS does not provide full OS-level admin access.
    • If the application requires complete OS-level control, consider RDS Custom (for Oracle/SQL Server) or a self-managed database on EC2.
  • Other database platforms
    • RDS supports Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server.
    • If any other database platform (such as IBM DB2, Informix, or Sybase) is needed, it should be deployed on a self-managed database on an EC2 instance.

Performance

  • RDS offers multiple storage types optimized for different workloads:
    • gp3 (General Purpose SSD) – baseline 3,000 IOPS, scalable up to 80,000 IOPS and 2,000 MiB/s throughput, up to 64 TiB per volume
    • io1/io2 (Provisioned IOPS SSD) – designed for I/O-intensive transactional workloads, up to 256,000 IOPS
  • Multi-AZ DB Cluster deployments provide improved write commit latency through optimized semisynchronous replication
  • Performance Insights provides a dashboard to monitor database load and identify bottlenecks
  • RDS Optimized Reads/Writes (Aurora) provide up to 2x faster query processing and 6x higher write throughput

Durability and Availability

  • RDS leverages Amazon EBS volumes as its data store
  • RDS provides database backups, for enhanced durability, which are replicated across multiple AZ’s
    • Automated backups
      • RDS automatically performs a full daily backup during the specified backup window, and captures DB transaction logs (up to 35-day retention)
    • User initiated backups (DB Snapshots)
      • User can initiate manual snapshots at any time; they are retained until explicitly deleted
  • Multi-AZ DB Instance – synchronously replicates data to a standby in another AZ with automatic failover (typically 60-120 seconds)
  • Multi-AZ DB Cluster – maintains a primary and two readable standbys across three AZs with faster failover (~35 seconds) and transaction log-based replication
  • RDS provides a DNS endpoint; in case of failure on the primary, it automatically fails over to the standby instance
  • RDS Read Replicas provide asynchronous replication for read scaling and can be promoted for disaster recovery (including cross-Region replicas)

Cost Model

  • RDS offers a tiered pricing structure based on instance size, deployment type (Single-AZ/Multi-AZ Instance/Multi-AZ Cluster), and AWS Region
  • Pricing components: DB instance hours, provisioned storage (per GB-month), I/O requests (for io1/io2), additional backup storage, and data transfer
  • Reserved Instances provide significant discounts (up to 69%) for 1-year or 3-year commitments
  • Aurora Serverless v2 charges per Aurora Capacity Unit (ACU) consumed per second

Scalability and Elasticity

  • RDS resources can be scaled in several dimensions: storage size, IOPS, instance compute capacity, and number of read replicas
  • Storage Auto Scaling automatically increases storage when approaching capacity limits
  • Aurora Auto Scaling automatically adjusts the number of Aurora Replicas based on demand
  • Aurora Serverless v2 scales compute capacity automatically in fine-grained increments (0.5 ACU) from minimum to maximum configured capacity
  • Read Replicas (up to 15 for Aurora, 5 for other engines) enable read scaling across AZs and Regions
  • Aurora Limitless Database provides horizontal write scaling by automatically sharding data across multiple writer instances

Interfaces

  • RDS APIs, AWS CLI, and the AWS Management Console provide management interfaces for creating, modifying, and managing DB instances
  • RDS Data API (Aurora) provides a secure HTTP endpoint for running SQL statements without managing database connections or drivers
  • Once a database is created, RDS provides a DNS endpoint for the database which can be used to connect using standard database drivers
  • Endpoint does not change over the lifetime of the instance, even during failover in Multi-AZ configurations
  • RDS Proxy endpoints provide connection pooling and improved failover handling for applications

Amazon DynamoDB

  • Amazon DynamoDB is a fully managed, serverless NoSQL database service that delivers single-digit millisecond performance at any scale.
  • DynamoDB offers zero infrastructure management, zero downtime maintenance, and automatic scaling to accommodate any workload demand.
  • DynamoDB provides both eventually-consistent reads (by default) and strongly-consistent reads (optional), as well as ACID transactions (TransactWriteItems, TransactGetItems) for coordinated operations across multiple items and tables.
  • Amazon DynamoDB handles data as follows:
    • DynamoDB stores structured data in tables, indexed by primary key, and allows low-latency read and write access to items.
    • DynamoDB supports rich data types: Scalar (String, Number, Binary, Boolean, Null), Document (List, Map), and Set (String Set, Number Set, Binary Set)
    • Tables do not have a fixed schema, so each data item can have a different number of attributes.
    • Primary key can either be a single-attribute partition key (hash key) or a composite partition key + sort key (hash-range key).
    • Local Secondary Indexes (LSI) – alternate sort key on the same partition key (defined at table creation)
    • Global Secondary Indexes (GSI) – alternate partition key and optional sort key, can be added/modified anytime

Key Features (Updated 2024-2026)

  • On-Demand Capacity Mode – pay-per-request pricing with no capacity planning; automatically scales to accommodate workload demand. 50% price reduction effective November 2024.
  • Global Tables – fully managed, multi-Region, multi-active replication with two consistency modes:
    • Multi-Region Eventual Consistency (MREC) – default mode, typically sub-second replication
    • Multi-Region Strong Consistency (MRSC) – GA 2025, provides zero RPO with strongly consistent reads/writes across all Regions
  • DynamoDB Accelerator (DAX) – fully managed, in-memory cache providing microsecond read latency for read-heavy workloads
  • Standard-IA Table Class – lower storage cost option (up to 60% cheaper storage) for infrequently accessed data
  • PartiQL – SQL-compatible query language for DynamoDB, enabling familiar SELECT, INSERT, UPDATE, DELETE syntax
  • Zero-ETL Integrations – seamless data replication to Amazon Redshift, OpenSearch Service, and SageMaker Lakehouse without building ETL pipelines
  • S3 Import/Export – bulk import data from S3 and export table data to S3 in DynamoDB JSON or Amazon Ion format
  • Point-in-Time Recovery (PITR) – continuous backups with per-second granularity, restorable to any point within a configurable 1-35 day window
  • Encryption at Rest – enabled by default using AWS owned keys, with options for AWS managed key or customer managed KMS key
  • DynamoDB Streams / Kinesis Data Streams – capture item-level changes for event-driven architectures, real-time analytics, and cross-Region replication

Ideal Usage Patterns

  • DynamoDB is ideal for applications that need a flexible NoSQL database with low read and write latencies, and the ability to scale storage and throughput up or down as needed without code changes or downtime.
  • Use cases requiring a highly available and scalable database e.g., mobile apps, gaming, digital ad serving, live voting, sensor networks, log ingestion, access control, metadata storage for S3 objects, e-commerce shopping carts, web session management, and serverless applications
  • Event-driven architectures leveraging DynamoDB Streams to trigger Lambda functions or downstream processing
  • Global applications requiring multi-Region active-active deployments with Global Tables

Anti-Patterns

  • Structured data with Join and/or Complex Transactions
    • If the application uses structured data and requires complex joins, multi-table transactions, or relationship infrastructure provided by traditional relational databases, RDS or Aurora would be a better choice. (Note: DynamoDB does support ACID transactions within and across tables, but not SQL-style joins.)
  • Large Blob data
    • DynamoDB has a maximum item size of 400 KB. For large media files, videos, etc., use S3 for storage and DynamoDB for metadata.
  • Large Objects with Low I/O rate
    • DynamoDB uses SSD drives and is optimized for high I/O workloads. If the application stores very large amounts of infrequently accessed data, S3 or the Standard-IA table class might be more cost-effective.
  • Complex ad-hoc analytics
    • For complex analytical queries across large datasets, use DynamoDB zero-ETL integration with Amazon Redshift or export to S3 for Athena queries.

Performance

  • SSDs and limited indexing on attributes provides single-digit millisecond latency at any scale.
  • Provisioned capacity mode – define exact read/write capacity units for predictable workloads with optional auto-scaling
  • On-demand capacity mode – automatically accommodates up to double previous peak traffic instantly, with further scaling within minutes
  • DAX (DynamoDB Accelerator) – in-memory cache providing microsecond response times for eventually consistent reads
  • DynamoDB automatically partitions data to maintain consistent performance as tables grow.

Durability and Availability

  • DynamoDB automatically and synchronously replicates data across three AZs in a Region for high availability and data protection against facility failures.
  • Global Tables provide multi-Region replication with 99.999% availability SLA (multi-Region)
  • PITR provides continuous backups for point-in-time restore capability
  • On-demand backups allow full table backups at any time without performance impact

Cost Model

  • DynamoDB offers two capacity modes:
    • On-Demand – pay per read/write request (no capacity planning). 50% price reduction since November 2024.
    • Provisioned – pay per hour for provisioned Read/Write Capacity Units (with optional auto-scaling and Reserved Capacity discounts)
  • Additional pricing components: data storage (per GB-month), Global Tables replication (per replicated write unit), backups, data export/import, DynamoDB Streams reads, and data transfer
  • Standard-IA table class reduces storage costs by up to 60% with higher per-request costs (ideal when storage dominates)
  • Global Tables pricing reduced by up to 67% (November 2024)

Scalability and Elasticity

  • DynamoDB is both highly-scalable and elastic with virtually unlimited storage and throughput capacity.
  • Data is automatically partitioned and re-partitioned as needed, while SSD storage provides predictable low-latency at any scale.
  • On-Demand mode provides truly serverless scaling with no capacity planning required
  • Provisioned mode with Auto Scaling automatically adjusts capacity based on utilization targets
  • DynamoDB can handle more than 10 trillion requests per day and support peaks of more than 100 million requests per second.

Interfaces

  • DynamoDB provides a low-level REST API, AWS SDKs in multiple languages, and the AWS CLI
  • PartiQL – SQL-compatible query language supported via Console, CLI, SDKs, and NoSQL Workbench
  • APIs provide both management and data interfaces: table management (create, list, delete, describe) and item operations (Get, Put, Update, Delete, Query, Scan, BatchWrite, BatchGet, TransactWrite, TransactGet)
  • DynamoDB Streams API – captures ordered sequence of item-level changes
  • NoSQL Workbench – visual tool for data modeling, visualization, and query development

Databases on EC2

  • EC2 with EBS volumes allows hosting a self-managed relational database with full OS and database administrative control
  • Ready-to-use, prebuilt AMIs are available from leading database vendors in AWS Marketplace
  • Note: With the introduction of RDS Custom (for Oracle and SQL Server), the need for self-managed databases on EC2 has decreased for these specific engines

Ideal Usage Patterns

  • Self-managed database on EC2 is ideal for applications that require a specific database platform not supported by Amazon RDS e.g., IBM DB2, Informix, Sybase, or specialized configurations
  • Applications requiring maximum level of administrative control and configurability including custom storage engines, specialized replication, or kernel-level tuning not available in RDS or RDS Custom
  • Database versions or configurations not yet supported by RDS

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images), use S3 for object storage and RDS or DynamoDB for metadata
  • Managed service available
    • If RDS supports the database engine and provides the needed features, RDS is preferred for reduced operational overhead. For Oracle/SQL Server requiring OS access, consider RDS Custom before self-managing on EC2.
  • Automated scalability
    • Self-managed databases require manual or scripted scaling operations. If fully-automated scaling is needed, DynamoDB, Aurora Serverless, or RDS with Auto Scaling may be better choices.

Performance

  • Performance depends on the EC2 instance type, number/configuration of EBS volumes, and database tuning
  • Scale up by choosing larger instance types (compute-optimized, memory-optimized) or Graviton-based instances for better price-performance
  • For storage: use gp3 or io2 Block Express EBS volumes. Use software RAID 0 (disk striping) across multiple EBS volumes for aggregated IOPS and bandwidth
  • Instance store (NVMe SSDs) can provide very high IOPS for temporary/cache workloads

Durability & Availability

  • Uses EBS for storage with same durability guarantees (99.999% availability for io2 Block Express)
  • Enhanced durability via EBS snapshots, cross-Region replication, or third-party backup tools (e.g., Oracle RMAN) to S3
  • High availability requires manual configuration: Multi-AZ replication, clustering solutions, or automated failover scripts

Cost Model

  • Cost determined by: EC2 instance size/type, EBS volume size and IOPS, data transfer, and any third-party database licensing costs
  • Savings Plans and Reserved Instances reduce EC2 compute costs for steady-state workloads
  • BYOL (Bring Your Own License) options available for Oracle, SQL Server, and other commercial databases

Scalability & Elasticity

  • Leverage EC2 scalability by creating AMIs for horizontal scaling, though database-specific clustering/sharding is required
  • Vertical scaling requires instance stop/start (brief downtime without clustering)
  • Auto Scaling groups can manage read replica fleets for read-heavy workloads

Comparison: RDS vs DynamoDB vs Database on EC2

Factor Amazon RDS DynamoDB Database on EC2
Type Managed Relational (SQL) Managed NoSQL (Key-Value/Document) Self-Managed Relational
Scaling Vertical + Read Replicas; Aurora Serverless for auto-scaling Fully automatic (on-demand) or provisioned with auto-scaling Manual vertical/horizontal
Availability Multi-AZ (2 or 3 AZs), automated failover Automatic across 3 AZs; Global Tables for multi-Region Manual HA configuration required
Admin Overhead Low (managed patching, backups) None (serverless) High (full responsibility)
Use Case Complex queries, joins, ACID transactions High-speed key-value access, flexible schema, massive scale Unsupported engines, full OS control

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. Which of the following are use cases for Amazon DynamoDB? Choose 3 answers
    1. Storing BLOB data.
    2. Managing web sessions
    3. Storing JSON documents
    4. Storing metadata for Amazon S3 objects
    5. Running relational joins and complex updates.
    6. Storing large amounts of infrequently accessed data.
  2. A client application requires operating system privileges on a relational database server. What is an appropriate configuration for highly available database architecture?
    1. A standalone Amazon EC2 instance
    2. Amazon RDS in a Multi-AZ configuration
    3. Amazon EC2 instances in a replication configuration utilizing a single Availability Zone
    4. Amazon EC2 instances in a replication configuration utilizing two different Availability Zones

    Note: With the introduction of RDS Custom, this question’s context has evolved. RDS Custom for SQL Server now supports Multi-AZ. However, for full OS-level control beyond what RDS Custom offers, EC2 remains the answer.

  3. You are developing a new mobile application and are considering storing user preferences in AWS, which would provide a more uniform cross-device experience to users using multiple mobile devices to access the application. The preference data for each user is estimated to be 50KB in size. Additionally 5 million customers are expected to use the application on a regular basis. The solution needs to be cost-effective, highly available, scalable and secure, how would you design a solution to meet the above requirements?
    1. Setup an RDS MySQL instance in 2 availability zones to store the user preference data. Deploy a public facing application on a server in front of the database to manage security and access credentials
    2. Setup a DynamoDB table with an item for each user having the necessary attributes to hold the user preferences. The mobile application will query the user preferences directly from the DynamoDB table. Utilize STS. Web Identity Federation, and DynamoDB Fine Grained Access Control to authenticate and authorize access (DynamoDB provides high availability as it synchronously replicates data across three facilities within an AWS Region and scalability as it is designed to scale its provisioned throughput up or down while still remaining available. Also suitable for storing user preference data)
    3. Setup an RDS MySQL instance with multiple read replicas in 2 availability zones to store the user preference data. The mobile application will query the user preferences from the read replicas. Leverage the MySQL user management and access privilege system to manage security and access credentials.
    4. Store the user preference data in S3 Setup a DynamoDB table with an item for each user and an item attribute pointing to the user’ S3 object. The mobile application will retrieve the S3 URL from DynamoDB and then access the S3 object directly utilize STS, Web identity Federation, and S3 ACLs to authenticate and authorize access.
  4. A customer is running an application in US-West (Northern California) region and wants to setup disaster recovery failover to the Asian Pacific (Singapore) region. The customer is interested in achieving a low Recovery Point Objective (RPO) for an Amazon RDS multi-AZ MySQL database instance. Which approach is best suited to this need?
    1. Synchronous replication
    2. Asynchronous replication (Cross-Region Read Replicas use asynchronous replication. Note: DynamoDB Global Tables with MRSC now offers zero RPO across Regions for NoSQL workloads.)
    3. Route53 health checks
    4. Copying of RDS incremental snapshots
  5. You are designing a file-sharing service. This service will have millions of files in it. Revenue for the service will come from fees based on how much storage a user is using. You also want to store metadata on each file, such as title, description and whether the object is public or private. How do you achieve all of these goals in a way that is economical and can scale to millions of users?
    1. Store all files in Amazon Simple Storage Service (S3). Create a bucket for each user. Store metadata in the filename of each object, and access it with LIST commands against the S3 API.
    2. Store all files in Amazon S3. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
    3. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Use a database running in Amazon Relational Database Service (RDS) to store the metadata.
    4. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
  6. Company ABCD has recently launched an online commerce site for bicycles on AWS. They have a “Product” DynamoDB table that stores details for each bicycle, such as, manufacturer, color, price, quantity and size to display in the online store. Due to customer demand, they want to include an image for each bicycle along with the existing details. Which approach below provides the least impact to provisioned throughput on the “Product” table?
    1. Serialize the image and store it in multiple DynamoDB tables
    2. Create an “Images” DynamoDB table to store the Image with a foreign key constraint to the “Product” table
    3. Add an image data type to the “Product” table to store the images in binary format
    4. Store the images in Amazon S3 and add an S3 URL pointer to the “Product” table item for each image
  7. A company needs to store IoT sensor data from thousands of devices. The data is small (under 1KB per reading), arrives at unpredictable rates, and must be queryable by device ID and timestamp with single-digit millisecond latency. Which database solution is most appropriate?
    1. Amazon RDS MySQL with Multi-AZ
    2. Self-managed Cassandra on EC2
    3. Amazon DynamoDB with on-demand capacity mode (DynamoDB with on-demand mode is ideal: handles unpredictable workloads without capacity planning, supports composite key (device ID as partition key, timestamp as sort key), and provides single-digit millisecond latency)
    4. Amazon Aurora Serverless
  8. A company wants to perform real-time analytics on data stored in their DynamoDB table without impacting production read/write performance. Which approach is the most operationally efficient?
    1. Create a read replica of the DynamoDB table
    2. Export data to S3 on a scheduled basis and query with Athena
    3. Use DynamoDB zero-ETL integration with Amazon Redshift (Zero-ETL integration provides near real-time data replication to Redshift without building custom pipelines or impacting DynamoDB performance)
    4. Use DynamoDB Streams with a Lambda function to copy data to RDS