Amazon DVA-C02: Databases & Caching (RDS, Aurora, ElastiCache, Timestream, Proxy) — Study Guide
Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
RDS and Aurora: design, scaling, and encryption
Designing relational databases on RDS or Aurora starts with the workload tradeoffs between single-node provisioned RDS and Aurora’s distributed storage. Choose Aurora when you need high read scale and fast failover: Aurora replicas share the cluster volume so promotion is quick, while RDS MySQL/Postgres read replicas use asynchronous binlog-based replication and can lag. For scaling reads, add read replicas and point application read traffic to them; use reader endpoints in Aurora to automatically balance among replicas. For writes, vertical scale (instance class) and careful schema/index design matter. Always enable encryption at rest with a KMS CMK at creation time — enabling encryption later requires snapshot/restore into a new encrypted instance; that’s a common trap. For in-transit protection, enforce TLS/SSL connections (RDS provides CA bundles). For credentials, prefer AWS Secrets Manager with automatic rotation using the built-in RDS rotation Lambda template; programmatically fetch secrets with SecretsManager.getSecretValue() in SDKs. Consider IAM DB authentication to remove static passwords: generate a token via RDS.Signer (SDK) or rds.generate-db-auth-token, then connect with a short-lived token. Instrument using Performance Insights, Enhanced Monitoring, and CloudWatch; use slow query logs and EXPLAIN for hotspots.
Connection pooling, RDS Proxy, and serverless patterns
Serverless functions and connection-heavy apps commonly exhaust DB connection limits. The straightforward pattern in Node.js is to place a mysql2/promise pool in the Lambda global scope and reuse it across invocations, but this doesn’t solve massive concurrent scaling. RDS Proxy is the managed answer: create the proxy with create_db_proxy, associate it with Secrets Manager secrets and target RDS/Aurora instances, and use the proxy endpoint from your app. RDS Proxy handles connection multiplexing, IAM authentication integration, and failover. For serverless Aurora Serverless or when you prefer HTTP-style calls, use the RDS Data API: rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) lets Lambdas run SQL without persistent TCP connections. A common gotcha is mixing Data API with provisioned clusters — Data API is intended for serverless clusters and has different latency/transaction semantics. Also be aware that RDS Proxy introduces a connection pool timeout and max_connections; tune the idle client timeout and connection borrowing for Lambda bursts. Use SecretsManager.getSecretValue() for credentials and rotate with rotateSecret or enable automatic rotation in console/SDK.
Caching strategies: ElastiCache, DAX, and cache design
Caching choices hinge on the data store and access patterns. For DynamoDB, DAX provides microsecond read latency and transparent SDK integration via the AmazonDaxClient that wraps DynamoDB.DocumentClient; it’s ideal for read-heavy, eventually-consistent workloads. For relational or arbitrary key-value caching, use ElastiCache Redis for advanced data structures, persistence (AOF/RDB snapshots), replication, and cluster-mode sharding, or Memcached for simple, horizontally scalable caching. Implement cache-aside for reads and write-through/write-behind only when acceptable for consistency and complexity. Key design is critical: prefix keys by application and version, use sensible TTLs, and avoid unbounded cardinality. Handle cache stampedes with lock-and-refresh patterns (SETNX or Redlock) or probabilistic early TTL refresh. Configure Redis with multi-AZ and automatic failover; create replication groups with automatic failover and snapshots via CreateReplicationGroup. Common traps include stale caches after writes, not invalidating on schema changes, and expecting absolute consistency. Monitor cache hit ratio and eviction metrics in CloudWatch and scale node types or cluster shards when memory or CPU becomes a bottleneck.
Time-series with Timestream and read-replica patterns
Amazon Timestream is purpose-built for time-series: ingest using WriteRecords API from the SDK with batched WriteRecords calls and query with TimestreamQuery.query(sql). Design your record schema with dimensions of low cardinality and use multi-measure records to reduce write amplification. Configure memory and magnetic retention rules per table to keep recent data hot and cheaply store older data; adjusting retention is critical because memory tier retention size affects cost and query performance. For analytics, use time-series specific queries (time_bin or bin) and push down filters on dimensions to minimize scanned data. When integrating time-series with relational stores, offload historical immutable data to Timestream and serve hot metadata from RDS/Aurora with ElastiCache. For relational read scaling, add read replicas and route read-only traffic; for Aurora, use reader endpoints and examine replica lag (CloudWatch ReplicaLag) before routing critical reads. A common developer gotcha is high cardinality in Timestream or caching keys produced per-request, which balloons storage and hurts performance. Use batching for writes and asynchronous ingestion pipelines (Kinesis, Firehose) to smooth peaks and avoid throttling.
Practical Problem: Use-Case Scenario
Scenario: NovaShop runs a multi-region ecommerce platform in AWS using Aurora MySQL for orders in us-east-1, with Lambda-based APIs and a global customer catalog in DynamoDB. Developers use CI/CD in a single AWS account and store DB credentials in Secrets Manager.
Challenge: During sales spikes, Lambda functions exhaust DB connections and the catalog needs microsecond reads; developers must preserve security with rotated credentials and minimal latency for product reads.
Recommended Approach:
- Create an RDS Proxy for the Aurora cluster using CreateDBProxy, link the Secrets Manager secret ARN, and configure IAM authentication; update Lambda to use the proxy endpoint and SecretsManager.getSecretValue() for credentials.
- For the catalog, deploy an Amazon DAX cluster and switch the DynamoDB client to AmazonDaxClient({endpoints}) that wraps the DynamoDB DocumentClient for microsecond reads.
- Enable Secrets Manager automatic rotation for the Aurora secret using the RDS rotation Lambda template (rotate-secret or configure via console) and ensure Lambda IAM role can call secretsmanager:GetSecretValue.
- Add an ElastiCache Redis cluster (cluster mode) for session caching and implement cache-aside with TTLs and a SETNX refresh lock to prevent stampedes.
Rationale: Using RDS Proxy prevents connection storms from Lambda scaling while IAM/Secrets Manager protects credentials with automated rotation; DAX provides microsecond DynamoDB reads and ElastiCache handles transient session/read caching, aligning with serverless scaling and security best practices.
← Storage · All domains · Messaging →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →