Route 53 Failover practice questions

Use a single Alias A record with simple routing and a short TTL so Route 53 quickly changes the IP address.

Why it fails: A single Alias A record with simple routing always returns the same endpoint regardless of its health; Route 53 does not evaluate health checks for simple routing policies. A short TTL only reduces the DNS cache duration, so clients will eventually retry, but they will keep getting the same IP address until it is manually changed. There is no automatic switch to another region, so this configuration cannot provide failover.

Use weighted routing to send a small percentage of traffic to the secondary region, increasing it manually when the primary fails.

Why it fails: Weighted routing distributes traffic by assigned weights, but it does not consider endpoint health; Route 53 will continue sending requests to the primary even if its health check fails unless you manually modify the weights. Manual adjustment is slow, relies on DNS TTL expirations, and introduces human error, making it unsuitable for automated disaster recovery. Failover routing, by contrast, changes answers automatically when the associated health check fails.

Use latency routing only, letting Route 53 choose the lowest-latency region at query time, without health checks.

Why it fails: Latency routing selects the region that offers the lowest latency for each client, but it makes this choice purely on network performance, not on whether the endpoint is actually healthy. If the primary region is down but still responds to DNS queries with the same IP, latency routing will keep directing users there because no health check is involved. It therefore lacks the deterministic health-check-based failover behavior required for active/passive disaster recovery.

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

Why it fails: 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 it fails: 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 it fails: 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.

Create a single Route 53 record using weighted routing across both ALBs with weights adjusted manually during an incident.

Why it fails: Weighted routing with manual weight adjustments is inherently reactive and not an operational failover mechanism. While you could assign weights to A records that point to each ALB, Route 53 will still distribute traffic according to those weights even if one ALB is impaired, unless you attach a health check to each weighted record and remove the unhealthy set automatically. Manually editing weights during an incident relies on DNS TTL expiration and propagation, which can take minutes, and requires someone to detect the outage first—so it does not meet the need for automatic, fast regional failover.

Use latency-based routing so Route 53 always selects the fastest region; health checks are unnecessary because client latency reflects availability.

Why it fails: Latency-based routing chooses the record that offers the lowest round-trip time for each individual client, not the region that is actually healthy. If the us-east-1 endpoint begins returning HTTP 5xx errors or is completely unavailable, latency-based routing will still return that record to clients in eastern North America because latency measurements do not reflect application health. Health checks are mandatory if you want latency-based routing to fail over, and the option explicitly says they are unnecessary—making this configuration incapable of detecting or responding to an outage.

Use a single A record with a static IP address that points to a NAT gateway, and update that IP during failure events.

Why it fails: A NAT gateway is designed for outbound internet access from private subnets, not for accepting inbound traffic to an ALB; it cannot serve as a public endpoint for an API. Moreover, ALBs are typically accessed via their DNS names, not a static IP, and using a static IP requires an Elastic IP attached to a Network Load Balancer or an instance, not a NAT gateway. Manually updating the A record during a failure is not an automated failover approach; it introduces DNS TTL delays and requires external monitoring, so it is both architecturally invalid and operationally unsafe for this use case.

Use simple routing with one record that contains both regions as weighted targets.

Why it fails: Simple routing in Route 53 does not support weighted targets and returns a single set of resource records to every DNS query without any health-check evaluation. Because it cannot associate multiple regions with weights or health checks, it cannot detect a primary Region failure and automatically reroute to a secondary. Therefore, using simple routing would not satisfy the active/passive failover requirement in this scenario.

Use weighted routing and set the secondary Region weight to 0 until needed.

Why it fails: Weighted routing allows you to assign traffic proportions to multiple records, but setting the secondary Region's weight to 0 only changes the distribution when you manually update the DNS configuration. Route 53 does not automatically adjust weights in response to a health check failure, so if the primary Region becomes unhealthy, clients will still receive the primary endpoint and experience failures. This approach requires manual intervention, which contradicts the need for automatic failover.

