An enterprise is optimizing the disaster recovery (DR) and reliability of a critical multi-tier application. The application is deployed across multiple AWS accounts within an AWS Organization:
* Account A (Application): Hosts the application tier on Amazon EC2 instances inside private subnets of VPC-Prod (in us-east-1) and VPC-DR (in us-west-2).
* Account B (Network): Hosts a centralized Egress-VPC in us-east-1. Outbound traffic from VPC-Prod to third-party payment APIs is routed through an AWS Transit Gateway to the Egress-VPC, which contains a single NAT Gateway.
* Account C (Data): Hosts an Amazon Aurora PostgreSQL Global Database. The primary cluster is in us-east-1 (VPC-Data-Primary), and the secondary cluster is in us-west-2 (VPC-Data-DR). Account C also hosts the Route 53 Private Hosted Zone (PHZ) db.corp.local containing the database endpoints. VPC-Prod is associated with this PHZ.
During a recent regional disaster recovery simulation, the team observed the following failures:
1. A single Availability Zone (AZ) outage in the Egress-VPC caused all outbound payment API requests from VPC-Prod to fail, even though the application instances in other AZs were healthy.
2. The failover of the application tier to us-west-2 exceeded the 15-minute Recovery Time Objective (RTO) because database promotion was triggered manually and DNS updates took too long to propagate.
3. The standby application instances in VPC-DR failed to resolve the database endpoints in db.corp.local.
The enterprise requires an RTO of under 10 minutes and a Recovery Point Objective (RPO) of under 1 minute.
Which combination of actions will resolve these issues and meet the target RTO and RPO?
- AIn Account B, deploy a NAT Gateway in each Availability Zone of the Egress-VPC. Configure the route tables of the Transit Gateway subnets in each AZ to route outbound internet traffic to the local NAT Gateway. Create an AWS Lambda function triggered by a CloudWatch Alarm every 15 minutes to monitor replication lag, delete the global database, promote the secondary cluster, and update Route 53. In Account C, share the PHZ db.corp.local with Account A using AWS Resource Access Manager (RAM) and associate it.
- BIn Account B, maintain the single NAT Gateway and configure a VPC peering connection between VPC-Prod and Egress-VPC to bypass the Transit Gateway. Use AWS Backup to perform daily cross-Region backups of the Aurora PostgreSQL database, restore the database from the backup in us-west-2 during a failover, and update Route 53. In Account A, authorize the association of VPC-DR with the PHZ db.corp.local. In Account C, associate VPC-DR with db.corp.local.
- In Account B, deploy a NAT Gateway in each Availability Zone of the Egress-VPC. Configure the route tables of the Transit Gateway subnets in each AZ to route outbound internet traffic to the NAT Gateway in the same AZ. Use AWS Route 53 Application Recovery Controller (ARC) routing controls to manage application traffic failover, and initiate an Aurora Global Database managed failover to promote the secondary database cluster. In Account C, authorize the association of VPC-DR with db.corp.local. In Account A, associate VPC-DR with db.corp.local.Cevap
- DIn Account B, configure a Route 53 resolver endpoint in the Egress-VPC to perform active-passive failover between NAT Gateways. Configure Amazon Route 53 active-passive failover routing policies with basic Route 53 health checks directly monitoring the Aurora cluster's primary endpoint. In Account A, create a duplicate Private Hosted Zone named db.corp.local and manually replicate the database CNAME records to point to the secondary cluster's endpoints.