Read traffic to an Aurora cluster is increasing and the primary's write performance must be protected.
The application should use a read endpoint that distributes reads to replicas.
Which design is most appropriate?
Create Aurora Replicas and use the Aurora reader endpoint so read traffic is distributed away from the writer.
Detailed explanation
The reader endpoint balances read connections across Aurora Replicas and protects the primary writer.
The reader endpoint balances read connections across Aurora Replicas and protects the primary writer.
DNS weights do not provide Aurora connection pooling or replica-aware read distribution.
DNS weights do not provide Aurora connection pooling or replica-aware read distribution.
A snapshot is stored data and does not accept live SQL queries.
A snapshot is stored data and does not accept live SQL queries.
All read load would remain on the primary and would not scale reads separately.
All read load would remain on the primary and would not scale reads separately.
Check official documentation
Compare the following points with the official documentation.
Amazon Aurora ReplicasとReader Endpointの公式説明を確認する。
What to confirm
書き込み系と読み取り系のエンドポイントを使い分けられる。
Key points
- Aurora Replicas
- Reader endpoint
- Read scaling
Notes
- Environment: AWS公式Auroraドキュメントの確認
- Confirm current AWS service behavior in the official documentation.
Foundation review
Read/write separation
The reader endpoint serves read traffic while the writer endpoint remains for writes.
DNS is not pooling
Route 53 can resolve names but does not implement Aurora-aware database connection pooling.