Use latency-based routing so requests go to the region with the lowest latency, regardless of health.

Why it fails: Latency-based routing selects the record that offers the lowest observed latency based on the client's location, and it does not consider the endpoint's health status when making that decision. If the nearest Region is having an outage, Route 53 will continue to direct traffic to that unhealthy target because latency remains the sole routing factor. Even when health checks are attached, the default behavior does not proactively fail over to a secondary Region for disaster recovery.

Latency-based routing with health checks for both Regions.

Why it fails: Latency-based routing chooses the Region primarily based on measured latency. Health checks can remove an endpoint from routing if unhealthy, but it does not guarantee that all traffic switches to a specific secondary Region as a deliberate primary/backup failover policy.

Weighted routing to distribute traffic evenly across both Regions.

Why it fails: Weighted routing sends a configured percentage of traffic to each Region under normal conditions. Even if one endpoint becomes unhealthy, weighted routing by itself does not implement a strict “switch all traffic to the secondary when primary fails” pattern without additional failover-specific configuration.

Geolocation routing based on the client’s country to choose a Region.

Why it fails: Geolocation routing bases DNS answers on the geographic location of the client making the query, mapping countries or continents to specific endpoints, so it has no concept of endpoint health or deliberate primary/backup failover. If the region serving a particular location goes down, geolocation routing will continue to return that region's records because it never evaluates health of the underlying resources—clients in that location would simply get DNS answers pointing at an unavailable endpoint. This policy is appropriate for latency reduction or content localization, not for regional disaster recovery where all traffic must move to a standby region when the primary fails.

Create two latency-based alias records for the same name, each with different health checks; Route 53 will automatically shift to the secondary when primary is unhealthy.

Why it fails: Latency-based routing selects the record with the lowest measured latency for each user, so it is inherently a performance-optimization policy, not a failover mechanism. While attaching health checks to each latency record will cause Route 53 to stop returning an unhealthy record, it still does not create a deterministic primary/secondary relationship; traffic can be distributed across both healthy regions based on latency, and if the primary fails, traffic only shifts to the secondary because the secondary happens to have lower latency, not because a failover rule was triggered. Additionally, when the primary recovers, latency-based routing may immediately route traffic back to it, causing flapping, without the stable active-passive semantics required for regional disaster recovery.

Use geolocation routing with a health check; when the primary is unhealthy, Route 53 will automatically change the region mapping globally.

Why it fails: Geolocation routing directs traffic based on where the user is located. Health checks do not create a “global primary-to-secondary region switch” mapping for a single global name; this is not the intended use of geolocation routing.

Use simple routing with weighted records and a low health check threshold so traffic quickly moves to the secondary region.

Why it fails: Weighted routing distributes traffic by configured weights and is not a failover routing policy. Also, health check thresholds do not replace the need for a primary/secondary failover model that deterministically routes all traffic to the secondary when the primary is unhealthy.

Keep simple routing and lower the TTL to 10 seconds.

Why it fails: 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 it fails: 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 it fails: 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.

Enable termination protection on the EC2 instances and configure an Elastic IP address per instance so that clients can reconnect to the same address after a zone failure.

Why it fails: Termination protection only blocks accidental instance termination; it does nothing when an Availability Zone itself is impaired. Elastic IP addresses are Regional and can be remapped, but clients are connecting to the load balancer endpoint, not to instance addresses, so this design neither preserves the endpoint nor provides running capacity in a second zone.

Replace the Network Load Balancer with an Application Load Balancer deployed in one Availability Zone and attach an Auto Scaling group with a desired capacity of two instances.

Why it fails: An Application Load Balancer is also a Regional resource, but keeping the Auto Scaling group in a single Availability Zone means the workload still has no capacity in a second zone, so a zone failure still takes down every instance. This option changes the load balancer type and its DNS name, which also violates the requirement that clients keep using the existing API endpoint.

