Reliability and Business Continuity practice questions

Enable DynamoDB Accelerator (DAX).

Why wrong: DAX is a Redis-compatible in-memory caching service that offloads read traffic from DynamoDB, reducing latency and throttling for hot keys. It is deployed within a single Region and does not copy table data to other AWS Regions, so if that Region suffers an outage the DAX cluster and the underlying table become unavailable together. Therefore DAX offers no disaster recovery or cross-Region failover capability.

Create a read replica in another region.

Why wrong: Unlike Amazon RDS, DynamoDB does not provide a read replica feature that lets you create a separate read-only copy of a table in a different Region. The only native way to replicate a DynamoDB table across Regions is to enable global tables, which replicate the entire table with read and write access in each selected Region. Without global tables, a regional failure leaves no remote table available to serve reads or writes, so read replicas are not a valid recovery solution.

Increase read and write capacity units.

Why wrong: Increasing read and write capacity units—even with on-demand scaling—only changes the throughput allocation within the table's current Region and does not create any redundant infrastructure elsewhere. It affects performance and throttling under load, but has no bearing on the table's recoverability if the entire AWS Region becomes unavailable. The application would still be completely dependent on the single-Region table, so this action cannot provide the required high availability or disaster recovery.

Modify the DB instance to Single-AZ and then back to Multi-AZ.

Why wrong: Converting the DB instance to Single-AZ removes the standby replica and changes the entire high-availability topology, which is a structural migration rather than a failover test. When you then convert back to Multi-AZ, RDS provisions a completely new standby in another AZ, so you are not exercising the existing standby's failover logic at all. This operation also causes downtime and is not how you would simulate a primary-instance failure.

Reboot the DB instance without selecting any failover option.

Why wrong: Performing a standard reboot without the 'Reboot with failover' checkbox simply restarts the existing primary DB instance in place; the standby remains idle and the primary endpoint stays on the same instance. No failover is attempted because no health-check failure is simulated, so this only tests the instance's ability to restart, not the failover mechanism. To actually trigger a failover, you must either select the failover option or induce a real primary availability event.

Promote the standby instance using the Amazon RDS console.

Why wrong: A Multi-AZ standby is not a readable or separately manageable DB instance; it is a synchronous replica under RDS's control, and Amazon RDS does not provide a 'Promote' action for Multi-AZ standbys. Promoting a replica is a read replica operation only, so attempting this in the console would either fail or apply to a different resource. In a Multi-AZ setup, the primary-to-standby transition is automatically managed by RDS and cannot be manually initiated through a promotion.

Deploy an additional EC2 instance in the same Availability Zone.

Why wrong: Adding an EC2 instance within the same Availability Zone does not create fault-domain redundancy because an AZ is a single failure domain—if the AZ goes down, all instances in it become unreachable. The new instance would not serve traffic independently unless it is behind a load balancer or has a data replication and failover mechanism, and even then a same-AZ placement adds no resilience against an AZ failure. This option only increases capacity, not availability.

Enable termination protection on all EC2 instances.

Why wrong: Termination protection is a data-loss safeguard that prevents users or scripts from accidentally terminating an EC2 instance; it does not affect the instance's runtime health or its ability to withstand infrastructure failures. An instance can still be lost due to an underlying hardware degradation or an Availability Zone outage, and termination protection will not trigger or contribute to failover. Therefore it provides no availability benefit for the application as a whole.

Use an Amazon RDS Multi-AZ deployment for the database tier.

Why wrong: Deploying Amazon RDS Multi-AZ improves the database tier's resilience by automatically failing over to a standby replica in a different AZ, but it does not make the web application tier itself redundant. The question specifically concerns the EC2 web instances, which would remain a single point of failure if they are confined to one AZ or lack a load balancer. Even with a highly available database, the application still goes down if its only web server fails, so this option does not address the application tier's availability requirement.

Amazon RDS Performance Insights

Why wrong: Amazon RDS Performance Insights is a database performance tuning feature that visualizes the load on your database in terms of waits, SQL queries, and host activity. It is designed to help identify performance bottlenecks like slow queries, lock contention, or high CPU utilization, not to track infrastructure lifecycle events. While a failover could momentarily affect performance metrics, Performance Insights does not record or present the occurrence, timing, or cause of the failover itself. Therefore, it cannot be used to review failover event details.

Amazon CloudWatch Logs

