A financial services company loaded millions of historical stock trades into an Amazon DynamoDB table. The table uses on-demand capacity mode. Once each day at midnight, a few million new records are loaded into the table. Application read activity against the table happens in bursts throughout the day, and a limited set of keys are repeatedly looked up. The company needs to reduce costs associated with DynamoDB.
Which strategy should a solutions architect recommend to meet this requirement?
To reduce costs associated with DynamoDB while handling bursts of read activity and limited sets of frequently accessed keys, the best strategy involves utilizing DynamoDB Accelerator (DAX) as a caching solution to enhance performance and reduce the number of direct read operations on DynamoDB. Switching to provisioned capacity mode and configuring DynamoDB auto scaling also helps accommodate the predictable read and write patterns, especially with the daily batch load at midnight. These combined approaches ensure cost-efficiency and optimal performance by aligning the capacity with actual usage patterns without relying on on-demand capacity mode, which can be more expensive.
not able to find out dynamo on savings plans description https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
there is no savings plans for dynamodb nor rds. must be D.
DAX + provisioned capacity + auto scaling --savings plans are for EC2 and do not contribute to DynamoDB Provisioned mode is a good option if any of the following are true: You have predictable application traffic. You run applications whose traffic is consistent or ramps gradually. You can forecast capacity requirements to control costs. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.ProvisionedThroughput.Manual
B - in my opinion
A for me on this one. if you use elasticache in front of the dynamodb then frequently accessed data will benefit from caching.
Changing to D - https://aws.amazon.com/dynamodb/dax/
Less Dynamo DB requests = Less provisioned throughput capacity =Cost Savings, hence A
A- Incorrect can't use ElastiCache in DynamodDB. B- Correct as DAX equivalent to Elasticache for DynamoDB and read is in burst
B is INCORRECT since Saving Plans does NOT support DynamoDB The way to save cost on DynamoDB is Reserve Capacity.
C - Wouldn't solve the "and a limited set of keys are repeatedly looked up" which DAX will help with.
DAX better than Elastic
I'll go with D There is no saving plans to DynamoDB, you have Provisioned capacity mode. https://aws.amazon.com/dynamodb/pricing/?p=pm&c=database&pd=ddb&z=4
Correct D.
Deploy DynamoDB Accelerator (DAX) - burst reads on limited set of keys (caching) Use provisioned capacity mode - base read / write capacity Configure DynamoDB auto scaling - predictable record loads at midnight B: incorrect as DynamoDB supports capacity reservations but on the DynamoDB console page not from cost explorer
D, as there is no savings plans for DynamoDB