A financial technology company is deploying a transaction processing system on AWS. The application uses an Amazon RDS for PostgreSQL database. To meet regulatory compliance, the database architecture must achieve a Recovery Point Objective (RPO) of zero (no data loss) and a Recovery Time Objective (RTO) of less than 35 seconds for any single Availability Zone failure within the primary AWS Region. The application also requires local read scaling within the primary Region to handle reporting queries without affecting write transaction throughput. Which database configuration satisfies these resilience and scalability requirements with the lowest RTO?
- ADeploy a Single-AZ DB instance with two Read Replicas in different Availability Zones, and configure an AWS Lambda function to promote a Read Replica to primary if the main instance fails.
- Deploy the database as an Amazon RDS Multi-AZ DB cluster with one writer and two readable standby DB instances across three Availability Zones.Cevap
- CDeploy two independent Single-AZ DB instances in different Availability Zones, configure bidirectional database replication, and use an Amazon Route 53 latency routing policy with health checks to route traffic.
- DDeploy a standard Amazon RDS Multi-AZ DB instance with a standby in a second Availability Zone, and configure a cross-Region Read Replica to handle local reporting queries.
Cevap
Deploy the database as an Amazon RDS Multi-AZ DB cluster with one writer and two readable standby DB instances across three Availability Zones.
Deploying an Amazon RDS Multi-AZ DB cluster satisfies all constraints. It uses semi-synchronous replication to guarantee an RPO of zero (no data loss) if at least one standby acknowledges the write. Its architecture enables automatic failovers that typically complete in under 35 seconds, meeting the strict RTO target. Furthermore, it allows read traffic to be routed to the two standby DB instances, providing native local read scaling within the primary Region.
Adım Adım Çözüm
Anahtar Kavram
Amazon RDS Multi-AZ DB Cluster Deployments vs Multi-AZ DB Instance Deployments