Design Resilient Architectures practice questions

Increase the SQS visibility timeout and, when validation fails, call DeleteMessage in the consumer to remove the message immediately.

Why wrong: Increasing the visibility timeout only gives the consumer more time to process, temporarily reducing the chance of redelivery while a message is in flight, but it does not prevent the retry loop for a message that consistently fails to validate or process. If the consumer calls DeleteMessage after validation failure, you are permanently discarding the poison message without any opportunity to inspect, log, or route it for remediation, which undermines operational debugging and can silently drop legitimate business events. SQS's actual poison-message solution is a dead-letter queue with a redrive policy that moves a message to a DLQ after the configured maxReceiveCount, allowing for isolation and recovery. Since this option lacks that DLQ-based quarantine and also does not implement idempotency to handle at-least-once redelivery of valid messages, it is insufficient.

Move to SNS topics with subscriptions and rely on SNS to provide exactly-once delivery to eliminate duplicates automatically.

Why wrong: SNS is a pub/sub messaging service that does not offer exactly-once delivery semantics; its standard topic type delivers messages at least once and can produce duplicates during retries or due to network issues. Subscribers (e.g., SQS queues) still need their own idempotency handling because SNS does not deduplicate messages for you. Moreover, switching to SNS does not address the core problem of poison messages: SNS lacks a built-in dead-letter queue with redrive policies like SQS, so you'd still need to design a quarantine mechanism separately. Therefore, this option fails to provide the required duplicate protection and poison-message handling.

Change the queue to FIFO and enable content-based deduplication, leaving the consumer logic unchanged.

Why wrong: FIFO with content-based deduplication may reduce some duplicates, but it does not guarantee protection against duplicate side effects when the consumer times out or fails after partially processing. Poison-message retry loops still need a DLQ/redrive approach, and idempotency is still required to make processing safe under retries.

Add an Aurora read replica and keep using the same JDBC URL.

Why wrong: A read replica helps scale read traffic, but it does not solve failover for the writer or the stale-connection problem caused by using a fixed instance endpoint. The application still needs to connect through the cluster writer endpoint.

Increase the EC2 instance size of the application servers.

Why wrong: Increasing the EC2 instance size of the application servers only adds CPU and memory to the compute tier; it does not change how the JDBC driver resolves the Aurora database endpoint or how connection pools handle a failover event. The application is failing because its pooled connections are still pinned to the old writer instance endpoint, which is now a read-only replica or unavailable. Additional app capacity cannot refresh those stale connections or make the application aware that the writer role has moved to another Aurora instance. The correct fix is to use the Aurora cluster writer endpoint, which always resolves to the current writer, and to implement retry logic for transient connection errors during failover.

Switch to a single-AZ RDS PostgreSQL instance for simpler connectivity.

Why wrong: Switching to a single-AZ RDS PostgreSQL instance would actually reduce availability and is a step backward from Aurora's multi-AZ architecture. A single-AZ instance has no automatic failover to another AZ, so any infrastructure failure or maintenance window can cause a full database outage, potentially longer than the transient interruption seen with Aurora. It also does not solve the root cause: the application is connecting to a specific instance endpoint, and RDS single-AZ uses a different DNS name but the same pitfall if the application were to point to a particular instance. The cluster writer endpoint and retry logic are the correct solution because they preserve high availability and let the application automatically follow the writer through failover.

Rely only on increasing the SQS visibility timeout so duplicates rarely occur, without adding idempotency checks or a DLQ.

Why wrong: Increasing the SQS visibility timeout only reduces the window in which a message can become visible again after a consumer fails to delete it; it does not eliminate at-least-once delivery, because a consumer can still crash mid-processing, or a message's visibility can expire during long-running tasks, causing the same payment order to be delivered again. Without idempotency checks, a duplicate delivery can lead to a second charge or duplicate side effect. Moreover, this approach ignores poison messages: if a message consistently fails to process (e.g., malformed payload), it will be retried indefinitely, clogging the queue and consuming resources without ever being moved to a DLQ.

Switch to a FIFO queue and delete messages immediately upon receipt to avoid duplicates.

