A logistics company is designing a new package tracking system on AWS. The application consists of a microservices-based API layer hosted on AWS Fargate that handles consistent, steady-state transaction volume , and a relational database layer running on Amazon RDS for PostgreSQL that operates continuously to store tracking history. Additionally, an hourly background job aggregates tracking metrics, running continuously for minutes of every hour. The company wants to minimize compute costs for this architecture while maintaining high availability and performance. Which TWO purchasing strategies or configurations should a solutions architect recommend? (Select two.)
- Purchase a Compute Savings Plan to cover the AWS Fargate API layer.Answer
- Purchase Amazon RDS Reserved Instances to cover the PostgreSQL database.Answer
- CIncrease the Compute Savings Plan commitment size to cover both the Fargate API layer and the Amazon RDS database instances.
- DMigrate the -minute hourly background job to AWS Lambda functions to eliminate idle compute costs.
- EMigrate the tracking history database to Amazon DynamoDB configured with Provisioned Capacity Mode to handle highly unpredictable, spiky query volumes.
Answer
Purchase a Compute Savings Plan to cover the AWS Fargate API layer, and purchase Amazon RDS Reserved Instances to cover the PostgreSQL database.
Purchasing a Compute Savings Plan is the most cost-effective option for the Fargate API layer because it offers discounts up to on EC2, Fargate, and Lambda for a - or -year commitment. Since Compute Savings Plans do not cover Amazon RDS, purchasing RDS Reserved Instances is the correct and separate method to optimize costs for the database layer.
Step-by-Step Solution
Key Concept
Selecting cost-optimized compute options by matching workloads to appropriate purchasing plans (Compute Savings Plans for Fargate, RDS Reserved Instances for databases) and avoiding platform limitations (Lambda timeout limits).