Aurora Global Database
Putting Writes on the Global Writer Endpoint at Deployment, Not During the Outage
- Global writer endpoint tracking the current primary across switchover/failover, with extra write safeguards.
- DNS TTL ~5s recommendation and the DNS-change RDS event.
- Cluster-endpoint "-ro" stripping for promoted/manual endpoints.
- RDS Proxy: per-cluster endpoints need repointing; SESSION read-consistency unsupported through the proxy.
Production premise
The endpoint you put writes on decides how failover behaves. The global writer endpoint is a DNS name that always resolves to the current primary, through switchovers and managed failovers alike. During fencing windows — the intervals when a failed Region is being cut off from writes — Aurora applies additional write safeguards to the traffic you send through this endpoint.
Cluster endpoints do not follow the role. When a secondary is promoted,
its writer endpoint is its old reader endpoint minus -ro:
my-global.cluster-ro-… becomes my-global.cluster-…. Applications
bound to cluster endpoints therefore need config changes in the middle
of the incident.
Reads belong on each Region's own reader endpoint, for local latency. RDS Proxy users have one more move after a promotion: repoint to the new primary's proxy endpoint.
Failure mode & inflection point
There are two ways this fails.
The first: applications hardcode the primary Region's cluster endpoint. Failover happens, and writes keep aiming at a dead endpoint — or worse, at the recovered old primary, whose data has diverged — until someone edits config under pressure.
The second: DNS caches with default TTLs hold the stale global-endpoint record after promotion. During that window, writes land on the fenced Region. AWS's own guidance is that fencing is best-effort, not a guarantee.
Production guardrail
Default: every write path in every Region connects through the global writer endpoint. The endpoint's own record is AWS-managed — what you control is caching on your side. AWS's recommendation is to cut the DNS cache TTL in your application and network layers to about 5 seconds. Add an alarm on the RDS event that signals the global endpoint's DNS change, so you can confirm the application registered the new primary before resuming writes.
Do not front the global endpoint with a cross-region RDS Proxy. Proxy endpoints are per-cluster and need manual repointing anyway — the proxy adds a layer without removing the manual step.