Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 670 discussion

With provisioned capacity mode, you specify the number of reads and writes per second that you expect your application to require, and you are billed based on that. Furthermore if you can forecast your capacity requirements you can also reserve a portion of DynamoDB provisioned capacity and optimize your costs even further. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/capacity.html

DynamoDB On-Demand pricing is about 6.94x the cost of provisioned capacity. If your applications have predictable traffic patterns and you don't mind spending the time to understand those patterns, using DynamoDB's provisioned throughput capacity can save you money. Also can't set any capacity units for on-demand mode, so A is false in it's premise. https://www.serverless.com/blog/dynamodb-on-demand-serverless

A: is most cost effective (which is a question/requirement ) - 4h per week for Tests purpose

CD are expensive as reserved capacity even with discounts would spend most time in idle mode (over paid, under utilized) A: On demand is good if you have unpredictable usage, https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.OnDemand B: Provisioned is good if you the usage: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html "The company knows how many read and write operations the application performs to the table each second during the tests." so ideally they can set this as max

I initially thought it would be A, but when they mentioned "Update the read and write capacity units appropriately." which are automatically set in "on-demand" switched to B

Provisoned Mode shoud be the answer seeing that the workloads are predictable and DynamoDB isnt used for any other thing.

On-demand mode Option A: On-demand mode is suitable for workloads that are unpredictable or that do not have significant or consistent database traffic. It automatically scales to accommodate workload demands and charges for the read and write throughput that the application consumes. For infrequent testing, this could be cost-effective because you only pay for what you use during the testing period and don't incur costs when the table is not being accessed. Whereas for the Option B, if you only run tests once a week for 4 hours, you might pay for unused capacity for the rest of the week unless you manually scale down the capacity after tests are completed, which adds operational overhead.

Agree with B, on-demand mode might not scale fast enough after the DB has been idle for 164 hours. As they know exactly the number of reads and writes per second, should use provisioned mode, and set capacity to 1 RCU and 1 WCU while the DB is not in use.

Provisioned Mode (Option B): Provisioned mode allows you to specify the desired read and write capacity units. Since the workload occurs once a week for 4 hours, you can provision the read and write capacity units accordingly to handle the expected load during that time. This can be a more cost-effective option than on-demand pricing for predictable workloads.