Examkin

Question

Difficulty: Very hardEnhancing Reliability and Disaster Recovery

An enterprise runs a critical tier-1 transaction application across two AWS regions: us-east-1 (Primary, Account A) and us-west-2 (Recovery, Account B). The us-east-1 VPC deploys an Amazon Aurora PostgreSQL database, an Application Load Balancer (ALB), and Amazon ECS tasks on AWS Fargate. Outbound internet traffic from Fargate in us-east-1 is routed via redundant NAT Gateways. In us-west-2, a warm standby environment is deployed, utilizing a single NAT Gateway to reduce idle costs, and an Aurora PostgreSQL cross-region read replica.

Internal services resolve the database using a Route 53 Private Hosted Zone (PHZ) in Account A. During a disaster recovery (DR) drill, two issues are identified:
1. Internal microservices in Account B cannot resolve the database endpoint using the PHZ, causing connection failures.
2. A simulated database crash in us-east-1 did not trigger external DNS failover to us-west-2, as Route 53 continued routing traffic to the us-east-1 ALB because the ALB itself remained healthy.

The business requires a recovery time objective (RTO) of less than 15 minutes, a recovery point objective (RPO) of less than 1 minute, and high availability during failover.

Which combination of actions should a solutions architect recommend to resolve these issues and satisfy the RTO and RPO requirements?

  1. Configure AWS Route 53 Application Recovery Controller (ARC) routing controls linked to Route 53 health checks. Create a Route 53 Private Hosted Zone association authorization in Account A for the us-west-2 VPC in Account B, and associate the VPC. Deploy redundant NAT Gateways across multiple Availability Zones in us-west-2. Convert the database to an Amazon Aurora Global Database.Answer
  2. B
    Configure Route 53 active-passive failover with a health check linked to a CloudWatch alarm monitoring database connectivity. Share the Private Hosted Zone from Account A to Account B using AWS Resource Access Manager (RAM) to allow VPC resolution. Deploy redundant NAT Gateways in us-west-2. Convert the database to an Amazon Aurora Global Database.
  3. C
    Configure Route 53 active-passive failover with a health check linked to a CloudWatch alarm monitoring database connectivity. Create a Route 53 Private Hosted Zone association authorization in Account A for the us-west-2 VPC, and associate the VPC. Keep the single NAT Gateway in us-west-2 to control standby costs. Convert the database to an Amazon Aurora Global Database.
  4. D
    Configure Route 53 failover routing by enabling 'Evaluate Target Health' on the us-east-1 ALB alias record. Create a Route 53 Private Hosted Zone association authorization in Account A for the us-west-2 VPC, and associate the VPC. Deploy redundant NAT Gateways in us-west-2. Retain the Aurora cross-region read replica and configure an AWS Lambda function triggered by Amazon CloudWatch database metrics to promote the replica during failover.

Answer

The correct approach is to configure AWS Route 53 Application Recovery Controller (ARC) routing controls linked to Route 53 health checks, create a Route 53 Private Hosted Zone association authorization in Account A for the us-west-2 VPC in Account B and associate the VPC, deploy redundant NAT Gateways across multiple Availability Zones in us-west-2, and convert the database to an Amazon Aurora Global Database.
The correct response addresses all RTO, RPO, and high availability constraints. Converting the database to an Amazon Aurora Global Database ensures physical replication lag remains under a second, meeting the RPO of less than 1 minute. Utilizing Route 53 Private Hosted Zone association authorizations resolves cross-account internal DNS queries correctly, as AWS Resource Access Manager does not support Route 53 Private Hosted Zones. Deploying redundant NAT Gateways across Availability Zones in the recovery region avoids a single point of failure during failover. Finally, managing failover through AWS Route 53 Application Recovery Controller (ARC) routing controls ensures failover executes cleanly when the backend database becomes degraded, avoiding the failure mode where Route 53 continues routing traffic to a healthy ALB that has lost database connectivity.

Step-by-Step Solution

1
Select replication method to achieve RPO < 1 minute.
Amazon Aurora Global Database provides storage-based physical replication that achieves typical replication lag of less than 1 second, meeting the RPO requirement.
Standard cross-region read replicas use asynchronous logical replication, which can experience high replication lag under load, and their promotion is a manual or script-driven process that can exceed RTO and RPO limits.
2
Resolve cross-account Private Hosted Zone (PHZ) resolution.
Authorize the VPC in Account B to associate with the PHZ in Account A using the AWS CLI or Route 53 API, then accept the association in Account B.
Route 53 Private Hosted Zones cannot be shared via AWS Resource Access Manager (RAM); cross-account association requires a two-step authorization and association process.
3
Address high availability of egress traffic in the recovery region.
Replace the single NAT Gateway in us-west-2 with redundant NAT Gateways deployed across all utilized Availability Zones.
A single NAT Gateway creates a single point of failure (SPOF) for outbound internet traffic from ECS tasks on AWS Fargate in the event of an Availability Zone outage.
4
Configure DNS failover routing behavior.
Use Route 53 Application Recovery Controller (ARC) routing controls or custom health checks linked to application/database health metrics.
Relying on Route 53 ALB alias records with Evaluate Target Health enabled fails to detect database outages because the ALB and its targets remain healthy even when the backend database is down.

Key Concept

Multi-region disaster recovery orchestration with cross-account Route 53 DNS private hosted zone resolution, Aurora Global Database physical replication, and network redundancy.
Estimated Time:3m 0s
Rate this question

Topics

Enhancing Reliability and Disaster Recovery