Question

Difficulty: MediumEnhancing Reliability and Disaster Recovery

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?

  1. A
    The 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.
  2. B
    The 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.
  3. 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.Answer
  4. D
    The 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.

Answer

The root cause is that the Route 53 Private Hosted Zone was not associated with VPC-B. To resolve it, the owner of the Private Hosted Zone in the production account must authorize the cross-account VPC association, and the DR account must then associate VPC-B with the hosted zone.
The correct answer identifies that a Route 53 Private Hosted Zone (PHZ) is only accessible to VPCs that are explicitly associated with it. Since the PHZ is created in the production account and associated with VPC-A, it is not accessible to VPC-B in the disaster recovery account by default. To resolve this in a multi-account environment, the production account must authorize the association of VPC-B with the PHZ, and then the disaster recovery account must associate VPC-B with the PHZ. Once this association is established, the application servers in VPC-B will be able to resolve database endpoints using the PHZ.

Step-by-Step Solution

1
Verify DNS resolution from the disaster recovery VPC (VPC-B).
The application servers fail to resolve db.internal.example.com to any IP address.
By default, Route 53 Private Hosted Zones are only accessible to VPCs that have been explicitly associated with them.
2
Authorize the cross-account VPC association.
The production account authorizes VPC-B in the DR account to associate with the Private Hosted Zone.
AWS cross-account Route 53 Private Hosted Zone association requires explicit authorization from the hosting account before the association can be made.
3
Associate the VPC with the Private Hosted Zone from the DR account.
VPC-B is successfully associated with db.internal.example.com.
Once authorized, the DR account can submit the association request, allowing instances in VPC-B to resolve the database endpoints.

Key Concept

Cross-account and cross-VPC DNS resolution using Route 53 Private Hosted Zones for disaster recovery failover.
Estimated Time:2m 0s
Rate this question