Load balancing with the reader endpoint - Amazon Aurora MySQL Database Administrator’s Handbook

Load balancing with the reader endpoint

Because the reader endpoint contains all Aurora Replicas, it can provide DNS-based, random reader assignment for new connections. Every time you resolve the reader endpoint, you'll get an instance IP that you can connect to, chosen randomly.

DNS works at the connection level (not the individual query level). You must keep resolving the endpoint without caching DNS to get a different instance IP on each resolution. If you only resolve the endpoint once and then keep the connection in your pool, every query on that connection goes to the same instance. If you cache DNS, you receive the same instance IP each time you resolve the endpoint.

You can use Amazon RDS Proxy to create additional read-only endpoints for an Aurora cluster. Applications can reconnect more quickly to the proxy endpoints than the Aurora reader endpoint if reader instances become unavailable.

If you don’t follow best practices, these are examples of issues that can occur:

  • Unequal use of Aurora Replicas, for example, one of the Aurora Replicas is receiving most or all of the traffic while the other Aurora Replicas sit idle.

  • After you add or scale an Aurora Replica, it doesn’t receive traffic or it begins to receive traffic after an unexpectedly long delay.

  • After you remove an Aurora Replica, applications continue to send traffic to that instance.

For more information, refer to the DNS endpoints and DNS caching sections of this document.