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

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

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