RDS Multi-AZ Failover DNS Caching: Common Issue

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The RDS CNAME record was not updated by AWS after the failover.

  Why it's wrong here

  This is incorrect because AWS RDS Multi-AZ failover automatically updates the DNS CNAME record for the primary DB instance to point to the new primary (the former standby) within seconds. The CNAME is managed by RDS and is updated programmatically during the failover, so a stale CNAME due to AWS not updating it is not a plausible cause. The issue is more likely that the application itself has cached the resolved IP from before the failover, not that the canonical record is outdated.

• ✗

  The application is using the read replica endpoint instead of the primary endpoint.

  Why it's wrong here

  This is incorrect because read replica endpoints are distinct endpoints that point to the replica instance and are not used for primary read/write traffic. In a Multi-AZ deployment, failover affects only the primary endpoint; the read replica endpoint remains unchanged, so if the application were using a replica endpoint it would continue to connect to the replica (read-only) and would not experience a failover-related outage. The symptom described—connection failures or stale data after failover—indicates the application is using the primary endpoint but has not re-resolved its DNS.

• ✗

  The application is using a Route 53 health check that failed and redirected traffic away from the endpoint.

  Why it's wrong here

  This is incorrect because Route 53 health checks are not automatically configured for RDS endpoints as part of the RDS service. While you can manually create a Route 53 health check that monitors an RDS endpoint (e.g., via a custom resource), the failover itself triggers a DNS change in the RDS-managed CNAME, not a Route 53 record change. Route 53 health checks do not redirect traffic away from the primary RDS endpoint during a Multi-AZ failover; they only affect records that are explicitly tied to a health check, which is not the default behavior here.

• ✓

  The application is using a cached DNS resolution that points to the old primary.

  Why this is correct

  This is correct. After an RDS Multi-AZ failover, the RDS-managed DNS CNAME is updated to point to the new primary instance's underlying IP address. However, if the application's DNS resolver (or the application itself) has cached the old IP address from before the failover, it will continue to try to connect to the old primary instance until the cache expires (based on the DNS TTL, which is typically 30–60 seconds for RDS). A long TTL or a resolver that ignores TTL can keep the stale IP in effect, causing errors (e.g., 'Communications link failure') even though the new primary is healthy.

Go deeper

Related to this question