Why wrong: Deleting a message immediately upon receipt is dangerous because it assumes the processing will always succeed; if the payment logic fails after deletion, the message is lost forever, and the payment order may never be processed, violating the reliability required for a payments workload. A FIFO queue does guarantee strict ordering and exactly-once delivery within a consumer group, but that guarantee only holds if you delete the message after successfully processing it and committing the side effect. Immediate deletion also defeats the purpose of SQS's at-least-once model, which exists to allow safe retries, and it does not address duplicate application-level side effects if processing itself is not idempotent.

Move the workload to SNS and use synchronous HTTP endpoints so the sender retries until the receiver confirms success.

Why wrong: SNS delivery is not a guaranteed exactly-once request/response mechanism. Even with retry behavior, duplicate deliveries and partial failures can still occur, and this approach does not directly provide the same DLQ + idempotency protections for at-least-once delivery semantics.

Reduce the ALB health check interval to speed up detection of unhealthy targets.

Why wrong: Reducing the ALB health check interval may detect instance health failures sooner, but it does not change where Auto Scaling is allowed to launch instances. If the ASG is still limited to a single AZ’s subnets, capacity cannot be restored in other AZs.

Enable connection draining on the ALB so existing requests complete before targets are terminated.

Why wrong: Connection draining helps during controlled events such as deployments or scale-in, where you want in-flight requests to finish. It does not enable the ASG to launch replacements in other Availability Zones after an AZ outage.

Increase the ASG desired capacity from 2 to 6 to compensate for the missing subnets.

Why wrong: Increasing the ASG desired capacity from 2 to 6 does not change the subnets or Availability Zones the ASG is configured to use. Auto Scaling can only launch instances into the subnets explicitly attached to the ASG, so if those subnets all reside in the Availability Zone that failed, the extra capacity requests will still fail to launch instances. The desired capacity increase would only be helpful if the ASG had spare capacity in unaffected AZs to scale into, which is exactly the missing configuration.

Change both records to weighted routing with a 50/50 split so Route 53 can shift traffic gradually.

Why wrong: Weighted routing distributes traffic according to assigned weights (e.g., 50/50) and does not incorporate health checks, so Route 53 would continue to send a portion of traffic to the primary even if it is healthy, while also sending half to the secondary. This split does not implement the required active-passive failover model, because no automatic switch occurs when the primary becomes unhealthy. The symptom of 'still sends traffic to primary' would persist because weighted routing does not evaluate endpoint health when choosing answers. For health-based failover, Route 53 needs failover routing with a health check attached to the primary record.

Switch to latency-based routing so users are always directed to the lowest-latency Region.

Why wrong: Latency-based routing selects the region that offers the lowest network latency for the specific client, optimizing user experience rather than enforcing a business preference for a primary region. It does not use health checks to fail over; if the primary endpoint remains the lowest-latency target even while unhealthy, Route 53 will continue directing traffic there, matching the reported symptom. This policy cannot implement a strict active-passive model because it lacks a primary/secondary hierarchy and would not automatically shift traffic solely on health status. A failover routing policy with a health check on the primary record is required to achieve the desired behavior.

Use geolocation routing so clients in one Region are sent to the healthier endpoint.

Why wrong: Geolocation routing determines DNS responses based on the geographic location of the requesting client, not on the operational health of the target endpoints. Even if one region is 'healthier,' Route 53 would continue to serve the record mapped to each client's location, ignoring any health-check failures on the primary. This approach cannot express the requirement of preferring one region and failing over only when it is unhealthy, because geo policies do not include health evaluation in their decision logic. The observed behavior of traffic still going to the primary would remain unchanged unless the client’s location happens to map elsewhere.

Increase DesiredCapacity to 4 while keeping all instances in subnet-a1.

Why wrong: This adds more instances, but they are still all in the same Availability Zone. If us-east-1a fails, every instance is lost together and the application still goes down. Capacity is not the same as fault isolation.

Replace the Application Load Balancer with a Network Load Balancer.

Why wrong: A Network Load Balancer changes the load-balancing layer, but it does not fix the root problem: all instances are still in one AZ. If that AZ fails, there are still no healthy targets to receive traffic.

Enable EBS encryption on the launch template volumes.

