Examkin

Question

Difficulty: HardOptimizing Resource Costs and Sizing

An enterprise manages a multi-account environment under AWS Organizations with consolidated billing enabled. The production workloads must maintain high availability across three Availability Zones with minimal administrative overhead. The current infrastructure includes the following components:

* Compute: An Auto Scaling group in Account A running 1212 Linux x86_64 Amazon EC2 `m6i.4xlarge` instances 24/7. Monitoring shows CPU utilization is consistently between 15%15\% and 20%20\%, and memory utilization is under 30%30\%. No code changes or recompilations are permitted.
* Serverless: Containerized microservices running on AWS Fargate in Account A. The tasks are allocated 44 vCPUs and 16 GB16\text{ GB} of RAM, with average CPU and memory utilization at 22%22\%.
* Database: A transactional write-heavy Amazon Aurora PostgreSQL DB cluster in Account B running on a single `db.r6g.4xlarge` instance. The database CPU utilization averages 10%10\% but spikes to 85%85\% daily for a 1-hour batch ingestion process.
* Network: Outbound traffic to the internet from private subnets in Account C is routed through a single NAT Gateway in Availability Zone `us-east-1a` to minimize processing costs.

Which two of the following recommendations should the Solutions Architect make to optimize resource costs and sizing without introducing code changes, risking service downtime, or compromising high availability? (Select TWO.)

  1. Downsize the EC2 instances to `m6i.2xlarge`, and purchase Compute Savings Plans in the organization's management account to maximize savings across both the EC2 instances and the Fargate tasks.Answer
  2. Downsize the Fargate tasks to 1 vCPU1\text{ vCPU} and 4 GB4\text{ GB} of RAM, and migrate the Aurora database to Aurora Serverless v2 configured with a capacity range of 44 to 6464 Aurora Capacity Units (ACUs).Answer
  3. C
    Downsize the EC2 instances to `c6i.2xlarge` to optimize compute efficiency, and purchase EC2 Instance Savings Plans in the organization's management account to cover the EC2 instances and Fargate tasks.
  4. D
    Share the single NAT Gateway in Account C with Account A and Account B using AWS Resource Access Manager (RAM) to eliminate cross-AZ data transfer fees.
  5. E
    Keep the Fargate tasks at their current capacity, and route all outbound traffic in Account A and Account B through the single NAT Gateway in Availability Zone `us-east-1a` to avoid the hourly charges of additional NAT Gateways.

Answer

Downsize the EC2 instances to m6i.2xlarge and purchase Compute Savings Plans in the management account; downsize the Fargate tasks to 1 vCPU and 4 GB RAM, and migrate the Aurora database to Aurora Serverless v2 with a capacity range of 4 to 64 ACUs.
Downsizing the EC2 instances to `m6i.2xlarge` reduces the provisioned resources to half, perfectly fitting the observed utilization (under 3.2 vCPUs and 19.2 GB RAM) while maintaining the x86_64 architecture without code changes. Purchasing Compute Savings Plans at the management account level allows the discount to cover both EC2 and Fargate tasks across the organization. Additionally, downsizing the Fargate tasks to 1 vCPU and 4 GB RAM aligns resources with the actual 22% utilization, and migrating the Aurora DB cluster to Aurora Serverless v2 enables dynamic scaling up to 64 ACUs during batch ingestion, eliminating provisioned idle capacity costs.

Step-by-Step Solution

1
Analyze EC2 metrics and right-size the compute instances.
Downsizing from `m6i.4xlarge` (16 vCPUs, 64 GB RAM) to `m6i.2xlarge` (8 vCPUs, 32 GB RAM) is safe since peak CPU usage is <3.2 vCPUs and memory usage is <19.2 GB. A compute-optimized instance like `c6i.2xlarge` is ruled out because its 16 GB RAM would lead to memory starvation.
Ensures that compute sizing matches actual resource requirements without risking application stability or requiring code changes.
2
Analyze Fargate metrics and right-size task allocations.
The Fargate tasks utilize 22% of 4 vCPUs (~0.88 vCPUs) and 16 GB RAM (~3.52 GB). Downsizing the task definition to 1 vCPU and 4 GB RAM optimizes utilization and significantly reduces Fargate costs.
Prevents over-provisioning of serverless compute resources.
3
Analyze database patterns and migrate to a dynamic scaling model.
The Aurora PostgreSQL database is highly underutilized for 23 hours a day (10% CPU) but spikes to 85% during ingestion. Migrating to Aurora Serverless v2 with a range of 4 to 64 ACUs (8 GB to 128 GB RAM) allows the database to scale up automatically to handle ingestion spikes and scale back down, saving substantial database provisioning costs.
Provides automated cost-effective sizing for variable and bursty database workloads.
4
Evaluate Savings Plans options for multi-account coverage.
Compute Savings Plans purchased in the management account cover both EC2 and Fargate across the organization. EC2 Instance Savings Plans are incorrect because they do not cover Fargate compute.
Applies the most flexible and comprehensive discount program across the multi-account AWS Organization.

Key Concept

Right-sizing compute (EC2 and Fargate) and database (Aurora) workloads based on performance metrics, combined with selecting the correct Savings Plans type (Compute vs. EC2 Instance) for multi-account serverless environments while maintaining high availability.
Rate this question

Topics

Optimizing Resource Costs and Sizing

More questions from this topic