How to design AWS RDS MySQL for high-volume write imports?
Short answer
A Use Amazon RDS for MySQL with Provisioned IOPS SSD storage and monitor CloudWatch write metrics, adjusting IOPS as the write-heavy import volume demands.
Question
Key Takeaways
Tested on matching RDS storage to sustained high write IOPS; the trap is assuming ElastiCache caching fixes write pressure when it primarily serves read traffic.
A high-volume MySQL write workload is best migrated to Amazon RDS for MySQL with Provisioned IOPS SSD storage, monitored via CloudWatch so IOPS can be adjusted. This page establishes why option A addresses the write-heavy import pattern better than ElastiCache, DocumentDB, or Amazon EFS.
Common mistake: Many candidates choose B and insert ElastiCache to absorb the load, but caching helps repeated reads, not the regular high-volume writes from the client-facing application.
Expert Analysis
Why the Answer Is Correct
The scenario describes a MySQL database that accepts regular imports from a client-facing application and generates a high volume of write operations, so the primary requirement is deterministic storage performance for writes. Amazon RDS for MySQL with Provisioned IOPS SSD storage lets the architect allocate dedicated IOPS rather than relying on the burst behavior of General Purpose SSD, which fits a sustained write-heavy import pattern. CloudWatch monitoring provides visibility into write metrics and allows the provisioned IOPS level to be adjusted as traffic grows or changes. Keeping the engine as MySQL also avoids an unnecessary database migration, so the application can be relocated with minimal query changes. This is the most direct AWS design for relieving the performance concern while preserving relational MySQL semantics.
Why the Other Options Are Wrong
Option B places an ElastiCache cluster in front of RDS and has the application query the cache instead, but ElastiCache is an in-memory caching layer for read-heavy access patterns; it does not remove the regular imports and write operations that are stressing MySQL. Even a write-through strategy still writes to the database and would not eliminate the insert and import load described in the question. Option C switches to Amazon DocumentDB, which is MongoDB-compatible rather than MySQL-compatible, so it is the wrong database engine for relocating an existing MySQL workload. Option D uses Amazon EFS, a file system rather than a relational database service, so changing performance modes does not solve MySQL write throughput or provide SQL database capabilities.
Community Comment Notes
Most learners selected option A, and Hkayne captured the key point that the problem is a “high volume of write,” so ElastiCache is unnecessary. Scheldon argued for Provisioned IOPS over General Purpose SSD and noted that CloudWatch can be used to monitor and adjust the setup as needed. sandordini and GOTJ defended option B using an in-memory caching and write-through approach, but that reasoning assumes the bottleneck is repeated reads rather than the regular imports driving writes into MySQL. The stronger consensus correctly focuses on storage IOPS for the write-intensive RDS database rather than adding a read cache.
Official Reference
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
This link opens the official vendor documentation in a new tab.
Exam Strategy
When a question mentions high write volume for a relational database, map the requirement to storage IOPS first, not to read caching. Provisioned IOPS SSD is the SAA-C03 signal for sustained database write performance, while ElastiCache is usually a distractor for read-heavy workloads.
Frequently Asked Questions
Why doesn't ElastiCache solve the high-volume write problem for MySQL?
When should I choose Provisioned IOPS SSD for Amazon RDS?
Community Votes
80% 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
-
Hkayne 👍 5 Answered AA or B. Can't be B because there is high volume of write no need for Elasticache
-
Scheldon 👍 4 Answered AAnswer A For sure we cannot choose generar purpose IOPS SSD hence I would choos provisioned one. addtionally it is a good idea to monitor performance with CloudWatch and adjust setup(provisioned IOPS) if there will be a need.
-
Tanidanindo 👍 4 Answered AAmazon RDS for MySQL DB instance with Provisioned IOPS SSD storage
-
sandordini 👍 3 Answered BThe most effective strategy for coping with that limit is to supplement disk-based databases with in-memory caching (Elasticache for Redis, Write-through strategy) I'd go for B...
-
KennethNg923 👍 3 Answered Ahigh volume of write operation -> Provisioned IOPS SSD storage
Show 1 more comment
-
GOTJ 👍 1 Answered BEven though option "A" makes sense, everybody discarding option "B" is focusing on improving the import process performance itself by using ElastiCache, which is basically correct. However, there is not a clear indicator that the “client-facing application” ONLY performs high volumes of write operations. In fact, this can be pointless (a “write only” database?). In my opinion, the main concern of the company is how THE REST of the application processes might be affected while this write-intensive operations run in the database. And those operations surely includes reads. Using an ElastiCache in front of the RDB instance or creating a read replica to redirect reads to might help with performance of THE REST of application when write-intensive imports processes are executing, as the query result might be cached. My vote goes to “B”
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →