It depends 😉
On a few occasions I’ve heard people ask If you can do this when considering RDS for high availability. Usually the main reason is cost concerns.
Some people don’t like the fact that when setting up Multi-AZ deployments your costs basically double.
So while it is possible to use a Read Replica as a failover standby, it’s not without some complications.
Read replicas are used to offload read traffic from your primary DB, they’re not really used for failover.
Multi-AZ deployments use synchronous replication to make sure that the primary DB and standby DBs are in sync.
Read replicas are asynchronous, which means there’s a lag between the primary DB and the replicas.
If your primary goes down for whatever reason the replica will be out of sync with the written data.
You can promote a replica to become the primary but there isn’t an automatic way to do this and you’d also need to figure out how to sync the data that was missed while the primary was down.
If you’d rather just get back to building features with minimal downtime, it’s probably a safer bet to go with Multi-AZ.
You get automatic switching during a failover, handled by AWS. In most cases it’s around a minute or two.
So, while you can use a Read Replica for failover in AWS RDS, it’s not the easiest or most reliable method. It’s much smoother, and automated, to let AWS handle it with a Multi-AZ deployment instead.