LEARN. PRACTICE. GROW.Concept and mechanism
An RDS Multi-AZ DB instance deployment with a single standby uses that standby for availability, not for serving read queries. This differs from other models, including Multi-AZ DB clusters. RDS read replicas can help scale reads, but asynchronous replication permits lag. In Aurora with available replicas, the reader endpoint distributes connections among replicas; a thousand queries on one connection are not a thousand independent balancing decisions. The connection pool influences observed behavior and should be included in performance analysis.
Guided application
For DynamoDB, start with access patterns. A date used as the only partition key can concentrate all current writes. Distributing keys requires planning queries and aggregation to avoid replacing one problem with another. In a lazy-loading cache, a miss triggers an origin read and population; origin changes require a stale-data strategy. Define TTL, invalidation, and lag tolerance according to business needs. Before downsizing RDS, measure memory, I/O, connections, and critical periods; low average CPU does not demonstrate spare capacity in every dimension.
A user updates a record and immediately reads from a lagging replica. The old result may reflect replication lag; the read path must respect required consistency.
Common pitfalls
Using an instance standby as a read replica; assuming per-query balancing; hiding stale data behind indefinite TTL.
Related topics: Events, queues, and processing · Costs, commitments, and retirement
Choose availability and scale while preserving consistency requirements.
Reference: RDS read replicas · SAA-C03