Why wrong: Enabling EBS encryption on the launch template volumes encrypts data at rest, which protects the confidentiality of data stored on the volumes, but it has no impact on availability or failover behavior. The Auto Scaling group still launches all EC2 instances in subnet-a1 within us-east-1a, so if that Availability Zone experiences an outage, all instances and their encrypted volumes become unreachable simultaneously. Encryption is a security control, not a resilience mechanism; it neither introduces redundant compute in another zone nor changes the failure domain, and it does not alter how the load balancer routes traffic or how the ASG replaces unhealthy instances.

Increase the Auto Scaling group's desired capacity to a higher number than required.

Why wrong: Raising desired capacity does not fix the underlying problem of instances being terminated before the application finishes starting. The ASG will still perform ELB health checks and mark any instance that fails the configured health check as unhealthy, even during startup, and will replace it. A larger fleet only hides the symptom by providing extra capacity, but it also increases cost and can lead to a continuous cycle of launching and terminating instances during provisioning.

Disable ALB target group health checks so instances are considered healthy as soon as they register.

Why wrong: Disabling ALB target group health checks does not stop the ASG from considering instances unhealthy; if the ASG health check type is ELB, it relies on the target group's health status, so disabling checks will cause the ALB to always report healthy, which prevents the ASG from detecting genuine application failures. Meanwhile, the ALB will still route traffic to instances that are still warming up, causing 5xx errors for users, because the target is considered healthy regardless of actual readiness. This is an anti-pattern that sacrifices correctness for a false sense of stability.

Change the Auto Scaling health check type from ELB to EC2 so the ALB will no longer determine instance health.

Why wrong: Even if EC2 status checks pass, the application may still not be ready. The instance can remain in service while still causing failed requests, and the ASG will not use ALB readiness to enforce correct routing behavior.

Use latency-based routing so Route 53 automatically spreads traffic to both Regions based on measured latency.

Why wrong: Latency-based routing selects the Region with the lowest network latency for each user, so it can spread traffic across both Regions simultaneously based on geography. It does not provide deterministic active-passive failover: even if the primary ALB is wholly unhealthy, latency measurements may still point users there if that Region is closest or if no health check is associated with the latency records. Attaching health checks would exclude unhealthy endpoints, but the decision remains latency-driven and does not honor a preferred secondary in a specified failover order.

Use weighted routing and configure the secondary ALB to receive 100% traffic when the primary returns HTTP 5xx responses.

Why wrong: Weighted routing distributes traffic according to static weights you assign to each record, and it does not monitor ALB application response codes like HTTP 5xx. Although you can attach health checks to weighted records so unhealthy records are excluded from responses, simply 'configuring the secondary to receive 100%' on a 5xx condition is not a native weighted-routing feature. There is no built-in action that alters weights based on ALB status, so you'd still need an external automation or a health-check-driven failover policy such as failover routing.

Use geolocation routing and restrict the primary Region record to specific countries only.

Why wrong: Geolocation routing directs users to the record that corresponds to their physical (IP-based) location, such as country or continent. It has no built-in health-check failover logic, so if you restrict the primary Region's record to specific countries, those users would continue receiving the primary's DNS response even when the primary ALB is down. You would have to manually change records or rely on a separate failover mechanism, making this unsuitable for automatic cross-Region disaster recovery.

Restore a manual snapshot and overwrite the existing production DB instance so the data matches exactly 90 minutes ago.

Why wrong: Restoring a manual snapshot overwrites the entire database with the snapshot's capture time, which is only accurate to 90 minutes ago if a snapshot happened to be taken at that exact moment—something you cannot normally guarantee. Moreover, you cannot directly overwrite an existing RDS instance in place; you would have to restore to a new instance and then redirect traffic, and the restore process itself would interrupt production availability. Manual snapshots are periodic and do not provide the granular point-in-time precision needed to recover the precise state from 90 minutes ago.

Wait for the next automated backup window and then restart the current DB instance to roll back changes automatically.

Why wrong: Automated backup windows simply trigger snapshots and transaction log captures; they have no ability to roll back logical changes when the instance is restarted. A restart only reboots the DB engine, leaving committed UPDATE statements intact in the data files, so the erroneous rows would remain unchanged. Even after the next backup, restoring to that later backup would capture the corrupted state, not the pre-update state from 90 minutes ago. The only way to recover to the earlier timestamp is to use PITR to create a new instance from automated backups and logs.

