Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 41 discussion

A is correct. On demand mode is for unknown load pattern, auto scaling is for know burst pattern

A on-demand prices can be 7 times higher, given the options it is better to have reserved WCU and RCU and auto scale in the given schedule

B is the right answer. Reserved RCU/WCU locks you into fixed cost. Even though on demand is more expensive, the additional cost is paid only for 4 hrs a week.

A. Use AWS Application Auto Scaling to increase capacity during the peak period. Purchase reserved RCUs and WCUs to match the average load.

I think B is correct. because reserved is not required, ondemand would be better because it requireds only 4 hours per week. so B would be better. Autoscaling of the application can not impact dynamo db tables.

Tôi chọn A

Auto-scaling is for known traffic pattern, On-demand is for unknown traffic patter and also could be more expensive

AWS documentation suggests A is correct: https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html

A is correct. The focus is minimizing the cost of tables.

Considering the application's need to handle a peak load that is double the average and the fact that the workload is write-heavy, option B (Configure on-demand capacity mode for the table) is the most suitable solution. It directly addresses the variability in workload without requiring upfront capacity planning or additional management overhead, thus likely providing the best cost optimization for this scenario. On-demand capacity mode eliminates the need to scale resources manually or through Auto Scaling and ensures that you only pay for the write and read throughput you consume.

A is badly worded however, because it says "application" autoscaling. We are not talking about that here. Either it should be reworded as "DynamoDB autoscaling" for the answer to be correct. On-demand capacity mode is for unknown read/write patterns. Since the load change patterns are known, anything that involves on-demand capacity modes can be eliminated (hence not B). DAX is a caching service deployed in front of DynamoDB. It is geared towards "performance at scale". Problem in the use case, is to optimize table costs. Using DAX will incur additional costs. Hence anything that involves DAX (C and D) can also be eliminated.

https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/#:~:text=You%20can%20approximate%20a%20blend,save%20money%20as%20reserved%20capacity

Option B is the most cost-effective solution for workloads with significant fluctuations and unpredictable access patterns. The on-demand capacity mode automatically adjusts the table’s throughput capacity as needed in response to actual traffic, eliminating the need to manually configure or manage capacity. This mode is ideal for applications with irregular traffic patterns, such as a significant peak once a week, because you only pay for the read and write requests your application performs, without having to provision throughput in advance. Option B directly addresses the requirement to minimize costs associated with fluctuating loads, especially when the load significantly exceeds the average only during a brief period, by leveraging DynamoDB’s on-demand capacity mode to automatically scale and pay only for what is used.

I think there is mistake in answer A, and it should be DynamoDb auto scaling instead of application autos calling. Or application and dynamoDB auto scaling.

I choose option D, because DAX is not only an accelerator for the Reads, it also cache releasing a lot of load from the DB.

A -> You can scale DynamoDB tables and global secondary indexes using target tracking scaling policies and scheduled scaling. In this I would go for scheduled scaling. https://docs.aws.amazon.com/autoscaling/application/userguide/services-that-can-integrate-dynamodb.html B -> on-demand capacity mode is for unknown workload, this is not the case C -> DAX come with costs and it helps with reads, while here we have a more write-bound workload D -> See B and C comments

we use scheduled scaling here