AWS Certified Solutions Architect – Associate (SAA-C03)Design Cost-Optimized ArchitecturesMedium
A company has a legacy application that relies on a single relational database instance. This database is experiencing performance bottlenecks due to high read traffic, especially during peak business hours. The company wants to improve read performance and introduce high availability without re-architecting the application significantly. They also need a cost-effective solution. Which AWS database strategy should they employ?
- AImplement Amazon ElastiCache for database caching
- BMigrate to Amazon DynamoDB
- CUpgrade the existing RDS instance to a larger size
- DAdd Amazon RDS Read Replicas
Show answer & explanationAnswer & explanation
Correct answer: D. Add Amazon RDS Read Replicas
Amazon RDS Read Replicas allow you to create one or more read-only copies of your primary database instance. They are a cost-effective way to scale out read operations, offloading read traffic from the primary instance, and can also be promoted to a standalone database in case of primary instance failure, improving availability without significant application changes.
Why the other options are wrong
- A. ElastiCache is for caching frequently accessed data, which can help some read performance, but read replicas directly scale the database's read capacity and provide high availability benefits, which is a more direct and often more comprehensive solution for 'high read traffic' and 'high availability' for a relational database.
- B. Migrating to DynamoDB (NoSQL) would require significant application re-architecture, which is explicitly excluded by the 'without re-architecting the application significantly' constraint.
- C. Upgrading the existing RDS instance (scaling up) would increase costs and might not fully address read-heavy bottlenecks as effectively as scaling out with read replicas, especially if the bottleneck is due to concurrent read operations.
Amazon RDS Read Replicas
Amazon RDS Read Replicas provide an easy way to scale out read-heavy database workloads. Updates made to the source database are asynchronously copied to the read replica(s).
- Scales read operations, offloading from the primary instance.
- Can be promoted to a standalone database for disaster recovery.
- Supports MySQL, PostgreSQL, MariaDB, Oracle, SQL Server.
- Cost-effective way to improve read performance and availability.
Memory trick: For read-heavy databases, make copies to share the work, like multiple librarians for a busy library.