Why wrong: Amazon CloudWatch Logs is a service for storing and monitoring log files, and RDS does not automatically write failover events to it. For RDS, CloudWatch Logs can contain database engine logs such as MySQL error logs, PostgreSQL logs, or SQL Server error logs, but these are application/database-level logs, not infrastructure event records. An automatic Multi-AZ failover is an infrastructure event managed by the RDS service; it is not emitted as a log entry by default. To capture RDS failover events, you would need to use RDS event notifications or Amazon EventBridge, not CloudWatch Logs directly.

AWS CloudTrail

Why wrong: AWS CloudTrail records API calls made by users, roles, or AWS services for audit and governance purposes. The automatic Multi-AZ failover process is an internal RDS service operation triggered by health checks or underlying infrastructure issues; it is not an API call that enters the CloudTrail log. CloudTrail may show supporting API calls like RebootDBInstance if a manual failover was forced, but the automatic failover itself is not represented as an API event. Thus, CloudTrail would not provide a direct record of the failover's occurrence or its root cause.

Increase the Auto Scaling group minimum to 10 instances to absorb the failure.

Why wrong: Raising the Auto Scaling group minimum to 10 does not change the failure domain: all 10 instances would still be launched within the same single Availability Zone (AZ) if the group is not configured for multiple AZs. When that one AZ experiences an outage, every instance is simultaneously unavailable, and the ALB has no healthy targets to route to. The minimum capacity only guarantees a desired number of instances exist, not that they reside in independent infrastructure. Redundancy across AZs is the only way to avoid a single point of failure, so this approach merely increases cost without improving resilience.

Use larger instance types to handle the load of a failed AZ.

Why wrong: Selecting larger instance types only increases compute, memory, and network capacity on each individual instance but does not alter the underlying architecture's Availability Zone (AZ) dependency. If all instances are placed in a single AZ and that AZ fails, even a massive instance will be offline, so the workload is still completely unavailable. Larger instances can help absorb increased traffic during normal operations, but they cannot protect against an entire AZ becoming unreachable. To survive an AZ failure, instances must be distributed across multiple AZs, not made more powerful in one AZ.

Use multiple Application Load Balancers in different AZs.

Why wrong: Deploying multiple Application Load Balancers in different AZs does not resolve the fundamental issue if the EC2 instances are all located in a single Availability Zone (AZ). The ALBs are only entry points; they still forward requests to backend targets, and if those targets are all down because their AZ is unavailable, every ALB will return 503 or have no healthy instances to serve. In fact, an ALB itself is designed to be a regional or multi-AZ resource, so creating separate ones in different AZs is unnecessary and adds complexity. The proper fix is to have the ALB and the Auto Scaling group span the same set of AZs so that at least one AZ remains operational.

Create a read replica of the RDS instance in a second region. Configure an Amazon CloudFront distribution with the ALB as origin. Use Route53 failover routing policy to route traffic to the CloudFront distribution.

Why wrong: A read replica in a second region provides asynchronous replication and can be promoted, but it is not a fully managed disaster recovery solution; promotion requires manual intervention, which alone could exceed the 2-hour RTO. Using CloudFront with the ALB as origin does not provide automatic failover for the underlying compute and database; CloudFront only caches and distributes content, and Route53 failover to a CloudFront distribution does not fail over the RDS database or the application stack. This option lacks automated database failover and regional infrastructure deployment, making it unsuitable for the stated RTO and RPO requirements.

Take daily manual snapshots of the RDS instance and copy them to a second region. Store the AWS CloudFormation template for the infrastructure in an S3 bucket with cross-region replication. In the event of a disaster, manually deploy the stack and restore the snapshot.

Why wrong: Daily manual snapshots copied to a second region can provide a recovery point, but the snapshot is only as recent as the last manual snapshot, which can be up to 24 hours old—far exceeding the 1-hour RPO. In a disaster, manually deploying the CloudFormation stack and restoring the snapshot involves significant human steps, including launching infrastructure, waiting for stack creation, and restoring the DB, which will almost certainly exceed the 2-hour RTO. While cross-region replication of the template ensures the template is available, it does not pre-provision resources or automate failover, so this solution is too slow and manual for the required recovery objectives.

Use AWS Database Migration Service (DMS) to continuously replicate data to a second region. Use an Application Load Balancer in the primary region and a Network Load Balancer in the secondary region. Create a Route53 weighted routing policy to distribute traffic.

