4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

Database tiers represent the stateful core of modern cloud architectures and are traditionally the most difficult components to scale. Unlike stateless compute tiers that scale horizontally behind a load balancer in minutes, database scalability involves data replication, storage volume management, transaction serialization, and partition distribution. The AWS Certified CloudOps Engineer – Associate exam requires deep operational mastery of horizontal scaling in Amazon RDS, decoupled storage and compute in Amazon Aurora, instant elasticity in Aurora Serverless v2, and partition mechanics in Amazon DynamoDB.

Amazon RDS Horizontal Scaling & Read Replicas

Amazon Relational Database Service (RDS) supports traditional relational engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). While vertical scaling modifies the DB instance class (requiring a brief outage during reboot), horizontal scaling offloads read-intensive traffic using Read Replicas.

Read Replica Architecture & Mechanics

Read replicas leverage native asynchronous replication (e.g., MySQL binary logs or PostgreSQL Write-Ahead Logs):

• Asynchronous Replication: Writes committed on the primary instance are streamed asynchronously to replicas. Because replication is asynchronous, replicas cannot guarantee immediate consistency with the primary.
• Workload Offloading: Replicas possess independent DNS endpoints. Applications route write traffic (INSERT, UPDATE, DELETE) to the primary writer while directing heavy reporting, BI dashboards, and read-only API calls to replica endpoints.
• Cross-Region Read Replicas: Replicas can be provisioned in another AWS Region, delivering low-latency local reads for global users and serving as a cross-Region disaster recovery (DR) target.
• Promoting Read Replicas: A replica can be promoted to a standalone read-write database (aws rds promote-read-replica), permanently severing replication. This is a core mechanism for DR failover and migration workflows.

Monitoring Replication Lag

CloudOps engineers monitor the ReplicaLag CloudWatch metric (measured in seconds). High lag indicates the replica trails behind the primary. Common causes include:

• Intense write volume on the primary exceeding replica write throughput.
• Undersized replica instance classes relative to the primary.
• Long-running analytical queries on the replica locking tables and stalling replication threads.

Multi-AZ Standby vs. Read Replica Distinction

• Multi-AZ Standby: Uses synchronous replication to a passive standby in a second AZ strictly for automated failover. The standby cannot accept read traffic.
• Read Replica: Uses asynchronous replication to active secondary instances that serve read traffic. Replicas do not provide automated failover unless part of an Aurora cluster.

Amazon Aurora Scaling & Architecture

Amazon Aurora is a cloud-native relational engine compatible with MySQL and PostgreSQL that decouples compute from underlying storage.

Aurora Storage Auto Scaling

Unlike RDS, which requires upfront EBS provisioning and storage modification cooldowns, Aurora uses a distributed, log-structured Cluster Storage Volume:

• Replication: Aurora writes data 6-ways across three Availability Zones.
• Automatic Expansion: Storage scales automatically in 10 GiB increments up to 128 TiB as data grows, with zero downtime, zero performance degradation, and zero manual intervention.

Aurora Read Replicas & Shared Volume

Aurora clusters support up to 15 Aurora Replicas. Unlike RDS replicas—which maintain separate EBS storage volumes and duplicate data via logical logs—all Aurora replicas share the exact same underlying cluster storage volume:

• Minimal Replication Lag: Because replicas read directly from the shared cluster storage volume rather than replaying logical logs, AWS documents replica lag as usually much less than 100 milliseconds after the writer commits an update. Lag rises during heavy write bursts, so monitor the AuroraReplicaLag CloudWatch metric rather than assuming a fixed figure.
• Automated Failover Targets: Any Aurora replica can serve as an automatic failover target, promoting to primary writer in under 30 seconds with zero data loss.
• Endpoints: The Cluster Endpoint routes to the primary writer, the Reader Endpoint load-balances queries round-robin across available replicas, and Custom Endpoints isolate specific replica groups for dedicated workloads.
• Aurora Auto Scaling: Automatically adds or removes Aurora Replicas based on CloudWatch metrics (RDSMetric:CPUUtilization or RDSMetric:DatabaseConnections).

Aurora Serverless v2

Aurora Serverless v2 provides instant compute auto-scaling for transactional workloads, measured in Aurora Capacity Units (ACUs) (1 ACU ≈ 2 GiB RAM, corresponding CPU, and network bandwidth):

• Scales across a capacity range of 0 to 256 ACUs, in increments as small as 0.5 ACU. The ceiling available to a given cluster depends on its engine and platform version: older versions support 0.5-128, newer versions support 0.5-256, and current versions support 0-256, where a minimum of 0 ACUs enables automatic pause and resume on an idle cluster.
• Scales compute and memory in fractions of a second in-place, without dropping database connections or interrupting transactions.
• Supports mixed clusters combining provisioned writer instances with Serverless v2 reader instances for cost-optimized burst handling.

Amazon DynamoDB Scaling & Partition Mechanics

Amazon DynamoDB is a fully managed, serverless NoSQL key-value and document database delivering single-digit millisecond latency at any scale.

Capacity Modes: Provisioned vs. On-Demand

• Provisioned Capacity Mode: The engineer explicitly defines Read Capacity Units (RCUs) and Write Capacity Units (WCUs). 1 RCU delivers 1 strongly consistent read/sec (or 2 eventually consistent reads/sec) for items up to 4 KB; 1 WCU delivers 1 write/sec for items up to 1 KB. Paired with Application Auto Scaling to scale throughput between defined bounds based on target utilization (e.g., 70%).
• On-Demand Capacity Mode: Fully serverless scaling that accommodates unpredictable workloads with zero capacity planning. Accommodates up to previous peak traffic instantly, and can double peak throughput within 30 minutes, charging strictly per request unit.

Physical Partitions & Hot Partition Mitigation

DynamoDB divides data across physical partitions, each with hard architectural limits:

• Maximum storage: 10 GB
• Maximum throughput: 1,000 WCUs and 3,000 RCUs

A Hot Partition occurs when application queries concentrate on a single partition key (e.g., a popular event ID). If write traffic to that key exceeds 1,000 WCUs, DynamoDB throttles requests with ProvisionedThroughputExceededException, even if total table capacity is largely idle. Engineers mitigate hot partitions by:

• Redesigning partition keys for high cardinality (e.g., UUIDs).
• Implementing write sharding: appending random or calculated suffixes (e.g., EventId_1..N) to spread writes across multiple physical partitions.

DynamoDB Accelerator (DAX)

For read-intensive workloads requiring microsecond latency, DynamoDB Accelerator (DAX) provides a fully managed in-memory cache cluster. DAX sits directly before DynamoDB, implements write-through caching, and absorbs repetitive read spikes from hot keys to protect underlying partition RCUs.