A retail company is migrating its product inventory database to AWS. The database experien… — AWS Certified Solutions Architect - Associate

A retail company is migrating its product inventory database to AWS. The database experiences a steady, predictable baseline of $1,200\text{ read operations per second}$ and $200\text{ write operations per second}$ during regular hours. However, during flash sales that occur for $1\text{ hour}$ every Friday evening, read traffic spikes to $15,000\text{ operations per second}$ and write traffic spikes to $3,000\text{ operations per second}$ . The database schema is non-relational, and the company wants to optimize cost while ensuring the database does not throttle during flash sales. Which TWO configurations should the solutions architect recommend to meet these requirements cost-effectively? (Select TWO.)

Configure Amazon DynamoDB in Provisioned Capacity Mode and configure AWS Application Auto Scaling to schedule write capacity scaling before and after the flash sales.Answer
Implement Amazon ElastiCache to cache inventory read requests, reducing the required DynamoDB provisioned read capacity during both baseline and peak hours.Answer
C
Configure Amazon DynamoDB in On-Demand Capacity Mode to automatically scale up to support the read and write spikes during the flash sales.
D
Configure Amazon DynamoDB with provisioned capacity set statically to $15,000$ Read Capacity Units (RCUs) and $3,000$ Write Capacity Units (WCUs) to prevent throttling.
E
Migrate the database to Amazon RDS for PostgreSQL with a Multi-AZ deployment and route the write traffic spikes to the standby replica to distribute the load.

Answer

The correct configurations are to run DynamoDB in Provisioned Capacity Mode with scheduled scaling for write capacity and to deploy Amazon ElastiCache to cache inventory read requests.

Implementing scheduled scaling for write capacity and caching reads with Amazon ElastiCache is the most cost-effective solution. Since the flash sale occurs at a predictable time, AWS Application Auto Scaling can schedule write capacity increases to

3,000\text{ WCUs}

before the sale and scale back down to the baseline of

200\text{ WCUs}

after the sale, preventing throttling at the beginning of the sale. Caching product inventory details with Amazon ElastiCache reduces the read load on DynamoDB, allowing the database to be provisioned with a low, cost-optimized read capacity baseline instead of provisioning for the

15,000\text{ RCUs}

peak.

Step-by-Step Solution

Analyze the workload characteristics and database requirements.

The database has a non-relational schema with a steady baseline of

1,200\text{ reads/sec}

and

200\text{ writes/sec}

, and a predictable spike to

15,000\text{ reads/sec}

and

3,000\text{ writes/sec}

for

1\text{ hour}

once a week.

Identifying the workload patterns helps determine the most cost-effective database engine, capacity mode, and scaling strategy.

Evaluate the cost-effectiveness of DynamoDB capacity modes.

Provisioned Capacity Mode is cheaper for the predictable baseline. Since standard auto-scaling takes time to scale up, scheduling scaling activities before the weekly flash sale ensures write capacity is ready without throttling.

Scheduled scaling aligned with predictable events optimizes write cost while ensuring performance.

Determine the best caching strategy for the read path.

Introduce Amazon ElastiCache to cache inventory details. This offloads the

15,000\text{ reads/sec}

peak from DynamoDB, allowing the database read capacity to remain low.

Caching read-heavy workloads is much cheaper than provisioning database throughput to handle extreme read peaks.

Key Concept

Cost-optimized database capacity planning using DynamoDB scheduled scaling and ElastiCache caching layers for predictable and spike workloads.

Estimated Time:2m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics