Application failover configuration

Your application needs no failover configuration of its own: the DBO proxy handles failover and load balancing for you. Your application connects to one of the proxy's two endpoints (read-write or read-only), and the proxy spreads its connections across the database instances behind it, round-robin. Health-check probes run continuously: an instance that fails its checks is removed from the load balancer until it is healthy again, so new connections only ever land on instances that can serve them.

The proxy endpoint itself is resilient too. The proxy runs as a Kubernetes ClusterIP service, which provides stable IP routing to healthy proxy pods: while pods restart or are rescheduled, the service address stays the same and Kubernetes automatically routes your connections to available proxy pods at the IP level.

For the proxy hostname and port to use in your connection string, see Connecting client applications.

Optional: falling back to a direct database connection

Teams that want an application-level safety net, reconnecting directly to the database if the proxy endpoint itself becomes unreachable, can build one with standard load-balancer or DNS failover patterns, for example an NLB in front of the proxy with Route 53 failover routing to the direct database endpoint.

Next steps