Soru

Zorluk: ZorEnhancing Reliability and Disaster Recovery

An enterprise operates a multi-region application across two AWS accounts to support disaster recovery. Account A hosts the primary application infrastructure in the us-east-1 Region, including a public Application Load Balancer (ALB) and an Auto Scaling group of Amazon EC2 instances inside a VPC. Account B hosts the standby infrastructure in the us-west-2 Region with a similar configuration. A Route 53 public hosted zone, managed in a separate shared services account, routes external traffic to the ALBs using failover routing. Internal microservices in the primary VPC query a shared service using an internal domain name registered in a Route 53 Private Hosted Zone (PHZ) internal.corp hosted in Account A. During a disaster recovery simulation, the primary region was degraded due to backend database replication lag and EC2 instance failures, but the public ALB in us-east-1 remained operational. The simulation revealed two issues: 1. The public Route 53 failover record did not route traffic to the standby ALB in us-west-2 because the health check was configured to monitor the ALB's endpoint, which returned a 200 OK status from a static welcome page on the ALB itself. 2. The EC2 instances launched in Account B's VPC in us-west-2 were unable to resolve the internal domain names hosted in Account A's PHZ. Which combination of steps will resolve these issues and ensure a reliable, automated failover process?

  1. A
    Share the Route 53 Private Hosted Zone internal.corp from Account A to Account B using AWS Resource Access Manager (RAM). Configure the Route 53 public hosted zone to use latency-based routing, and disable 'Evaluate Target Health' on the alias records to prevent intermittent failovers caused by temporary database replication lag.
  2. B
    Establish a VPC Peering connection between Account A's VPC and Account B's VPC to automatically extend private DNS resolution of internal.corp across the accounts. Configure Route 53 Application Recovery Controller (ARC) routing controls for the public ALBs, but set up the routing controls without Route 53 health checks to prevent automated failover from occurring without manual operator confirmation.
  3. Create a VPC association authorization in Account A for the Private Hosted Zone internal.corp targeting the VPC in Account B, and then associate the VPC in Account B with the hosted zone. Configure a custom health check endpoint (such as /health) on the ALB target group that validates backend application and database connectivity, and enable 'Evaluate Target Health' on the Route 53 public alias failover records.Cevap
  4. D
    Attach a cross-account IAM role to Account B's EC2 instances that grants Route 53 read-only permissions to query the Private Hosted Zone in Account A. Configure the public Route 53 hosted zone to route traffic using a weighted routing policy, and deploy an AWS Lambda function triggered by Amazon CloudWatch alarms to manually swap DNS weights from Account A to Account B when an outage is detected.

Cevap

Create a VPC association authorization in Account A for the Private Hosted Zone internal.corp targeting the VPC in Account B, and then associate the VPC in Account B with the hosted zone. Configure a custom health check endpoint (such as /health) on the ALB target group that validates backend application and database connectivity, and enable 'Evaluate Target Health' on the Route 53 public alias failover records.
The correct answer resolves both issues using native AWS features. To enable cross-account VPC resolution for a Route 53 Private Hosted Zone (PHZ), you must first create a VPC association authorization in the hosting account (Account A) and then associate the target VPC (Account B's VPC) from the target account. For the failover issue, configuring the ALB target group health checks to use a custom endpoint (like /health) that verifies backend application and database connectivity ensures that if the backend degrades, the targets will be marked unhealthy. Enabling 'Evaluate Target Health' on the Route 53 alias failover record then allows Route 53 to automatically detect the unhealthy ALB and fail over to the standby region.

Adım Adım Çözüm

1
Authorize the Private Hosted Zone association from Account A to the VPC in Account B.
An association authorization is created for the target VPC in Account B.
Route 53 Private Hosted Zones cannot be directly associated across accounts without authorization from the owner account.
2
Associate the VPC in Account B with the Private Hosted Zone in Account A using the AWS CLI or API.
The standby instances in Account B's VPC can resolve the internal domain names under the private hosted zone.
Once authorized, the target account must accept the association so its VPC Route 53 resolver queries the hosted zone.
3
Configure the ALB target group health check path to a custom path (such as /health) that validates backend application logic and database replication status.
The ALB will report unhealthy status if the backend application or database connection fails, rather than only testing the load balancer listener.
A default HTTP listener response does not reflect actual application availability, which prevents DNS failover if the application fails but the ALB remains online.
4
Enable 'Evaluate Target Health' on the Route 53 public alias records pointing to the ALBs.
Route 53 automatically stops routing traffic to the primary ALB when its target group health check fails.
Setting 'Evaluate Target Health' to yes instructs Route 53 to check the health of the ALB's backend targets and perform automated DNS failover.

Anahtar Kavram

Cross-account Route 53 Private Hosted Zone association and deep application health checks for automated multi-region failover
Bu soruyu puanla