Create a second Network Load Balancer in a different Availability Zone and use Amazon Route 53 weighted routing to send half the client traffic to each load balancer.

Why it fails: A second Network Load Balancer in another zone does not protect the instances, which remain in one zone, and weighted routing does not automatically withdraw a failed endpoint from DNS. Weighted records keep resolving to the failed load balancer until health checks and TTL expire, and clients would also need to tolerate two different endpoint names, which the scenario forbids.

Keep latency-based routing, and set the weights so the secondary Region rarely receives traffic unless manual changes are made.

Why it fails: Latency-based routing selects the Region with the lowest network latency for each user, while weighted routing merely distributes traffic according to fixed percentages. Neither policy reacts to health checks or automatically shifts traffic when the primary Region fails; the weights would remain unchanged, so the secondary Region would only receive its small configured share until someone manually adjusts the weights or the primary record is removed. This approach requires operational intervention and does not provide the deterministic, health-check-driven failover the company needs.

Use an alias A record that returns both ALBs simultaneously so clients automatically load balance across Regions during outages.

Why it fails: An alias A record in Route 53 can point to a single ALB, so returning both ALBs simultaneously would require multiple A records under the same name. Even if both are returned, DNS does not force clients to load balance; each client randomly picks one of the returned IPs, and a client may continue using the unhealthy primary Region. Health checks without a failover routing policy do not remove the unhealthy ALB from the response set, so this approach cannot guarantee that traffic shifts to the secondary only after primary failure.

Use geolocation routing to route users to the primary Region and rely on ALB health checks to shift requests between Regions.

Why it fails: Geolocation routing directs users to the Region you map based on their geographic location, not on the health or availability of the ALBs. The ALB's own health checks only control whether individual targets behind that ALB are considered healthy; they have no effect on Route 53's geolocation mapping. Thus, users in the primary Region would still be routed to the primary ALB even if it is completely unhealthy, and there is no mechanism to shift requests to the secondary Region automatically.

Weighted routing

Why it fails: Weighted routing assigns a relative weight to each record and proportionally distributes DNS answers among all records, for example 80% primary and 20% standby, which intentionally sends traffic to both endpoints at all times. Unlike failover routing, it does not encode an explicit active-passive relationship; even with health checks, weighted routing simply removes unhealthy records from the denominator and continues splitting traffic among the remaining records based on original weights. This makes it suitable for load distribution or canary releases, but it does not model the 'primary always preferred, standby only on failure' pattern described in the question.

Geolocation routing

Why it fails: Geolocation routing evaluates the geographic origin of the client's DNS resolver and maps that location to a designated record, such as sending US users to us-east-1 and European users to eu-west-1. This policy is location-driven, not health-driven; if the primary endpoint fails, users from that region will still receive the DNS record pointing to the unhealthy endpoint until an administrator manually changes the geographically assigned record. It therefore cannot automatically redirect all traffic to the standby environment during an outage.

Latency-based routing

Why it fails: Latency-based routing answers DNS queries by returning the endpoint that appears to have the lowest latency from the calling resolver's network, so users are directed to whichever site is fastest rather than to a pre-defined primary site. Even if health checks eliminate unhealthy endpoints, the decision when both sites are healthy is purely performance-based, which can send traffic to the standby region during normal operation. This fails the active-passive requirement where the primary region must always be preferred unless it is actually unhealthy.

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

Why it fails: 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 it fails: 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 it fails: 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.

AWS Organizations service control policies

Why it fails: SCPs govern maximum permissions for accounts in an organisation; they cannot detect endpoint health or trigger cross-Region failover. They are tempting because they enforce guardrails centrally, which is the right tool for restricting services across accounts, not for resilience routing.

S3 Transfer Acceleration

Why it fails: S3 Transfer Acceleration speeds uploads to a bucket via edge locations; it neither monitors endpoint health nor redirects traffic between Regions. It is tempting for globally distributed uploads where latency, not failover, is the design driver.