Why wrong: A weighted routing policy distributes traffic based on configured weights, not on availability; it does not automatically remove a failed region from rotation or redirect all traffic to the healthy region, so it cannot provide failover in a regional outage. While DMS can continuously replicate data, it introduces additional complexity, requires managing replication tasks and endpoints, and does not natively integrate with Route53 health checks for automatic failover. This option also mixes an ALB in one region and NLB in another, but neither load balancer is designed for cross-region failover on its own; without a health-check-driven routing policy, the solution fails to meet the automatic failover requirement.

Use Amazon Data Lifecycle Manager (DLM) to take hourly snapshots and create an AWS CloudFormation template to launch a new instance from the snapshot.

Why wrong: DLM can schedule hourly EBS snapshots, but it is a snapshot lifecycle automation tool only and does not include restore automation. Building a CloudFormation template to launch an instance from a snapshot adds complexity, because you must manually define resource mappings, handle snapshot IDs, and manage the stack update/creation process. Additionally, DLM lacks centralized backup policies, cross-account monitoring, and audit capabilities that AWS Backup provides, increasing operational overhead and making recovery less reliable.

Use custom scripts to copy snapshots to an Amazon S3 bucket and restore from there.

Why wrong: Writing custom scripts to copy snapshots to S3 and restore from them is fragile and inefficient. Snapshots are stored in Amazon S3 internally by AWS, but copying them to user-visible S3 buckets requires using the snapshot export API, which is asynchronous and not intended as a backup/recovery path. This approach must handle snapshot export, import, and volume creation manually, introducing significant risk of script failure, data corruption, and extended RTO, and it duplicates AWS Backup's existing capabilities without the managed compliance features.

Use Amazon S3 Lifecycle policies to transition data to Amazon S3 Glacier.

Why wrong: S3 Lifecycle policies apply only to objects in Amazon S3, not to EBS snapshots, which are AWS-managed entities stored as block-based snapshots. They can transition S3 objects to Glacier for archival, but do not provide point-in-time recovery for EBS volumes. Using this method would require first exporting snapshots to S3 objects (not a native restore mechanism), and then Lifecycle policies would only manage storage tiering, not recovery. It does not meet the RTO requirement and is conceptually incorrect for snapshot management.

Weighted routing policy

Why wrong: Weighted routing policy in Amazon Route 53 assigns a weight to each resource record and returns DNS records in proportion to those weights, enabling load balancing across multiple instances. However, it does not evaluate the health of the target instances unless you explicitly attach health checks to the records, and even then it only stops responding with the IP when the health check fails. For a simple two-instance web application needing automatic failover when one instance becomes unhealthy, weighted routing would still return the unhealthy instance's IP to a portion of clients instead of routing all traffic to the healthy one.

Geolocation routing policy

