Database cost optimization: SAA-C03 study notes and practice questions
What to know about Database cost optimization for the SAA-C03 exam, from the Design Cost-Optimized Architectures domain (20% of the exam guide), then 2 free questions to test it. Part of the SAA-C03 study guide.
Database cost questions describe how a database is used (busy all day, quiet at night, spiky, only during business hours) and ask how to pay less without losing what the scenario needs.
DynamoDB capacity modes
Mode
Billed by
Best for
On-demand
Each read and write request
Unpredictable or spiky traffic, new tables, mostly idle tables
Provisioned (with auto scaling)
Read and write capacity units per hour
Steady or predictable traffic; reserved capacity discounts it further
Other DynamoDB levers: Standard-IA table class for tables that store a lot but are read rarely; TTL to delete expired items at no cost.
Relational databases
Stop RDS or Aurora instances when they’re not needed (development, office-hours workloads). Stopped instances aren’t billed for instance hours (storage still is), and RDS restarts them automatically after 7 days, so schedule a stop again (for example with EventBridge Scheduler or Instance Scheduler on AWS).
Aurora Serverless v2 scales capacity with load and can scale to zero when idle.
Reserved DB instances discount steady databases by up to around 70% for 1- or 3-year terms.
Rightsize with Compute Optimizer or Performance Insights before reserving.
Aurora I/O-Optimized has no per-I/O charges and higher storage and instance prices; it saves money when I/O makes up more than about a quarter of the Aurora bill. Aurora Standard is cheaper for low or moderate I/O.
Graviton instance classes cost less for the same performance.
Read replicas cost the same as instances: a cache may be cheaper for repeated reads.
How to choose
“Traffic is unpredictable with sudden short spikes”: DynamoDB on-demand.
“Steady, predictable traffic all day”: DynamoDB provisioned with auto scaling (and reserved capacity).
“Test databases only used 9 to 5 on weekdays”: scheduled stop and start.
“Production database running 24/7 for years”: Reserved DB instances.
Common traps
Assuming a stopped RDS instance stays stopped. It restarts after 7 days.
Provisioned capacity for spiky traffic. Auto scaling reacts in minutes and can throttle short spikes; on-demand absorbs them.
Deleting and re-creating databases each day to save money when stopping them is simpler.
A ticketing start-up is launching a new app backed by an Amazon DynamoDB table.
For most of the day the table receives a few requests a second, but when tickets for a popular event go on sale, writes jump within seconds to about 2,000 a second for 2 to 3 minutes. The team cannot predict when sales will open or how large they will be.
Requests must not be throttled, and nobody wants to manage capacity.
Which configuration is MOST cost-effective?
Choose one answer.
AA. Use provisioned capacity with DynamoDB auto scaling at a 70% target utilization, starting from the quiet-period baseline.
BB. Use provisioned capacity sized for 2,000 writes a second, and buy DynamoDB reserved capacity for that amount.
CC. Use on-demand capacity mode, so that the table is billed per request and scales with the traffic.
DD. Use provisioned capacity sized for the quiet periods, and put a DynamoDB Accelerator (DAX) cluster in front of the table.
B. Wrong: Reserved capacity discounts provisioned capacity that is used steadily, but the company would pay for 2,000 writes a second all day while using a tiny fraction of it. The peak is also only a guess, so a bigger sale could still be throttled. Learn more: DynamoDB reserved capacity (opens in a new tab)
C. Right: Correct. On-demand mode charges per read and write request and needs no capacity planning. A new on-demand table can sustain up to 4,000 writes a second, and the mode instantly handles up to double the previous peak, so the sudden 2,000-write spikes are absorbed while quiet hours cost very little. Learn more: DynamoDB on-demand capacity mode (opens in a new tab)
D. Wrong: DAX caches reads, but it is a write-through cache: every write is passed to DynamoDB, and if DynamoDB throttles the write, the error goes back to the caller. The write spike would still hit the table's small provisioned capacity and be throttled. Learn more: DAX and DynamoDB consistency models (opens in a new tab)
Explanation
Sudden, short, unpredictable spikes on a mostly quiet table are what on-demand capacity mode is for. It is billed per request, needs no capacity planning, and a new table can sustain up to 4,000 writes a second. Auto scaling reacts in minutes, not seconds; provisioning or reserving for the peak pays for idle capacity; and DAX does not reduce write load.
A software company runs 10 Amazon RDS for SQL Server Single-AZ DB instances for its development teams.
Developers use them only from 08:00 to 18:00 on weekdays, which is 50 of the 168 hours in a week. The project ends in 6 months. The databases and their endpoints must be kept until then, and the team wants as little ongoing effort as possible.
Which solution is the MOST cost-effective?
Choose one answer.
AA. Buy 1-year Reserved Instances for all 10 DB instances, and leave the instances running throughout the week.
BB. Create Amazon EventBridge Scheduler schedules that stop the DB instances at 18:00 and start them at 08:00 on weekdays.
CC. Migrate the databases to Aurora Serverless v2 with a minimum capacity of 0 ACUs, so that each one pauses when idle.
DD. Use an AWS Lambda function to snapshot and delete the instances each evening, and to restore them from the snapshots each morning.
Show the answer and explanation
Answer: B
A. Wrong: Reserved Instances discount instances that run all the time, but these are needed for only about 30% of the week. A 1-year term also runs 6 months past the end of the project, so the company would keep paying for instances it no longer needs. Learn more: Reserved DB instances for Amazon RDS (opens in a new tab)
B. Right: Correct. A stopped RDS instance is not charged for instance hours (storage and backups are still charged), keeps its endpoint, and RDS for SQL Server supports stopping Single-AZ instances. Schedules cut about 70% of instance hours with no long-term commitment, and the weekday start means the 7-day automatic restart never comes into play. Learn more: Stopping an Amazon RDS DB instance temporarily (opens in a new tab)
C. Wrong: Aurora Serverless v2 can scale to 0 ACUs and pause when there are no connections, so it is not billed for capacity while idle. However, Aurora is compatible only with MySQL and PostgreSQL, so SQL Server databases cannot move to it without a full engine migration. Learn more: Scaling to zero ACUs with automatic pause and resume (opens in a new tab)
D. Wrong: This removes instance charges overnight, but deleting and restoring creates new instances each day, which breaks the requirement to keep the databases and endpoints. Restores also take time every morning and add moving parts to maintain. Stopping and starting the instances gives the saving more simply.
Explanation
The instances are needed for 50 of 168 hours a week, so the biggest saving is to stop paying for the other 118. Stopped RDS instances are not billed for instance hours, keep their endpoints, and are restarted automatically only after 7 days, which a weekday schedule never reaches. The 6-month horizon rules out a 1-year reservation, and the SQL Server engine rules out Aurora Serverless v2.
Want more on Database cost optimization? The 5 full-length practice sets have 10 more Database cost optimization questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →