Exam AWS Certified Solutions Architect - Professional topic 1 question 496 discussion

I would go with "B". A: would be preferred if no replicas!, because four replicas will make it costly solution. B: TTL with DynamoDB will solve the database size cost. make it cost effective. C: is not good solution. D: Kinesis can store date unto 7 days.

A A: Although Aurora is more expensive, it does improve the reliability. B\C: DynamoDB is a NOSQL so I don’t think it’s suitable for this case.

Best Answer: B. Use Amazon DynamoDB with the source ID as the partition key and the timestamp as the sort key. Use a Time to Live (TTL) to delete data after 30 days. Why this is optimal: DynamoDB supports massive scale with predictable performance and read-heavy workloads. The schema with source ID as partition key and timestamp as sort key enables efficient querying of one source over time (ideal for "30-day average" lookups). TTL (Time to Live) automatically deletes old records, reducing storage cost and management overhead. DynamoDB is serverless, highly available, and resilient by design.

This is a typical use case (IOT). If we consider massive amounts of data, DynamoDB is the winner. In our case, we need a quick read/write data transaction system that DynamoDb can handle (Optimized for read/write). There is no mention of staying with an SQL database and converting to NoSQL is feasible. the suggested Aurora answer doesn't handle the fact that after 30 days, data can be discarded. So after a couple of months, the database will keep growing and incurring more and more costs! Which would be too expensive. I found a nice article comparing both dbs: https://dynobase.dev/dynamodb-vs-aurora/

A is the correct answer although DynamoDB could work it implies rewriting the application and can bring more time and expense which is not the context of the question. Then A more seems

A is the correct answer I don't think DynamoDB will be cheaper in this case... just tried to calculate the cost of DynamoDB for such HUGE data 10mx30days = 300m write records per month and 600m read records per month (twice) storage will be about 30tb> so price will be $4k> Aurora will be cheaper for sure!! even with additional 4RR

A: looks possible and real live I would rather take that approach as in reality different Database means rewriting software .... but this reality is out of scope of this question and Aurora is pricy B: question explicitely says "Queries to the collected data are for one source ID at a time.". Yes we have no relations, we do not need a relational database and so we can go with dynamo db. Setting the TTL gives us the required retention. This is way cheaper than aurora. C) Again DynamoDB. It does not mention the TTL. D) Kinesis might be posible but whats the cache for. Odd. A reality sidemark: once an average over a day(daily average) generated it doesn't have to recalculated as it doesn't change. Even if you want average over 30 days you only need at most the total *or* avarage of aday and the number of items so processing so many records over and over again ... if I'd rewrite that to a rolling update would be cost effective. For the exam I would go with B

B. Use Amazon DynamoDB with the source ID as the partition key and the timestamp as the sort key. Use a Time to Live (TTL) to delete data after 30 days.

A is the answer. Dynamo DB is for NO SQL.

I would go with "A": - Aurora supports MySQL so there is no need for architecture change - MySQL have aggregation functions where DynamoDB does not (only client-side, so we have to scan few TB and fetch them - that would be a massive cost) https://stackoverflow.com/questions/26298829/does-dynamodb-support-aggregate-functions-like-avg-max-min - Storing TBs of data would be cheaper in Aurora than in DynamoDB

So many answers for B with no justification for switching from SQL to NO-Sql?? Its a simple problem, already running MySql, so to improve the system add Read Replicas, because more reads than writes. No mention of having to delete data as a requirement, so unless someone can tell me why, my answer will have to be A.

B. Use Amazon DynamoDB with the source ID as the partition key and the timestamp as the sort key. Use a Time to Live (TTL) to delete data after 30 days.

I will pick B

10 million records * 100,000 sources * 100 bytes (assuming each record of 100 bytes) = (10000000*100000*100)/(1024*1024*1024*1024) = 90.9 TB of data each day! Max size supported by Aurora MySQL is 128TB. It can not take 30 days of data in one Aurora instance!

10 million records * 100,000 sources * 100 bytes (assuming each record of 100 bytes) = (10000000*100000*100)/(1024*1024*1024*1024) = 90.9 TB of data each day! Max size supported by Aurora MySQL is 128TB. It can not take 30 days of data in one Aurora instance!

"reliability and cost effectiveness" In my opinion - don't mix up cost with the daily average. Cost is related to the total cost of running such queries and the cost of supporting infrastructure. B wrong - having one table to serve 300 million (and more) records will have a lot of constraints not to mention only one configuration of RCU/WCU that must support writing and reports C correct - as mentioned by other people

I'll go for B