Use read replicas to scale beyond the compute or I/O capacity of a single DB instance for read-heavy database workloads. You can direct this excess read traffic to one or more read replicas.
To serve read traffic while the DB instance is unavailable
Use read replicas to serve read traffic when the source DB instance isn't available. Your source DB instance might not be available to take I/O requests, for example, because of I/O suspension for backups or scheduled maintenance. If your source DB instance isn't available to take requests, then you can direct read traffic to your read replicas.
Note: Because the source DB instance is unavailable, the data on the read replica might be stale.
For business reporting or data warehousing scenarios
Use read replicas for business reporting or data warehousing scenarios to run business reporting queries against a read replica instead of your production DB instance.
For disaster recovery
Use read replicas to implement disaster recovery. Promote a read replica to a standalone instance as a disaster recovery solution if the primary DB instance fails.
Best practices for read replicas
Use read replicas in different Regions to improve response times
Because replica creation can lead to I/O latency, it's a best practice to create read replicas when you anticipate a light database load. To mitigate I/O latency on your source DB instance and during read replica setup, use high availability (Multi-AZ) for Amazon RDS.
Mirror the source database
For optimal performance, the read replica must mirror the source database. If you use the Amazon RDS console to create a read replica, the console applies the source database settings by default.