Use latency-based routing with one record per region and no health checks.

Why it fails: Latency-based routing chooses the region with the lowest network latency for each individual user, but without health checks it will continue to return an endpoint even after that region becomes unhealthy. Because it has no primary/secondary concept, failover is not deterministic, and the response can vary per user based on their geographic location, causing some users to keep hitting the failed region until the DNS TTL expires. It also cannot automatically shift all traffic to a single healthy standby region, as required for a controlled disaster-recovery failover.

Use weighted routing and manually change the weights during incidents.

Why it fails: Weighted routing distributes traffic according to assigned weights, and while you could manually change weights during an incident, that requires human intervention, which slows recovery and risks configuration mistakes. Even if you associate health checks, weighted routing does not enforce a strict primary/secondary relationship; it simply removes unhealthy endpoints from rotation, meaning traffic could still be split across regions when both are healthy, and failover is not deterministic. Manual weight changes also do not account for DNS TTL caching, so impacted users may continue to receive the old answer until resolvers refresh.

Create a single alias record only for the primary region and rely on client-side DNS retries.

Why it fails: A single alias record pointing only to the primary region has no fallback target, and relying on client-side DNS retries is ineffective because most clients and resolvers cache DNS answers for the TTL and do not automatically re-query on connection failure. Without a health check and a secondary record, Route 53 has no mechanism to change the response; even if the client re-resolves, it receives the same primary IP because the record itself is unchanged. This creates a single point of failure and fails to meet the requirement for automated, deterministic failover across regions.

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

Why it fails: 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 it fails: 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 it fails: 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.

Configure Route 53 Weighted routing with 100% weight on the ALB and 0% on the S3 bucket

Why it fails: Weighted routing splits traffic based on configured weights and does not implement active-passive failover. A record with 0% weight is never returned in DNS responses, so if the ALB becomes unhealthy, Route 53 will not automatically start sending traffic to the S3 bucket. Even if a health check is associated, weighted routing only removes unhealthy weighted records from rotation; with 100% weight on the ALB and 0% on S3, there is no healthy record with nonzero weight to fail over to, so the site would go down.

Configure Route 53 Latency routing with records in both regions to route to the healthiest endpoint

Why it fails: Latency routing selects the endpoint with the lowest network latency for each client, which is not the same as health-based primary/secondary failover. If you create records in both regions, Route 53 will route users to S3 whenever S3's region is closer, even when the ALB is healthy, violating the requirement for an active-passive setup. Associating health checks with latency records can suppress unhealthy endpoints, but it still doesn't provide a deterministic primary/secondary ordering; latency routing inherently optimizes for speed, not failover semantics.

Configure Route 53 Geolocation routing with North American users directed to the ALB and all others to S3

Why it fails: Geolocation routing directs traffic based on the client's geographic location rather than endpoint health, so it cannot implement automatic failover from the ALB to S3. If North American users are pinned to the ALB record, they will continue to receive that record even when the ALB is unhealthy because geolocation routing only fails over when you define overlapping records and a default fallback, which is not part of this configuration. Additionally, users outside North America would always be sent to S3 even when the ALB is healthy, making the routing policy unsuitable for a primary/secondary architecture.

Increase the aurora_max_connections parameter on the cluster parameter group and reboot the readers

Why it fails: Raising max_connections increases the ceiling but each new connection consumes memory on the DB instance, and a burst can still exhaust the instance. Rebooting readers causes downtime and does not change the fundamental connection-per-client model, so the TooManyConnections errors would recur under load. It also does not improve failover behaviour or absorb spikes efficiently.

Replace the reader endpoint with a Network Load Balancer that distributes TCP connections across the Aurora readers

Why it fails: A Network Load Balancer can distribute TCP connections, but it does not pool or reuse database connections, so each client connection still becomes a separate Aurora connection and the limit is still reached. It also bypasses Aurora's native reader endpoint health checks and failover awareness, which can route traffic to an unavailable reader. This does not meet the resilience requirement.

