Study guide
4.4 Managed Database Scaling: RDS, Aurora & DynamoDB
AWS Certified CloudOps Engineer – Associate SOA-C03
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Monitoring & Observability Infrastructure
1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms
2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation
2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda
3 Chapter 3: Performance Optimization for Compute, Storage & Databases
3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance
4 Chapter 4: Compute & Database Scalability and Elasticity
4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB
5 Chapter 5: High Availability, Fault Tolerance & Load Balancing
5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments
6 Chapter 6: Backup, Data Protection & Disaster Recovery
6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience
7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK
7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures
8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC
8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows
9 Chapter 9: Systems Manager & Event-Driven Operations Automation
9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation
10 Chapter 10: Identity, Access Management & Governance
10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs
11 Chapter 11: Data Security, Encryption & Vulnerability Management
11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings
12 Chapter 12: VPC Architecture, Endpoints & Network Protection
12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing
13 Chapter 13: DNS, Route 53 Routing & Content Delivery
13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator
14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity
14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting
4.4 Managed Database Scaling: RDS, Aurora & DynamoDB
Key Takeaways Explain This Topic AI
Amazon RDS Read Replicas offload read-heavy workloads using asynchronous replication and can be promoted to standalone primary databases for disaster recovery or migration.
Amazon Aurora decouples compute from its shared distributed cluster storage volume, auto-scaling storage in 10 GiB increments up to 128 TiB and supporting up to 15 replicas whose replication lag is usually well under 100 milliseconds.
Aurora Serverless v2 scales compute capacity dynamically in fine-grained Aurora Capacity Units across a 0-to-256 ACU range (a 0-ACU minimum enables automatic pause) in fractions of a second without dropping active connections or failing over.
DynamoDB On-Demand capacity mode accommodates spiky and unpredictable workloads instantly, while Provisioned Capacity mode pairs RCUs and WCUs with Application Auto Scaling for predictable traffic.
DynamoDB physical partitions enforce hard limits of 1,000 WCUs and 3,000 RCUs; hot partitions caused by low-cardinality keys require key redesign or write sharding, while DAX delivers microsecond read acceleration.
Last updated: September 2026
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.