Task Statement 3.3: Determine high-performing database solutions.
📘AWS Certified Solutions Architect – (SAA-C03)
1. What Are Read Replicas?
A read replica is a read-only copy of a primary database.
- The primary database (writer) handles:
- All write operations (INSERT, UPDATE, DELETE)
- The read replicas handle:
- Read operations (SELECT queries)
Data is copied from the primary database to replicas using asynchronous replication.
Key Concept:
- Replication is eventually consistent
- There may be a small delay (replication lag) between primary and replicas
2. Why Use Read Replicas?
1. Improve Performance (Read Scaling)
- Offload read traffic from the primary database
- Helps in read-heavy workloads
2. Increase Availability
- Applications can read from replicas if primary is under heavy load
3. Support Distributed Applications
- Place replicas in different regions for low-latency reads
4. Reporting and Analytics
- Run heavy queries on replicas without affecting the main database
3. AWS Services That Support Read Replicas
Amazon RDS
Supports read replicas for:
- MySQL
- PostgreSQL
- MariaDB
- Oracle
- SQL Server (uses different mechanisms like Always On)
Amazon Aurora
- Supports up to 15 read replicas
- Replicas share the same storage (faster replication)
- Much lower replication lag than RDS
4. How Read Replication Works
- Application writes data to Primary DB
- Changes are recorded (transaction logs)
- Logs are sent to read replicas
- Replicas apply changes asynchronously
Important:
- Replicas are read-only
- Cannot directly write to replicas (except special cases like Aurora multi-master)
5. Configuring Read Replicas (Step-by-Step Concept)
Step 1: Enable Backups
- Automated backups must be enabled on the primary DB
Step 2: Create Read Replica
- Choose:
- Same region or different region
- Instance type
- Storage type
Step 3: Configure Connectivity
- Set endpoint for applications
- Update application to send read queries to replica endpoint
Step 4: Monitor Replication
- Check:
- Replication lag
- CPU usage
- Connections
6. Types of Read Replicas
1. Intra-Region Read Replicas
- Located in the same region
- Used for:
- Scaling reads
- High performance
2. Cross-Region Read Replicas
- Located in a different region
- Used for:
- Disaster recovery
- Global applications
7. Promoting a Read Replica
A read replica can be promoted to a standalone database.
When used:
- Primary database failure
- Disaster recovery scenario
Important Notes:
- Promotion breaks replication
- Replica becomes independent
- Applications must be updated to use new endpoint
8. Read Replicas vs Multi-AZ
This is a very common exam question.
| Feature | Read Replica | Multi-AZ |
|---|---|---|
| Purpose | Performance (read scaling) | High availability |
| Read/Write | Read-only | Standby (not used for reads) |
| Replication | Asynchronous | Synchronous |
| Failover | Manual (promote) | Automatic |
| Use Case | Heavy read workloads | Critical production systems |
Key Exam Tip:
- Need better performance → Read Replica
- Need automatic failover → Multi-AZ
9. Read Replica Limitations
- Replication lag (eventual consistency)
- Not suitable for:
- Strong consistency requirements
- No automatic failover (unless Aurora)
- Additional cost (each replica is a separate instance)
- Write operations not allowed
10. Best Practices for Configuring Read Replicas
1. Use for Read-Heavy Workloads
- Identify applications with high read traffic
2. Monitor Replication Lag
- Important for time-sensitive applications
3. Distribute Read Traffic Properly
- Use load balancing or application logic
4. Choose Right Instance Type
- Match workload requirements
5. Use Cross-Region Replicas for DR
- Helps in disaster recovery planning
6. Combine with Caching
- Use caching (e.g., ElastiCache) to further reduce load
11. Aurora-Specific Features (Important for Exam)
- Reader endpoint automatically balances read traffic
- Faster replication using shared storage
- Auto-scaling replicas
- Supports failover to a replica (better than RDS)
12. Common Exam Scenarios
Scenario 1:
Application has heavy read traffic
→ Use Read Replicas
Scenario 2:
Need global users with low latency
→ Use Cross-Region Read Replicas
Scenario 3:
Primary DB failure recovery
→ Promote Read Replica
Scenario 4:
Need automatic failover with no manual action
→ Use Multi-AZ (NOT read replicas)
13. Key Takeaways (Must Remember)
- Read replicas are used for scaling reads
- Replication is asynchronous
- Replicas are read-only
- Can be promoted to standalone DB
- Not a replacement for Multi-AZ
- Aurora is more advanced than RDS for replicas
