A production-like test environment has an Aurora PostgreSQL writer and an eligible reader in different Availability Zones. The application connects to the cluster endpoint without RDS Proxy.
During an approved failover test, measure application reconnection and successful writes. Database role switching alone is not the recovery criterion.
Which TWO actions should the team take for this test?
Run a planned writer failover, measure reconnection and resumed writes, and correlate DB connection counts and RDS events with application failure records.
Detailed explanation
Actually switch the writer and observe failed existing connections, reconnection, and successful writes. Distinguish the cluster endpoint update from the time when the application becomes usable.
Actually switch the writer and observe failed existing connections, reconnection, and successful writes. Distinguish the cluster endpoint update from the time when the application becomes usable.
Updating the endpoint does not migrate existing TCP connections to the new writer. Discard failed connections and verify new connections and writes, including DNS caching, timeout, and retry behavior.
Updating the endpoint does not migrate existing TCP connections to the new writer. Discard failed connections and verify new connections and writes, including DNS caching, timeout, and retry behavior.
Restarting a reader does not substitute for actually promoting it to writer. Use FailoverDBCluster for the intended writer switch and verify the role change and connection recovery.
Restarting a reader does not substitute for actually promoting it to writer. Use FailoverDBCluster for the intended writer switch and verify the role change and connection recovery.
DatabaseConnections counts client network connections to the DB instance, not application errors. Correlating application measurements and events identifies failures and recovery that connection counts alone cannot show.
DatabaseConnections counts client network connections to the DB instance, not application errors. Correlating application measurements and events identifies failures and recovery that connection counts alone cannot show.
Database availability alone does not verify that the application connection pool has refreshed or that writes succeed. Measure the impact observed by application users separately.
Database availability alone does not verify that the application connection pool has refreshed or that writes succeed. Measure the impact observed by application users separately.
Check official documentation
Compare the following points with the official documentation.
In the test environment, run FailoverDBCluster and record the role change, application reconnection, successful writes, and DB connection counts on a shared timeline.
Official references
What to confirm
Confirm a connection to the new writer and successful writes, recording elapsed application recovery time and failed requests.
Key points
- Aurora failover
- DatabaseConnections
- Connection retry
Notes
- Environment: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- Reviewed against the linked AWS documentation on 2026-10-10.
Foundation review
Separate writer switching from application recovery
In this configuration, FailoverDBCluster promotes an eligible reader to writer. Establish new connections through the cluster endpoint after the role change and measure through successful writes. Existing TCP connections do not migrate automatically; test connection pools, DNS caching, timeouts, and retries too.
Do not equate DB connections with application error rates
AWS/RDS DatabaseConnections counts client network connections to each DB instance. Select DBInstanceIdentifier and align measurements with RDS events. Measure application error rates, failed requests, retries, and successful writes in the application, publishing custom metrics if needed. Connection counts alone do not establish successful recovery.
Define the scope of the test result
Prepare a reader in another AZ and test with approved workload and environment conditions. Record failover start, connection failures, and resumed writes, then compare with the objective. A planned test establishes behavior for that configuration and workload; it does not guarantee the same recovery time or an SLA for every real outage.