Question

Difficulty: HardCost-Optimized Compute Selection and Purchasing Strategies

A financial services company operates a risk analysis application on AWS. The application architecture consists of three main tiers:

* Web/API Tier: Containerized APIs running on Amazon ECS with AWS Fargate. The APIs run 24/7 with a steady-state baseline of 10 vCPU10\text{ vCPU} and 20 GB20\text{ GB} RAM, but dynamically scale up to 50 vCPU50\text{ vCPU} and 100 GB100\text{ GB} RAM during peak business hours.
* Batch Processing Tier: A nightly data reconciliation job running on Amazon EC2. The job runs for 33 hours daily, is highly fault-tolerant, and can easily resume from checkpoints if interrupted.
* Database Tier: A steady-state Amazon RDS for PostgreSQL instance running 24/7.

The company wants to optimize its AWS compute and database costs over a 11-year period. Which combination of purchasing options will provide the most cost-effective solution while meeting the application's operational requirements?

  1. Purchase a 11-year Compute Savings Plan to cover the baseline Fargate tasks, use Fargate On-Demand for the peak scaling container tasks, run the reconciliation job on EC2 Spot Instances, and purchase a 11-year RDS Reserved Instance.Answer
  2. B
    Purchase a 11-year Compute Savings Plan to cover the baseline Fargate tasks, the daily EC2 reconciliation job, and the Amazon RDS for PostgreSQL instance, while using Fargate Spot for peak scaling.
  3. C
    Purchase a 11-year Compute Savings Plan to cover the baseline Fargate tasks, run the nightly reconciliation job on AWS Lambda functions, and purchase a 11-year RDS Reserved Instance for the database.
  4. D
    Purchase a 11-year EC2 Instance Savings Plan to cover the baseline Fargate tasks, run the reconciliation job on EC2 Spot Instances, and purchase a 11-year RDS Reserved Instance for the database.

Answer

Purchase a 11-year Compute Savings Plan to cover the baseline Fargate tasks, use Fargate On-Demand for the peak scaling container tasks, run the reconciliation job on EC2 Spot Instances, and purchase a 11-year RDS Reserved Instance.
The correct option correctly combines a 11-year Compute Savings Plan to cover the Fargate baseline, Fargate On-Demand for the user-facing API scaling tasks to ensure availability, EC2 Spot Instances for the fault-tolerant nightly batch job to achieve up to 90% cost savings, and a 11-year RDS Reserved Instance for the steady-state database.

Step-by-Step Solution

1
Analyze the workload requirements of each tier to determine the baseline versus variable demands.
The Web/API tier has a steady 24/7 baseline (10 vCPU10\text{ vCPU}/20 GB20\text{ GB} RAM) and variable scaling (50 vCPU50\text{ vCPU}/100 GB100\text{ GB} RAM). The database is steady-state 24/7. The batch job is temporary (33 hours) but fault-tolerant.
Correctly categorizing workloads is necessary to match them with the right pricing model.
2
Select the appropriate savings vehicle for steady-state workloads.
Choose a Compute Savings Plan for the ECS Fargate baseline, and an RDS Reserved Instance (RI) for the steady-state PostgreSQL database.
Compute Savings Plans offer up to 66% savings on EC2, Fargate, and Lambda. RDS RIs offer up to 69% savings on steady-state databases, whereas Compute Savings Plans do not cover RDS.
3
Determine the purchasing model for the temporary and fault-tolerant batch reconciliation job.
Select EC2 Spot Instances for the 33-hour nightly batch job.
Spot Instances offer up to 90% savings over On-Demand and are ideal for workloads that can tolerate interruption, such as checkpoints-enabled batch processing.
4
Select the purchasing model for the scaling portion of the Web/API tier.
Use Fargate On-Demand for the peak scaling tasks.
Since the Web/API tier is user-facing, using Fargate Spot for scaling could result in container termination and degrade user experience. Fargate On-Demand ensures high availability for the spiky web traffic.

Key Concept

Selecting cost-optimized compute purchasing strategies requires matching the availability, execution duration, and service type of each workload component with the correct AWS savings model (Compute Savings Plans vs. Instance Savings Plans vs. Reserved Instances vs. Spot Instances).
Rate this question