Task Statement 2.1: Design scalable and loosely coupled architectures.
📘AWS Certified Solutions Architect – (SAA-C03)
1. Introduction to Read Replicas
A Read Replica is a copy of a primary database instance that is used only for read operations.
In AWS, read replicas are mainly used with:
- Amazon RDS
- Amazon Aurora
The primary database instance (also called the master) handles:
- Write operations (INSERT, UPDATE, DELETE)
- Critical transactions
The read replica instances handle:
- Read queries (SELECT)
This separation allows the system to scale database workloads and improve performance.
2. Why Read Replicas Are Important
Modern applications often perform many more read operations than write operations.
Examples of read-heavy workloads include:
- Web applications retrieving user profiles
- Reporting dashboards
- Data analytics queries
- Product catalog queries
- Content management systems
If all read requests go to the primary database, the database can become overloaded.
Read replicas solve this problem by:
- Offloading read traffic
- Improving performance
- Increasing scalability
3. How Read Replicas Work
Step-by-step process
- A primary database instance receives write operations.
- The database records all changes in transaction logs.
- These logs are copied to the read replica.
- The read replica applies the same changes.
- The replica becomes an up-to-date copy of the primary database.
This process is called asynchronous replication.
Because it is asynchronous:
- Replicas may lag slightly behind the primary database.
- This delay is called replication lag.
4. Key Characteristics of Read Replicas
1. Read-only databases
Read replicas cannot accept write operations.
They are used only for:
- SELECT queries
- Reporting
- Data retrieval
2. Asynchronous replication
Replication happens after the primary database commits changes.
Because of this:
- Replicas might be a few seconds behind the primary database.
3. Multiple replicas supported
AWS allows multiple read replicas for a single database.
Example limits (varies by engine):
- Up to 15 replicas in many engines.
This increases read scalability.
4. Can be promoted to standalone databases
A read replica can be promoted to become an independent database.
When promoted:
- Replication stops
- The replica becomes a writable database
This feature is often used for:
- Disaster recovery
- Database migration
5. When to Use Read Replicas
Understanding when to use read replicas is very important for the SAA-C03 exam.
Below are the main scenarios.
5.1 When an Application Has Heavy Read Traffic
Many applications perform large numbers of read queries.
Example IT scenario:
A web application with thousands of users retrieving information from a database:
- User account data
- Product catalog
- System configuration data
If all requests go to the primary database, it can become overloaded.
Solution:
- Create multiple read replicas
- Send read queries to replicas
- Keep write operations on the primary database
Result:
- Better performance
- Reduced load on the main database
- Improved scalability
5.2 When Running Reporting or Analytics Queries
Reporting queries often:
- Scan large amounts of data
- Run complex SQL queries
- Take longer to execute
If these queries run on the primary database, they may slow down the application.
Solution:
- Run reporting queries on a read replica.
Example IT environment:
- Business intelligence dashboards
- Data analytics queries
- Periodic reporting jobs
This keeps the production database responsive.
5.3 When Offloading Background Processing
Many systems run background tasks that read large datasets.
Examples:
- Log analysis
- Data exports
- Batch processing
- Machine learning data extraction
Running these tasks on the primary database may impact application performance.
Instead:
- Run them against a read replica.
This separates:
- Application workload
- Background processing workload
5.4 When Scaling Global Applications
Applications with users in multiple regions may need faster database access.
AWS allows cross-Region read replicas.
This means:
- Primary database in one region
- Read replicas in other AWS regions
Example architecture:
- Primary database: US region
- Read replica: Europe region
- Read replica: Asia region
Benefits:
- Lower latency for users
- Faster data retrieval
- Improved global performance
5.5 When Creating Disaster Recovery Options
Read replicas can help create disaster recovery architectures.
If the primary database fails, a read replica can be:
- Promoted to a new primary database
This reduces downtime.
Important note for the exam:
Read replicas are not automatic failover mechanisms.
Automatic failover is handled by:
- Amazon RDS Multi-AZ
6. Read Replicas vs Multi-AZ Deployments
Students often confuse Read Replicas with Multi-AZ deployments.
Understanding the difference is critical for the exam.
| Feature | Read Replicas | Multi-AZ |
|---|---|---|
| Purpose | Improve read scalability | Provide high availability |
| Read traffic | Yes | No |
| Writes allowed | No | No (standby) |
| Replication type | Asynchronous | Synchronous |
| Failover | Manual promotion | Automatic failover |
| Performance scaling | Yes | No |
Summary:
- Use Read Replicas → for scaling reads
- Use Multi-AZ → for high availability
7. Supported Database Engines
Read replicas are supported by several engines in:
Amazon RDS
Examples:
- MySQL
- PostgreSQL
- MariaDB
- Oracle
- SQL Server
Also supported in:
Amazon Aurora
Aurora has enhanced replica capabilities:
- Up to 15 replicas
- Very low replication lag
- Faster failover
8. Benefits of Using Read Replicas
1. Improved database performance
Read replicas reduce the workload on the primary database.
2. Increased scalability
Applications can support more users and queries.
3. Isolation of workloads
Different workloads can run on different replicas.
Examples:
- Application reads
- Analytics queries
- Reporting
4. Better global performance
Cross-region replicas reduce latency for international users.
5. Disaster recovery support
Replicas can be promoted if the primary database fails.
9. Limitations of Read Replicas
Students should also understand the limitations.
1. Replication lag
Because replication is asynchronous:
- Data on the replica might not be fully up to date.
Applications requiring real-time consistency should read from the primary database.
2. Read-only access
Read replicas cannot accept write operations.
3. Manual failover
Failover is not automatic unless using other AWS services.
4. Additional cost
Each replica is a separate database instance, which increases cost.
10. Exam Tips for SAA-C03
These patterns frequently appear in AWS exam questions.
Use Read Replicas when:
- The application has heavy read workloads
- You need to scale database reads
- Reporting queries impact performance
- Analytics queries need a separate database
- Global users require low-latency reads
- Background jobs need database access
Do NOT use Read Replicas when:
- The requirement is automatic failover
- The requirement is high availability only
Instead use:
- Amazon RDS Multi-AZ
11. Quick Architecture Summary
A typical architecture with read replicas looks like this:
Application Layer
↓
Load Balancer / Database Router
↓
Primary Database (Write Operations)
↓
Read Replica 1 (Read Queries)
Read Replica 2 (Read Queries)
Read Replica 3 (Read Queries)
This architecture allows the system to:
- Handle large volumes of read traffic
- Maintain performance
- Scale efficiently.
✅ Key takeaway for the exam:
Use Read Replicas when you need to scale read operations and improve database performance, but use Multi-AZ deployments when the requirement is high availability and automatic failover.
