Question

Difficulty: MediumCost-Optimized Database Design and Capacity Planning

A company is hosting a fleet tracking application on AWS. The application consists of two main database workloads:

* An IoT sensor data ingestion workload that writes to an Amazon DynamoDB table. The traffic is highly unpredictable and spiky, with peak data rates reaching up to 10 times10\text{ times} the baseline activity, and dropping to near zero during off-peak hours.
* A weekly analytics reporting workload that queries an Amazon RDS for MySQL DB instance. The database experiences heavy read traffic during a 4-hour4\text{-hour} window once a week. The reports are non-critical, and the business has stated that high availability and automated failover are not required. The DB instance is currently configured with Multi-AZ enabled and uses provisioned IOPS (io2io2) storage to handle the weekly peak.

Which TWO options should the solutions architect implement to design a cost-optimal database architecture? (Select TWO.)

  1. Configure the DynamoDB table to use On-Demand capacity mode.Answer
  2. Modify the RDS DB instance to a Single-AZ deployment and change the storage type from io2io2 to gp3gp3.Answer
  3. C
    Configure the DynamoDB table using Provisioned Capacity mode and set the provisioning limits to the peak traffic volume to avoid database write failures.
  4. D
    Keep the RDS DB instance in a Multi-AZ deployment and purchase Compute Savings Plans to lower the hourly compute and storage costs of the DB instance.
  5. E
    Deploy the RDS DB instance with Multi-AZ enabled and configure an RDS Read Replica to serve as the automatic failover target to handle both high availability and reporting performance.

Answer

The correct configurations are to configure the DynamoDB table to use On-Demand capacity mode, and to modify the RDS DB instance to a Single-AZ deployment while changing the storage type from io2 to gp3.
Configuring DynamoDB to use On-Demand capacity mode automatically handles the spiky, unpredictable IoT data ingestion workload without the need to pay for idle capacity. For the MySQL database, since high availability is not a requirement, moving from a Multi-AZ deployment to a Single-AZ deployment reduces compute costs by eliminating the standby instance. Additionally, changing the storage type from provisioned IOPS (io2) to general purpose SSD (gp3) provides a cost-effective performance tier where throughput and IOPS can be scaled independently without paying io2 rates.

Step-by-Step Solution

1
Analyze the DynamoDB workload behavior
The workload is highly spiky and unpredictable, with near-zero traffic off-peak. On-Demand capacity mode is optimal as it charges only for the read and write requests executed, preventing cost overhead from idle provisioned capacity.
Choosing the appropriate DynamoDB capacity mode is critical to optimizing costs for spiky, irregular traffic.
2
Evaluate high availability requirements for the RDS instance
The reporting system is non-critical and doesn't require high availability. Disabling Multi-AZ (Single-AZ) reduces the instance cost significantly by removing the redundant standby instance.
Multi-AZ doubles DB instance costs and should be avoided if high availability is not required.
3
Analyze storage performance options for the RDS instance
The database uses io2 storage. Changing to gp3 storage allows provisioning the required baseline performance and scaling throughput/IOPS independently without paying the premium costs associated with io2.
gp3 storage provides a much more cost-effective alternative to io2 for general workloads.

Key Concept

Selecting the most cost-effective database deployment options, scaling strategies, and storage tiers based on workload requirements and SLA constraints.
Rate this question