Why TTL plays a part in this question?

[SalientListener]

Good Day. I come across this question in the question bank. I am trying to understand the reasoning behind the answer choice. Question does not mention anything about client connecting to INSTANCE endpoints. Which means it should be connecting to the CLUSTER endpoint which is a CNAME. From the explanation, it sounds like too high TTL for DNS names can cause these problems esp when connecting to an IP – but Cluster EP are great BECAUSE we dont use IP or instance EP directly so the TTL factor should not matter since the clients should have been connecting the correct cluster EP and the underlying DNS switch happens automatically. Can someone confirm if my understanding is correct?

A database team is investigating an application connection failure on an Amazon Aurora MySQL DB cluster with multiple Aurora Replicas in the same Region that had been running with no issues for the past 2 months. The connection failure lasted for 5 minutes and corrected itself after that. The Database Specialist reviewed the events from Amazon CloudWatch and verified that a failover event did occur during that time. It took the failover process around 15 seconds to complete.

Which of the following most likely caused the 5-minute connection outage?

(Ans) The client-side application’s time-to-live is set too high and is caching the old DNS data

[Tutorials-Dojo]

Thank you for posting your question.

The scenario is actually based on the event where an Amazon Aurora failover occurs. You have to check if your client application is caching the DNS data of your DB instances, and set the appropriate TTL. Keep in mind that in the actual AWS exam, there would be scenarios where it won’t explicitly mention certain details, such as the client application that caches the DNS data.

This is supported in the official AWS documentation:

• If your client application is caching the Domain Name Service (DNS) data of your DB instances, set a time-to-live (TTL) value of less than 30 seconds. The underlying IP address of a DB instance can change after a failover. Thus, caching the DNS data for an extended time can lead to connection failures if your application tries to connect to an IP address that no longer is in service. Aurora DB clusters with multiple read replicas can experience connection failures also when connections use the reader endpoint and one of the read replica instances is in maintenance or is deleted.

Reference:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html