Use cross-region read replicas to rewind changes and promote the replica to become the writer immediately.

Why wrong: Read replicas replicate the current data stream; they do not provide a built-in mechanism to rewind to a historical point in time. Promoting a replica would not correct the data to the state from 90 minutes ago.

Create a read replica in another Availability Zone and promote it manually if needed.

Why wrong: A read replica in another Availability Zone provides an asynchronous copy of the database, but it is not a primary DB instance and does not participate in automatic failover. If the source AZ fails, you must manually detect the outage, promote the replica, and reconfigure the application to point to the new endpoint. This operational intervention introduces minutes of downtime, which violates the 'database must continue serving' requirement that expects automatic recovery. Moreover, asynchronous replication means that the replica may lag behind the primary, so promoting it can result in data loss.

Increase the automated backup retention period to 30 days.

Why wrong: Automated backups capture consistent snapshots and transaction logs in Amazon S3, but they are designed for point-in-time recovery, not high availability. When an AZ fails, the existing DB instance becomes unavailable, and simply having backups does not provide a running database endpoint or an automatic failover mechanism. You would have to manually restore the instance in another AZ, which takes time (often 10-20+ minutes), during which the database is not serving traffic. Thus, increasing backup retention to 30 days improves durability and recovery granularity but does not keep the database online during an AZ failure.

Resize the DB instance to a larger class.

Why wrong: Resizing to a larger DB instance class changes the compute and memory resources of the same single instance, which remains located in one Availability Zone. This choice does not introduce any redundancy and does not alter the failure domain; if the AZ hosting the DB instance goes down, the larger instance also goes down. While a larger instance might absorb more load or handle a higher connection count, it cannot provide failover or continuity of service across AZ boundaries. Therefore, the database would still have a single point of failure at the AZ level.

Increase the ASG desired capacity so that extra instances absorb the failed ones.

Why wrong: Raising the desired capacity only launches more instances; it does not alter the Auto Scaling group's health check type, which remains EC2 status checks that pass because the OS and hypervisor are healthy. The application's HTTP 500 response occurs at the endpoint level, so the extra instances would either also return 500 and remain in service, or at best mask the symptom without removing the failing instances. This action neither detects the application failure nor triggers replacement.

Replace the Application Load Balancer with a Network Load Balancer to improve failover speed.

Why wrong: A Network Load Balancer operates at Layer 4 and its health checks only verify TCP connectivity, not HTTP response codes such as the 500 shown by the application's health endpoint. Replacing the ALB with an NLB would therefore still report the instance as healthy, and the ASG's default EC2 health checks would also continue to pass. This change alters the traffic layer but leaves the actual detection and replacement mechanism unchanged.

Increase the HealthCheckGracePeriod to the maximum value so the instances have more time to stabilize.

Why wrong: The health check grace period applies only after an instance is launched, delaying the start of health checks so a new instance has time to stabilize; it has no effect on instances that are already running and returning HTTP 500s. The exhibit shows a steady-state failure, not a boot-time issue, so increasing this value to the 3600-second maximum would only postpone evaluation of new replacements, leaving the current unhealthy instances untouched. It also does not change the health check type from EC2 status checks to ELB, so application failures remain invisible.

Restore the latest automated snapshot and accept data loss from the last backup window.

Why wrong: Restoring the latest automated snapshot would bring the database back to the exact point in time when that snapshot was captured, not to the target time of 2026-04-27 15:10 UTC. Since automated snapshots are taken daily (and manual snapshots only when you take them), if the incident occurred after the last snapshot, all transactions committed since that snapshot—including the valid rows that should be preserved—would be lost. While a snapshot restore is a valid recovery option, it cannot provide fine-grained point-in-time recovery, so it would not meet the requirement to restore to the specific pre-delete moment and would leave you short of the desired recovery point objective.

Promote a read replica because it will contain the deleted rows and can replace the primary immediately.

