Route 53 TTL Optimization: Balance Propagation and Cache (2026)

Route 53’s TTL values are a delicate balancing act between how quickly DNS changes propagate across the internet and how much DNS traffic your application generates.

Let’s watch a real-time DNS lookup with different TTLs. Imagine we have a record for app.example.com.

First, a high TTL, say 24 hours (86400 seconds).

# On a client machine, first lookup
dig app.example.com +short
# Output might be: 192.0.2.1

# Wait 1 hour, then lookup again
dig app.example.com +short
# Output will likely still be: 192.0.2.1

The DNS resolver (like your ISP’s DNS server or Google’s 8.8.8.8) caches the record for 24 hours. This means subsequent requests from clients using that resolver within that window don’t even ask Route 53; they just serve the cached answer. This drastically reduces DNS query load on Route 53 and speeds up lookups for clients.

Now, a low TTL, say 60 seconds.

# On a client machine, first lookup
dig app.example.com +short
# Output might be: 192.0.2.1

# Wait 30 seconds, then lookup again
dig app.example.com +short
# Output will likely still be: 192.0.2.1

# Wait another 30 seconds, then lookup again
dig app.example.com +short
# Output might be: 192.0.2.2 (if we changed it)

With a 60-second TTL, the resolver only holds the record for a minute. After that, it must ask Route 53 again. This ensures changes propagate very quickly, but it means many more queries hit Route 53.

The problem this solves is managing the trade-off between quick failover/updates and DNS query costs/performance. If your IP address changes frequently (e.g., dynamic scaling, quick deployments), you need a low TTL. If your IP is stable, a high TTL is almost always better.

Internally, when a DNS resolver receives a query for app.example.com, it first checks its local cache. If the record is there and hasn’t expired (based on its TTL), it returns the cached IP. If it’s not in the cache or has expired, the resolver queries Route 53. Route 53, in turn, looks up the record, returns the IP address, and tells the resolver the TTL for that record. The resolver then caches it for that duration.

The exact levers you control are the TTL values set on each DNS record in Route 53. You can set this per record type (A, CNAME, MX, etc.). For an A record, you’ll find the TTL field in the "Value" section when editing the record.

{
  "Comment": "Update A record",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "TTL": 300, // This is the TTL in seconds
        "ResourceRecords": [
          {
            "Value": "192.0.2.1"
          }
        ]
      }
    }
  ]
}

Here, TTL: 300 means the record will be cached by resolvers for 300 seconds (5 minutes).

The one thing most people don’t realize is that the TTL you set in Route 53 is a suggestion to the DNS resolvers. While most well-behaved resolvers respect it, a resolver could theoretically ignore it or cache for longer. However, for practical purposes and standard resolvers (like your OS, your ISP, Google DNS, Cloudflare DNS), the TTL is reliably honored. This means you can confidently set your TTLs knowing they will govern cache behavior.

The next concept you’ll encounter is how to use Route 53 latency-based routing or geolocation routing to serve different IPs based on where the user is, and how TTL interacts with those strategies.