Cost-Effective Caching for Repeated DB Reads

SAA-C03 By islever Editorial Last updated

Determine high-performing and/or scalable storage solutions. Design cost-optimized storage solutions.

Short answer

A Implement an Amazon ElastiCache for Redis cluster between the application and the DB cluster.

Question

A package delivery company has an application that uses Amazon EC2 instances and an Amazon Aurora MySQL DB cluster. As the application becomes more popular, EC2 instance usage increases only slightly. DB cluster usage increases at a much faster rate. The company adds a read replica, which reduces the DB cluster usage for a short period of time. However, the load continues to increase. The operations that cause the increase in DB cluster usage are all repeated read statements that are related to delivery details. The company needs to alleviate the effect of repeated reads on the DB cluster. Which solution will meet these requirements MOST cost-effectively?
  1. Implement an Amazon ElastiCache for Redis cluster between the application and the DB cluster. Correct Answer
  2. Add an additional read replica to the DB cluster.
  3. Configure Aurora Auto Scaling for the Aurora read replicas.
  4. Modify the DB cluster to have multiple writer instances.

Key Takeaways

The key trap is choosing more database replicas (Aurora scaling) when the workload consists of identical repeated reads that are ideal candidates for in-memory caching.

This question evaluates how to offload repeated read workloads from Amazon Aurora using a cost-effective caching layer. The correct solution is implementing Amazon ElastiCache for Redis.

Common mistake: Many learners select Option C (Aurora Auto Scaling) because it sounds like a modern, automated solution for load issues, failing to recognize that caching is significantly cheaper and more efficient for static data.

Expert Analysis

Why the Answer Is Correct

The scenario specifies that the increased load is caused by 'repeated read statements' related to delivery details. This is the textbook definition of a use case for an in-memory cache like Amazon ElastiCache for Redis. By storing the results of these frequent queries in memory, the application avoids hitting the database for every request. This drastically reduces the I/O load on the Aurora cluster. Furthermore, among the options provided, adding a cache layer is typically the most cost-effective way to handle high-frequency reads compared to provisioning additional compute or storage resources in the database tier.

Why the Other Options Are Wrong

Option B (adding another read replica) and Option C (Aurora Auto Scaling) involve adding more database instances. While this increases read capacity, it incurs significant ongoing costs for instance hours and storage. It does not reduce the fundamental inefficiency of re-querying the same data repeatedly. Option D is incorrect because Aurora MySQL clusters support only one writer instance; multiple writers are a feature of distributed databases like DynamoDB or specific multi-master setups not available in standard Aurora MySQL.

Community Comment Notes

The community strongly favors Option A, with users noting that 'repeated read statements' clearly indicate a need for a cache layer. One commenter pointed out that while Redis might seem expensive, it is more cost-effective than scaling the database for this specific pattern. Another user emphasized that adding read replicas costs money and doesn't solve the repeated query inefficiency as well as caching does.

Exam Strategy

When you see keywords like 'repeated reads', 'static data', or 'frequent lookups', immediately consider caching solutions (ElastiCache) before considering database scaling. Always evaluate the 'MOST cost-effectively' constraint to rule out over-provisioned database instances.

Frequently Asked Questions

Why not just add more Aurora read replicas?

Read replicas increase capacity but do not eliminate the overhead of repeated database queries. Caching serves the data directly from memory, which is faster and cheaper for identical requests.

Is ElastiCache always cheaper than Aurora scaling?

For high-frequency identical reads, yes. The cost of a small cache node is usually less than running additional full-sized Aurora instances that still process the same redundant queries.

More SAA-C03 FAQ →

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 6 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 6

  1. BillaRanga 👍 4 Answered A
    The question says, "The operations that cause the increase in DB cluster usage are all repeated read statements that are related to delivery details." - Read statements mean we can cache the results - hence, we need No read-replicas; we need only a cache layer to improve the performance.. Also, Adding read replicas costs money. The requirement is to meet them MOST cost-effectively
  2. sandordini 👍 4 Answered A
    A. Although Redis is not typically cheap, the question statement clearly shouts for a cached solution, which is Redis... Also, that's the only long-term solution, as we don't know anything about the volumes, scale of trends, etc...
  3. Kezuko 👍 3 Answered A
    "repeated read statements" -> Cache layer
  4. Scheldon 👍 1 Answered C
    AnswerC After topic reconsideration I will go with Aurora autoscaling To meet your connectivity and workload requirements, Aurora Auto Scaling dynamically adjusts the number of Aurora Replicas (reader DB instances) provisioned for an Aurora DB cluster. Aurora Auto Scaling is available for both Aurora MySQL and Aurora PostgreSQL. Aurora Auto Scaling enables your Aurora DB cluster to handle sudden increases in connectivity or workload. When the connectivity or workload decreases, Aurora Auto Scaling removes unnecessary Aurora Replicas so that you don't pay for unused provisioned DB instances. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html
  5. Andy_09 👍 7
    Option A
Show 1 more comment
  1. Scheldon 👍 3 Answered A
    AnswerA

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide