AWS Aurora Support
Aurora failover and DNS caching behavior.
Aurora promotes a reader quickly, but applications often keep talking to the old writer because of cached DNS or pooled connections. The cluster endpoint is a CNAME that changes, so recovery speed depends on your clients. We test and tune the client side.
When You Need This
The situations where this work pays for itself.
Signs it is time
- The app stays down after a failover though the database recovered
- Connections keep failing with read-only errors after failover
- Java services cache DNS lookups indefinitely
- You want to know your real recovery time for an incident report
- You use custom endpoints or multiple clusters behind one app
What you get
- Measured failover timeline for each service
- Driver, pool and DNS settings changes
- Promotion tier configuration
- Failover runbook and alarms
How we do it
A clear, safe process you can follow along with.
1. Understand the endpoints in use
We list the cluster, reader and custom endpoints your applications use, and confirm none use instance endpoints or IP addresses that go stale after promotion.
2. Check promotion tiers
Failover chooses a reader by promotion tier and size. We set tiers so a suitably sized reader is promoted and the writer does not end up on a weak instance.
3. Review client DNS caching
We check runtime caching, such as JVM networkaddress.cache.ttl, connection pool lifetime, sidecars and OS caches, and set short values, since the endpoint's DNS record has a short TTL.
4. Handle read-only errors
A client still connected to the old writer, now a reader, receives read-only errors on writes. We configure the pool to drop and re-resolve on such errors, or use the AWS-provided drivers that understand Aurora topology.
5. Consider RDS Proxy
A proxy keeps client connections and reconnects to the new writer itself, which can shorten the visible outage. We evaluate it against pinning and cost.
6. Run a controlled failover
We trigger a failover, measure from first error to full recovery for each service, and fix slow ones, then repeat.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Using instance endpoints
They point at one instance, not the current writer.
Long-lived pools with no validation
Dead or read-only connections stay in the pool unless validated.
Hard-coding cached IPs in config
Failover changes the address behind the endpoint.
Frequently Asked Questions
How long does Aurora failover take?
It is often around a minute or less but varies with load and recovery. Measure real client recovery time, which includes DNS and connection pool behavior.
Why do I get read-only errors after Aurora failover?
The client is still connected to the old writer, which became a reader. Re-resolve DNS and recreate connections, or use a driver that tracks cluster topology.
Should I use the cluster endpoint or instance endpoints?
Use the cluster endpoint for writes and the reader or a custom endpoint for reads. Instance endpoints do not follow the writer.
Want Help With Aurora failover and DNS caching behavior?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required