Why wrong: Geolocation routing policy routes traffic based on the geographic location of the DNS resolver (the user's IP address) rather than the health or availability of your resources. You can map different instances to serve users from specific continents, countries, or states, but Route 53 does not automatically reroute traffic when a particular instance becomes unhealthy — it simply continues responding with the record associated with that location. This policy is optimized for content localization and compliance, not for detecting instance failure and shifting traffic like the requirement here.

Simple routing policy

Why wrong: Simple routing policy in Amazon Route 53 is the most basic policy: it allows you to define a single record with multiple values (e.g., all IP addresses) and returns all values in a random order, or a single value if only one is configured. It does not support health checks, so Route 53 cannot distinguish between healthy and unhealthy instances, and every client receives the same set of IPs regardless of instance status. Because there is no mechanism to stop returning an unhealthy instance's IP, simple routing cannot provide automatic failover between the two EC2 instances.

Multi-AZ deployment

Why wrong: A Multi-AZ deployment in Amazon RDS synchronously replicates data to a standby instance in a different Availability Zone within the same AWS Region. This architecture protects against instance or Availability Zone failures, but it provides no resilience if the entire Region becomes unavailable. Because all copies of the database reside in the same Region, Multi-AZ cannot satisfy a cross-region disaster recovery requirement.

Cross-region read replica

Why wrong: A cross-region read replica is an asynchronous RDS feature that maintains a read-only copy in another Region. While this gives you a usable database for disaster recovery, replication lag is variable and can measure in seconds or even minutes under heavy write load, meaning it does not guarantee a sub-second Recovery Point Objective (RPO). Additionally, promoting the replica to be the primary is a manual operation that takes minutes, so the Recovery Time Objective (RTO) is not in the 1-minute range that Aurora Global Database can provide.

Automated snapshot copy to another region

Why wrong: Automated snapshot copying to another Region is a backup-based disaster recovery strategy, not a replication mechanism. Snapshots are taken periodically, so the RPO is driven by the backup schedule (typically hours), and copying the snapshot to another Region adds further delay. To restore, you must create a new DB instance from the snapshot, which can take minutes or longer, yielding an RPO of hours and an RTO that is far too high for the stated requirement of sub-second RPO and minute-level RTO.

Take daily snapshots and copy them to another region.

Why wrong: Daily snapshots copied to another region are point-in-time artifacts; even if copied immediately, the underlying data can be up to 24 hours old, which catastrophically exceeds the 5-minute RPO. Restoring from a cross-region snapshot also requires waiting for the snapshot copy to complete and then performing a full DB restore, typically taking well over an hour and thus missing the RTO. This strategy is acceptable only for compliance or audit requirements with a much looser recovery objective, not for protecting an active production database.

Use cross-region automated backups.

Why wrong: Automated backups are retained for up to 35 days and can be copied across regions, but the RPO is typically up to 15 minutes, and recovery involves restoring from a snapshot, which may take longer than 1 hour.

Deploy a second Multi-AZ DB instance in another region.

Why wrong: Deploying a second Multi-AZ DB instance in another region means running an entirely separate, fully provisioned PostgreSQL database; RDS does not automatically replicate data across independent instances, so you must set up external logical replication (e.g., DMS, pglogical) or manual sync, adding complexity and failure points. It also creates substantial cost overhead because you are billed for the second instance's compute, storage, and its own Multi-AZ synchronous standby — at least twice the infrastructure of a single cross-region Read Replica. This approach is over-engineered for the stated RPO/RTO and is not the true RDS-managed disaster-recovery feature, unlike a Read Replica.

Configure the EFS file system for One Zone storage class and mount it using the file system ID.

Why wrong: The One Zone storage class stores EFS data redundantly only within a single Availability Zone, so an AZ outage causes both data loss and complete file system unavailability. Mounting via the file system ID still resolves to the same single-AZ mount target, offering no cross-AZ failover. A critical application requires the Standard storage class, which replicates across multiple AZs, to withstand AZ failures.

Configure EFS to use provisioned throughput and mount it using a mount target IP address.

Why wrong: Provisioned throughput adjusts the file system's throughput capacity independent of storage size, but it does not influence data durability or availability across zones. Using a mount target IP address bypasses DNS-based failover and pins the client to a mount target in a single AZ, so an outage in that AZ breaks connectivity. For resilience, you must rely on the regional DNS name to reach mount targets in other AZs, not a static IP.

Enable EFS lifecycle management to move files to Infrequent Access storage class.

Why wrong: Lifecycle management migrates files to the EFS Infrequent Access (IA) storage class based on a configured age threshold, lowering storage costs for cold data. It does not alter the underlying storage class redundancy: files remain on the same file system, and IA data in the Standard file system is still replicated across AZs, but for One Zone it remains single-AZ. Thus, lifecycle management is purely a cost optimization and has no effect on the file system's resilience to an AZ outage.

Enable automatic backups.

Why wrong: Automatic backups in RDS for MySQL continuously capture transaction logs and storage snapshots to enable point-in-time recovery to any second within the retention window. However, backups alone do not provide automatic failover: after an Availability Zone failure you would have to restore a new DB instance from the most recent backup, which can take tens of minutes or longer depending on database size. Therefore automatic backups protect your data, not your availability.

Deploy a read replica in a different AZ.

Why wrong: A read replica in a different Availability Zone uses asynchronous replication from the primary database and is designed to offload read traffic. If the primary fails, the read replica can be manually promoted to a standalone primary, but you must initiate that promotion and it may lag behind the source by seconds or minutes, causing potential data loss of recent committed transactions. RDS for MySQL does not automatically promote a read replica to replace the primary, so this is not an automatic failover solution.

Take a manual snapshot and copy it to another AZ.

Why wrong: Taking a manual snapshot and copying it to another AZ creates a point-in-time backup in a separate geographic location for disaster recovery. To use that copy, you must manually restore a new RDS instance from the snapshot, which loses all database changes made after the snapshot was taken and requires the restoration time to complete before traffic can be redirected. This approach addresses data resilience but does not provide automatic failover or continuous availability during an AZ outage.

S3 Same-Region Replication (SRR)

Why wrong: S3 Same-Region Replication (SRR) replicates objects within the same AWS Region, so if the entire region becomes unavailable, the replica is lost along with the primary data. It is designed for use cases like aggregating logs or configuring data for resilience against individual bucket failures, not for disaster recovery across geographically distinct locations. Because the RPO and DR objectives require data to survive a regional outage, SRR does not fulfill the requirement, regardless of versioning or other enabling features.

S3 Event Notifications with an AWS Lambda function to copy objects to another region

Why wrong: Using S3 Event Notifications with a Lambda function to copy objects to another region is not an appropriate solution because event notifications only fire for new object creation events and do not automatically handle existing objects unless you separately trigger S3 Batch Operations. This custom replication path introduces operational overhead and potential failure points, as Lambda invocations can fail or be throttled, requiring you to build retry logic and monitor for gaps. It also lacks the native replication guarantee and RTC-driven 15-minute SLA that CRR provides, making it unreliable for meeting a strict RPO in a DR scenario.

S3 Transfer Acceleration

Why wrong: S3 Transfer Acceleration is an incorrect choice because it only speeds up the upload of objects over long distances by using AWS edge locations and optimized network paths to the S3 bucket. It does not perform any kind of replication, copy, or synchronized data mirroring across regions; it simply improves the network throughput for clients uploading to a single bucket. While it might help you get initial data into S3 faster, it offers no automated DR protection and cannot ensure that data is copied to a different region for recovery.

Increase the visibility timeout of the queue

Why wrong: Increasing the visibility timeout only extends the period during which a message is hidden from other consumers after a receive call. It does not track how many times a message has been received, nor does it move the message to another queue. While a longer visibility timeout might give a slow consumer more time to finish before the message becomes visible again, it does not address the underlying problem of a message that continually causes processing failure — the message will simply reappear and be retried forever until the visibility timeout is repeatedly extended.

Convert the queue to a FIFO queue

Why wrong: Converting the queue to a FIFO queue changes the semantics to strict ordering and exactly-once processing support, but it has no built-in handling for failed messages. FIFO queues require a message group ID, limit throughput, and do not automatically discard or redirect messages that fail to process. A poison-pill message in a FIFO queue can block all subsequent messages in its group, making the situation worse; you still need a DLQ with a redrive policy to rescue those failures.

Enable redrive allow policy on the queue

Why wrong: A redrive allow policy is a configuration on the DLQ that specifies which source queues are permitted to use that DLQ. It is a permission or scope control, not an action that moves messages. Without a corresponding redrive policy on the source queue that specifies the DLQ and max receive count, enabling the allow policy alone does nothing to send failing messages anywhere. So, while it may be a prerequisite or companion setting, it is not the mechanism that actually moves messages to the DLQ.

DynamoDB Accelerator (DAX)

Why wrong: Amazon DynamoDB Accelerator (DAX) is an in-memory cache that sits in front of a DynamoDB table, reducing read latency from single-digit milliseconds to microseconds. However, DAX maintains its cached data only within the same Region and does not propagate writes or cached items to other Regions. During a regional outage, both the cache and the underlying table become unavailable, and DAX offers no mechanism for failover or data replication, so it does not satisfy disaster recovery requirements.

DynamoDB point-in-time recovery

Why wrong: Point-in-time recovery (PITR) continuously backs up a DynamoDB table within the same Region, enabling you to restore it to any second during the last 35 days. However, PITR does not replicate live data to another Region; a restore operation creates a new table in the same Region and requires manual action. Because there is no automatic traffic failover or cross-Region copy, PITR alone cannot keep a workload available during a regional outage.

DynamoDB auto scaling

Why wrong: DynamoDB auto scaling adjusts provisioned read and write capacity in response to actual traffic, using target utilization policies to scale capacity up or down. This feature is only applicable to tables in provisioned capacity mode and affects performance, not data placement or durability. Auto scaling does not copy data to other Regions and provides no failover capability, so it cannot serve as a disaster recovery mechanism.

Place tasks in a single Availability Zone.

Why wrong: Placing all tasks in a single Availability Zone creates a hard dependency on that AZ's infrastructure. If the AZ experiences an outage, network partition, or power failure, the ECS service has no capacity to fail over because all task instances are co-located. This violates the high-availability design goal for critical applications, as even a healthy task in a healthy AZ cannot serve traffic if the entire AZ is impacted. This is the opposite of the recommended approach.

Use a binpack placement strategy.

Why wrong: Binpack placement strategy optimizes for the smallest number of container instances or the highest resource utilization, not for AZ diversity. It will place tasks on the instance that has the most available CPU or memory to meet the task's requirements, which can easily result in all tasks being scheduled onto a single container instance within one AZ. While binpack is efficient for cost and resource usage, it directly contradicts the need for high availability, as a single instance failure or AZ outage could take down the entire application.

Increase the desired task count to 10.

Why wrong: Simply increasing the desired task count to 10 does not influence where ECS places those tasks; placement is determined by the service's placement strategy and constraints. Without a spread strategy, the ECS scheduler could still place all 10 tasks on the same container instance or within the same AZ, especially if the instance has sufficient resources to run them. More tasks don't equate to more AZ resilience; you need to explicitly spread tasks across AZs to achieve high availability. In fact, increasing the count may even increase the blast radius if they're all co-located.

Create a placement group and launch the instance in it

Why wrong: A placement group only controls the physical placement of instances—cluster for low latency, spread for isolation, or partition for fault-tolerant big data applications. It does not perform health checks, nor does it have any mechanism to replace failed instances. Even if you place the instance in a spread placement group to minimize correlated failures, you must still separately create an ASG or use EC2 Auto Recovery to actually replace the instance after a failure.

Place the instance behind an Elastic Load Balancer

Why wrong: Placing the instance behind an Elastic Load Balancer enables the ELB to route traffic to the instance and health-check its status. However, an ELB is strictly a traffic distribution service—it does not have the ability to terminate or launch EC2 instances. If the instance fails, the ELB will simply stop sending traffic to that unhealthy target, but the instance remains down and the application stays unavailable unless another service such as an Auto Scaling group is configured to replace it.

Configure an Amazon Route 53 health check with failover routing

Why wrong: Amazon Route 53 health checks with failover routing policy can monitor the instance's endpoint and, if it fails, remove the failed record and respond to DNS queries with a healthy endpoint. This requires you to define at least one other record or resource as a failover target, but Route 53 cannot provision or start EC2 instances. Thus, this approach only reroutes client traffic; it does nothing to bring the original critical instance back to a running state.

Use Amazon Data Lifecycle Manager (DLM) to take snapshots every hour and use AWS Backup to copy them to us-west-2. In a disaster, restore the snapshot as a volume and attach to a new instance in us-west-2.

Why wrong: This is the correct answer because Amazon Data Lifecycle Manager (DLM) automates the creation of hourly EBS snapshots, satisfying the 1-hour RPO with minimal manual effort. AWS Backup can then automatically copy these snapshots to us-west-2, ensuring a current, recoverable copy exists in the DR region. During a disaster, you can restore the snapshot as an EBS volume and attach it to a pre-provisioned EC2 instance in us-west-2; if the instance and volume attachment are scripted (e.g., with a small bootstrapping script), the 15-minute RTO is achievable. The combination of DLM for lifecycle scheduling and AWS Backup for cross-region replication provides a fully managed, reliable DR solution.

Enable Amazon S3 Cross-Region Replication for the EBS volume's snapshot repository.

Why wrong: This option misunderstands how EBS snapshots are stored. While EBS snapshots are indeed backed by Amazon S3, they are placed in an internal, AWS-managed bucket that you cannot access directly, and S3 Cross-Region Replication cannot be enabled on that bucket. Even if you could enable CRR, the snapshot metadata and the actual data blocks are not ordinary S3 objects available for replication; snapshot copying must be done through the EC2 API, AWS Backup, or DLM’s cross-region copy feature. Therefore, simply enabling S3 CRR on the snapshot repository is not technically possible and would not provide the needed cross-region disaster recovery.

Attach an additional EBS volume configured with RAID 1, and use rsync to replicate data every hour to a volume in us-west-2.

Why wrong: This approach relies on manual scripting and additional infrastructure, which is not a managed or automated solution. You would need to maintain a second EBS volume in us-west-2, continuously run rsync processes, and handle the complexity of keeping the RAID 1 mirror in sync across regions, including dealing with network latency and consistency. Moreover, rsync-based replication is not crash-consistent and does not capture the full state of the application unless you also script volume attachment and instance launching. This method would be fragile, difficult to maintain, and would likely fail to meet the 15-minute RTO without significant custom automation, unlike the fully managed DLM/AWS Backup approach.

Read Replicas

Why wrong: Read Replicas are used to offload read traffic and can be promoted to a primary, but promotion is manual and does not provide automatic failover.

Automated backups with point-in-time recovery

Why wrong: Automated backups allow restoring to a point in time, but this is a manual process that takes longer than automatic failover and does not meet the minimal downtime requirement.

Amazon RDS Proxy

Why wrong: RDS Proxy is a connection pooling service that helps manage database connections. It does not provide automatic failover or a standby instance.