An enterprise operates a multi-tier application across two AWS accounts in an AWS Organization. The production deployment is in VPC-A within the us-east-1 region, and the disaster recovery (DR) site is in VPC-B within the us-west-2 region. The database tier uses an Amazon Aurora PostgreSQL Global Database, with the primary cluster in VPC-A and a secondary replica cluster in VPC-B. For internal communication, the database cluster's endpoints are registered in a Route 53 Private Hosted Zone (PHZ) named db.internal.example.com created in the production account.
During a disaster recovery exercise, the Solutions Architect initiates a failover by promoting the secondary database cluster in us-west-2 to primary and updates the DNS records. Although the Aurora database cluster promotion is successful, the application servers in VPC-B fail to connect to db.internal.example.com, resulting in DNS resolution failures.
What is the root cause of this failure, and how should it be resolved to ensure reliable disaster recovery?
- AThe Route 53 failover routing policy was configured without associating an active Route 53 health check to the primary database record, preventing Route 53 from updating the private DNS records to point to the promoted database cluster.
- BThe disaster recovery strategy selected for the Aurora PostgreSQL Global Database is a pilot light pattern, which has a target RTO that exceeds the duration of the DR exercise, causing replication lag to block database connection requests during promotion.
- The Route 53 Private Hosted Zone is not associated with VPC-B. To resolve this, authorize the association of VPC-B with the Private Hosted Zone from the production account, and then associate VPC-B with the Private Hosted Zone from the disaster recovery account.Cevap
- DThe database connection timed out because VPC-B was configured with a single NAT Gateway in one Availability Zone, which became overloaded and failed under the sudden traffic spike during the regional failover.