Why wrong: A read replica operates asynchronously, meaning it continually applies the same changes that reach the primary database after a brief replication lag. The accidental DELETE is a committed transactional change, so it will replicate to the replica just like any other statement; the replica will contain deleted rows only if it is frozen at a point before the delete replicated, which is not guaranteed and cannot be precisely controlled. Promoting the replica gives you a live database at whatever its current, post-delete state is, not a point-in-time pre-incident copy, so it cannot satisfy the requirement to restore to exactly 2026-04-27 15:10 UTC.

Enable Multi-AZ on the current database and wait for automatic failover to reverse the delete.

Why wrong: Multi-AZ on Amazon RDS provides high availability by maintaining a synchronous standby replica in a different Availability Zone that is automatically promoted during failover caused by infrastructure failures or maintenance. It is a physical copy of the database, not a logical undo log: any committed DELETE on the primary is also committed on the standby, so a failover would fail over to a database that already has the rows deleted. Enabling Multi-AZ and waiting for failover cannot roll back a logical data modification; it only restores service availability after a loss of the primary instance, not after an application error.

Keep simple routing and lower the TTL to 10 seconds.

Why wrong: A lower TTL can make clients refresh cached answers sooner, but simple routing still returns only one endpoint and does not provide primary/secondary failover behavior. It does not automatically switch traffic to the standby Region when the primary becomes unhealthy.

Use weighted routing with equal weights for both ALBs.

Why wrong: Weighted routing is useful for traffic splitting or gradual migration, but it is not the same as health-based disaster recovery. Equal weights do not create a primary endpoint with an automatic standby that is used only on failure.

Use geolocation routing so users in each continent reach a closer ALB.

Why wrong: Geolocation routing selects DNS responses based on the client's geographic origin, typically to direct users to the nearest or regionally appropriate endpoint. It does not evaluate the health or availability of the target resources. If the primary region's ALB becomes unhealthy, geolocation will still return that ALB's IP to users in that region, causing an outage. It lacks the health-check-driven failover mechanism that Route 53 failover routing provides, so it cannot meet the requirement for automatic disaster recovery.

Increase the Lambda timeout so each invocation can wait longer for the payment API.

Why wrong: Increasing the Lambda timeout does not add any buffering or durability. If the payment API is down, each invocation remains in flight longer, consuming concurrency and causing Lambda to scale up and continue retrying, which only deepens the backlog. Moreover, EventBridge has already delivered the event to the target; if the invocation fails after its longer timeout, the event is still lost unless you have a retry policy or a durable destination. The right design is to decouple with SQS, where messages persist independently of the downstream API's availability.

Switch the target to a Lambda function with reserved concurrency of zero during outages.

Why wrong: Setting reserved concurrency to zero during an outage stops all Lambda invocations entirely, which essentially disables the consumer rather than buffering the events. EventBridge will continue to attempt delivery to the new target and will likely exhaust its retry policy, eventually dropping the events because no queue exists to retain them. This approach also prevents you from processing any backlog when the API recovers, as you must remember to restore concurrency, and it does not help with poison messages. A queue-based solution with a DLQ provides durable storage while the consumer is intentionally paused or scaled down.

Replace EventBridge with CloudWatch Logs subscriptions so the consumer can poll the log stream later.

Why wrong: CloudWatch Logs subscriptions are designed for streaming log data to destinations for real-time analysis, not for buffering business events for later replay. They do not provide a pull-based queue, TLS of a message, per-message retry with backoff, or a DLQ to isolate poison messages. If the consumer is down, log events may be delivered later but you cannot guarantee exactly-once or ordered processing, and there is no mechanism to preserve and reprocess failed event payloads in an application context. EventBridge to SQS is the correct pattern because SQS is built specifically for durable message buffering between producers and consumers.

Active-active writes always provide strong consistency because AWS replicates data across Regions automatically and immediately.

Why wrong: Wrong. AWS does not replicate data across Regions automatically and immediately for active-active setups; cross-Region replication is always asynchronous by design, with measurable lag (e.g., Aurora Global Database typically has sub-second to 1-second replication lag, and DynamoDB Global Tables propagate changes asynchronously). This means a write in one Region may not yet be visible in another Region, so reads from the remote Region can be stale. Active-active multi-master patterns are eventually consistent under concurrent conflicting updates; they do not provide strong consistency unless the application uses a conflict-free data model or accepts last-writer-wins semantics, which is not universal.

