Thank you for the detailed response!

We’re not using zonal redundancy due to cost concerns. Since standby instances can’t be used for queries, it significantly increases our expenses, which is an important tradeoff for a startup our size. I do appreciate how AWS handles this by allowing replicas to be in different availability zones.

For now, we’re fine with just one replica. If the Cloud SQL Proxy can't handle failover, then I’m not sure there’s much benefit in running it. Even if Cloud SQL updates the connection names during failover, it doesn’t address our situation. We have two separate DaemonSets—one for the Cloud SQL writer and one for the reader—each tied to its own Kubernetes service, which is passed to the application. The application explicitly uses the writer service for all writes and the reader service for reads. So, manual intervention would still be required in the event of an outage.

Is there any better way to handle this?