Endpoints: How to Connect

Because Aurora clusters can have up to 15 Read Replicas — all sharing the same storage — managing individual IP addresses for each instance would be operationally unworkable. Aurora solves this with Endpoints: stable DNS names that abstract the underlying instance topology. Your application connects to a DNS name, not an IP address, so Aurora can change which instance is behind that name without requiring any application reconfiguration.

1. Cluster Endpoint (The Writer)

• Points to: The current Primary (Writer) instance.
• Use for: All INSERT, UPDATE, DELETE, and DDL operations. Any operation that modifies data must go here.
• Behavior on Failover: When the Primary fails, Aurora promotes a Read Replica to become the new Primary and automatically updates this DNS record to point to it. The TTL on this DNS record is very short (typically 5 seconds), so your application reconnects to the new Primary quickly.

2. Reader Endpoint (The Load Balancer)

• Points to: All available Read Replicas in the cluster.
• Use for: SELECT queries — reporting dashboards, analytics, read-heavy API endpoints.
• Behavior: The Reader Endpoint uses DNS round-robin. Each time your application resolves this DNS name, it receives the IP of a different replica, distributing read traffic across all available replicas automatically. If a replica fails, Aurora removes it from the DNS rotation.

3. Instance Endpoints

• Points to: A specific, individual instance in the cluster by name.
• Use for: Debugging, maintenance, or when you need to run a specific query on a specific node. Not recommended for production application traffic because it bypasses Aurora's automatic failover routing.

4. Custom Endpoints

• Use Case: When your replicas are not all the same size. For example, you might have 2 large db.r6g.8xlarge instances dedicated to heavy analytical queries and 4 smaller db.r6g.large instances handling web application reads.
• Behavior: You define a Custom Endpoint that includes only the large instances. Your analytics team connects to the Custom Endpoint; your web application connects to the Reader Endpoint (which you configure to exclude the large instances). This prevents a runaway analytics query from consuming resources needed by the web app.