A media company is migrating a web application to AWS. The architecture requires a fleet of Amazon ECS tasks running on AWS Fargate to handle constant, baseline user traffic. The application also uses Amazon DynamoDB to store user session data with highly unpredictable, spiky access patterns. The company wants to minimize the long-term, predictable costs of Fargate, while ensuring DynamoDB is optimized for cost. Which strategy should the company implement?
- Purchase a Compute Savings Plan for the ECS Fargate tasks, and configure Amazon DynamoDB in On-Demand capacity mode.Answer
- BPurchase a Compute Savings Plan to cover both the ECS Fargate tasks and the Amazon DynamoDB table capacity.
- CPurchase a Compute Savings Plan for the ECS Fargate tasks, and configure Amazon DynamoDB in Provisioned Capacity mode with statically provisioned read and write capacity to handle peak spikes.
- DMigrate the web application baseline traffic to AWS Lambda functions running continuously, and purchase a Compute Savings Plan to cover the Lambda invocation and duration costs.
Answer
Purchase a Compute Savings Plan for the ECS Fargate tasks, and configure Amazon DynamoDB in On-Demand capacity mode.
The correct strategy is to use a Compute Savings Plan to cover the constant, 24/7 baseline compute usage of the Amazon ECS Fargate tasks, and configure Amazon DynamoDB in On-Demand capacity mode. Compute Savings Plans provide discounts on ECS Fargate. Since DynamoDB access patterns are spiky and unpredictable, On-Demand capacity mode ensures that the company only pays for the database requests actually consumed, avoiding the high cost of over-provisioning capacity.
Step-by-Step Solution
Key Concept
Selecting cost-optimized compute purchasing strategies (Compute Savings Plans for Fargate) and matching appropriate database capacity modes (On-Demand for spiky DynamoDB workloads) to minimize AWS costs.