Active-active writes can be used safely by simply enabling retries and expecting the application to resolve conflicts without coordination.

Why wrong: Wrong. Enabling retries on write operations only handles transient network issues or throttling; it does not resolve data conflicts that occur when two Regions independently write to the same item or partition key. Without a centralized coordination authority, each Region may apply its own update, leading to divergence; retrying simply causes the request to be re-applied, which can compound the conflict rather than resolve it. Proper conflict resolution requires a deterministic strategy such as last-writer-wins, vector clocks, or application-specific merge logic, and even then, the result is eventually consistent, not strongly consistent.

To ensure strong consistency, run both Regions with different IAM roles and block cross-Region writes at the API layer only.

Why wrong: Wrong. IAM roles and API-level write blocking only control who can issue write requests; they do not influence the replication consistency of the underlying data store. If both Regions are still able to accept writes under their respective IAM roles, the system is still multi-master and susceptible to conflicting updates; blocking cross-Region writes at the API layer alone does not prevent writes that bypass that layer or a future misconfiguration. Even if you block cross-Region writes, that only enforces a single-writer topology implicitly, but the statement claims IAM differences ensure strong consistency—which they do not; strong consistency requires a single authoritative write path and synchronous or ordered replication, not access control.

Increase the Auto Scaling group desired capacity from 2 to 3 in the same subnet.

Why wrong: Increasing the Auto Scaling group's desired capacity to three in the same subnet keeps every EC2 instance within a single Availability Zone, which is the same failure domain shown in the exhibit. If us-west-2a suffers an outage, all three instances fail simultaneously because they share the same physical dependency. Horizontal scaling in one AZ does not add redundancy; it just increases the blast radius of an AZ failure.

Replace the Application Load Balancer with a Network Load Balancer.

Why wrong: Replacing the Application Load Balancer with a Network Load Balancer does not change the deployment's Availability Zone topology because both load balancer types are zonal—they are provisioned only in the subnets you explicitly attach. If the NLB still uses the original single-AZ subnets, it remains in the same failure domain, and an outage of us-west-2a continues to take down both the load balancer nodes and the target instances. A different Layer 4/7 load balancer type cannot provide cross-AZ resilience on its own; you still must attach subnets in a second AZ.

Increase the health check grace period so instances stay registered longer.

Why wrong: The health check grace period only delays when Auto Scaling starts replacing an instance after it fails its health checks. During a full Availability Zone outage, the Application Load Balancer cannot reach any target in that subnet, so extending the grace period merely postpones the inevitable replacement and leaves the service unavailable longer. It does not introduce a second Availability Zone, nor does it give the ASG a healthy location to fail over to.

Keep the read replica and automate promotion with a runbook after CloudWatch alarms fire.

Why wrong: Automating the promotion runbook with CloudWatch alarms eliminates the human step but still relies on an asynchronous read replica, which may lag behind the primary and cause data loss upon promotion. The promotion process itself is not a native RDS failover: it changes the replica's role, updates its endpoint, and requires the application to be redirected, all of which take time and are not seamlessly managed by RDS. The combined latency of alarm detection, script execution, and replica promotion will likely exceed the target recovery time, whereas a Multi-AZ deployment's failover is built-in and updates the endpoint automatically.

Use a cross-Region read replica so promotion happens faster during an AZ failure.

Why wrong: A cross-Region read replica is intended for disaster recovery across geographically distant Regions, not for handling an Availability Zone failure within the primary Region. Cross-Region replication is asynchronous, meaning the replica can be significantly behind the primary, and promoting it is a manual action that also requires changing the application's endpoint to the new Region. Network distance would increase failover latency and the setup does not provide the automatic, synchronous standby that Multi-AZ offers, so it would not help meet a strict recovery time objective in the same Region.

Increase the application retry count and keep the current database design.

Why wrong: Increasing the application retry count only masks transient connection failures, such as brief network timeouts, and cannot address a lengthy outage in which the primary database is down and an administrator must manually promote the read replica. Write requests will continue to fail until a new primary is promoted, so retries simply delay application failure and may increase load on the affected services. This approach leaves the architecture's RTO and RPO unchanged and does not introduce any automated failover capability.