Convert the readers to Aurora Replicas in a second Region and use a global database secondary cluster

Why it fails: Aurora Global Database is designed for cross-Region disaster recovery and low-latency reads in remote Regions, not for absorbing connection bursts within the primary Region. The secondary cluster has its own connection limits and would not receive the primary reader traffic without application changes. It adds complexity and cost without solving the connection exhaustion problem.

Use weighted routing with a 50/50 traffic split between both Regions.

Why it fails: Weighted routing distributes DNS responses according to assigned weights, so a 50/50 split would send roughly half of clients to each Region regardless of health. If us-east-1 goes down, those clients would still receive the us-east-1 IP and experience an outage. Even if you later attached health checks, this would adjust weights only gradually, not provide the immediate, deterministic primary-to-secondary failover behavior that an active-passive design requires.

Use latency-based routing so clients always choose the fastest Region.

Why it fails: Latency-based routing measures network latency between the user's DNS resolver and each Region, then returns the Region with the lowest latency. It is designed for performance optimization across active endpoints, not for controlled failover: the lowest-latency Region could still be unhealthy and would continue to receive traffic. This approach does not give you a defined primary and secondary pair, and health-based failover would require additional health checks and routing policy changes.

Use a geolocation policy without health checks.

Why it fails: Geolocation routing directs users to the Region that corresponds to their geographic location, such as routing North American users to us-east-1 and European users to us-west-2. Without health checks, a failed Region would still be returned for its mapped user base, and there is no pre-defined secondary endpoint to take over. Geolocation solves regional residency or local latency requirements, but it is not a failover architecture.

Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.

Why it fails: Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.

Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.

Why it fails: Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.

S3 Transfer Acceleration

Why it fails: S3 Transfer Acceleration is a performance feature for uploading objects to Amazon S3: it routes your upload traffic through AWS edge locations over optimized, accelerated network paths to the destination bucket's regional endpoint. It does not monitor the health of an origin, reroute users to a different region, or make any DNS routing decision about your application endpoint. Because it only speeds data into the same S3 bucket, it has no role in failing over an inventory application from the primary to a secondary region.

AWS Organizations service control policies

Why it fails: Service control policies (SCPs) are authorization guardrails used with AWS Organizations to restrict which AWS services and actions principals in an OU or account can use; for example, you could deny certain resource-modifying actions to enforce security boundaries. They do not inspect endpoint health, evaluate HTTP responses, or perform DNS-based traffic management, and they cannot dynamically change DNS records to route users to a working region. Thus SCPs are entirely unrelated to availability or failover behavior.

Create a weighted record set that sends 50 percent of traffic to each Region.

Why it fails: A weighted record set with a 50/50 split balances traffic across both ALBs simultaneously, which is appropriate for load distribution or canary testing. Weighted routing does not define one endpoint as primary and another as backup; if a health check disables one record, Route 53 simply reroutes all traffic to the other healthy record, but there is no ordered failover relationship. The scenario calls for a deliberate primary/secondary design, not proportional traffic splitting.

Create a latency-based record set so Route 53 always prefers the fastest Region.

Why it fails: Latency-based routing selects the Region that offers the lowest latency for each individual client, so geographically distributed clients may be sent to different Regions concurrently. This creates an active-active pattern in which both ALBs normally serve traffic, rather than keeping one inactive until the other fails. The routing decision is based on network performance, not an explicit failover order, so it does not implement a strict primary-to-secondary failover policy.

Create a multivalue answer record to return both ALB addresses on each lookup.

Why it fails: A multivalue answer record returns up to eight healthy IP addresses per response, chosen randomly via DNS, and each value must be associated with its own health check. This approach improves availability by giving clients multiple endpoints to try, but it lacks any notion of a primary or secondary relationship among the records. It also requires clients to handle multiple addresses and retries, whereas Route 53 failover routing actively replaces an unhealthy primary with a designated secondary in the DNS response.