Increase Aurora storage autoscaling so failovers are unnecessary.

Why wrong: Aurora storage autoscaling automatically expands the cluster's storage capacity as data grows; it does not alter the cluster's failover behavior. Failovers are triggered by writer-instance health issues, patching, or an Availability Zone impairment, not by storage pressure. Even with storage scaling enabled, Aurora will still promote a new writer and update the cluster writer endpoint, so the application must follow that endpoint. Storage capacity increases do not make failover unnecessary or prevent the writer DNS mapping from changing.

Point both reads and writes to the Aurora reader endpoint to keep the DNS name the same.

Why wrong: The Aurora reader endpoint is a load-balanced DNS name that routes read traffic to available Aurora Replicas, which operate in read-only mode. Sending writes to this endpoint will fail because replicas do not accept write statements, and the underlying instance behind the reader endpoint can change constantly as replicas are added or promoted. While the reader endpoint's DNS name remains stable, its resolution does not guarantee a primary instance, so it is an invalid target for write traffic. Only the cluster writer endpoint ensures that writes always resolve to the current primary instance, irrespective of topology changes.

Disable Aurora failover capability so the cluster never switches writer instances.

Why wrong: Aurora's failover capability is a built-in high-availability feature that promotes a new writer automatically when the current one becomes unhealthy. There is no practical way to disable this without also stripping away the cluster's Multi-AZ resilience, which would leave writes without a working target during a failure. If you somehow prevented failover, the original writer instance could remain unhealthy or require replacement, and the application would still be pinned to an instance endpoint that might never accept writes again. Disabling failover reduces availability and eliminates the automatic endpoint remapping that the cluster endpoint provides.

Delete the message from the queue immediately after receive to prevent redelivery.

Why wrong: Deleting a message immediately after receive means the queue no longer retains it, so if the consumer fails before finishing the payment, the message is permanently lost and the charge never happens. In contrast, standard practice is to change visibility or lease and delete only after successful processing. This strategy also does not address duplicate delivery that occurred before deletion or from other concurrent consumers, so it fails to ensure consistency.

Increase the queue visibility timeout to a very large value so messages rarely reappear.

Why wrong: Setting a very long visibility timeout can temporarily hide a message, but once the timeout lapses—whether due to consumer failure, crash, or normal lease renewal—the message will reappear and be redelivered. This approach merely postpones duplicates rather than preventing them, and it dangerously increases the detection time for a truly failed payment job. It also gives no protection against a message that is redelivered after a successful charge but before deletion.

Switch to a single-threaded consumer with one worker so messages are processed in order.

Why wrong: Constraining the system to a single-threaded consumer reduces concurrent processing conflicts but does nothing to change the queue's at-least-once redelivery behavior. If the message visibility timeout expires while the message is still being processed, the same message can be redelivered and processed again, even by the same single worker. It sacrifices scalability and throughput while failing to solve the duplicate-charging problem.

Latency-based routing with regional aliases to split traffic based on measured latency.

Why wrong: Latency-based routing chooses the record that offers the lowest latency for the client, but it bases this decision on measured network performance and not on the current health of the endpoints. If Region A becomes unhealthy, Route 53 may still return its records if the latency measurement is favorable, since no health check is attached to reject an unhealthy region. Therefore, latency routing cannot guarantee that all traffic will switch to Region B when Region A fails, which is the specific requirement for regional failover.

Geolocation routing using country-based routing policies.

Why wrong: Geolocation routing selects the DNS record based on the geographic origin of the client, using country or continent mappings, and it does not evaluate the health of the target resource. Even if Region A is unhealthy, clients from regions mapped to Region A will still be directed there, because geolocation policies ignore health checks entirely. This policy is designed for content localization, not for active/standby disaster recovery with automatic failover.

Weighted routing with weights set to 100 for Region A and 0 for Region B.

Why wrong: Weighted routing distributes DNS responses based on assigned weights, but these weights are static and are not automatically adjusted in response to health checks. Setting weights to 100 for Region A and 0 for Region B would send all traffic to Region A, and if Region A becomes unhealthy, Route 53 would continue returning its records, causing an outage until an external process manually updates the weights. This approach lacks the native health-check-driven failover capability of failover routing.