Question

Difficulty: HardOptimizing Compute and Storage Performance

An enterprise financial analytics company runs daily risk simulation models on AWS. The simulation runs on a fleet of Amazon EC2 `c5.4xlarge` instances in an Auto Scaling group. The simulations read a massive set of historical market data (around 2 TB2\text{ TB}) from an Amazon S3 bucket at the start of each run and write massive temporary scratch files (up to 500 GB500\text{ GB} per instance) during execution.

Currently, the EC2 instances are configured with a single 1 TB1\text{ TB} General Purpose SSD (gp3) EBS volume for both the operating system and scratch space. During the run, the company observes that scratch writes hit I/O limits, causing CPU utilization to drop while waiting for I/O. Additionally, the initial download of the 2 TB2\text{ TB} historical market data from S3 takes over 30 minutes30\text{ minutes}, delaying the start of the simulation.

Which two modifications should the Solutions Architect implement to optimize the compute and storage performance for this workload? (Select two.)

  1. Change the instance type of the simulation fleet to `c5d.4xlarge` to utilize the local NVMe-based instance store volumes, and configure the simulation software to use this instance store for writing temporary scratch files.Answer
  2. Configure the simulation application to download the historical market data from Amazon S3 using parallel byte-range requests across multiple threads to saturate the instance's network interface.Answer
  3. C
    Request AWS Support to pre-warm the Application Load Balancer (ALB) that routes traffic to the simulation fleet to prevent connection dropping during the initial data download from Amazon S3.
  4. D
    Migrate the historical market data from Amazon S3 to an Amazon Aurora PostgreSQL database, and route read queries to the Multi-AZ standby instance to scale the data retrieval capacity.
  5. E
    Decrease the Auto Scaling group scale-out cooldown period to 15 seconds15\text{ seconds} to allow the fleet to rapidly add new instances when the initial S3 download causes a spike in CPU usage.

Answer

To optimize performance, change the EC2 instance type to `c5d.4xlarge` to utilize the local NVMe instance store for temporary scratch space, and configure the application to download historical market data from Amazon S3 using parallel byte-range requests.
Utilizing local NVMe instance stores (via `c5d` instances) provides high-performance, low-latency disk access for temporary scratch files, resolving the EBS I/O bottleneck. Downloading from S3 using parallel byte-range requests allows the application to utilize the full network bandwidth of the instance, resolving the S3 transfer delay.

Step-by-Step Solution

1
Analyze the scratch space performance bottleneck.
The simulation writes up to 500 GB500\text{ GB} of temporary data per instance and is hitting I/O limits on EBS gp3. Because these scratch files are temporary and do not need to persist beyond the simulation run, local NVMe-based instance store volumes on `c5d` instances are the most performant and cost-effective solution.
This offloads I/O from network-attached EBS volumes to local bus-attached NVMe storage, achieving lower latency and avoiding costs associated with provisioning extra EBS IOPS/throughput.
2
Analyze the S3 download throughput bottleneck.
Downloading 2 TB2\text{ TB} of historical market data sequentially limits network throughput. The S3 throughput can be scaled by requesting parallel byte-range requests concurrently across multiple threads, allowing the instance to saturate its network bandwidth.
S3 scales performance by prefix and by horizontal request concurrency. Parallel range requests enable the application to download multiple chunks of the file at the same time, maximizing utilization of the 10 Gbps network capacity of the instance.
3
Evaluate and eliminate incorrect architectural options.
Pre-warming the ALB is rejected because ALB is for inbound client traffic, not outbound S3 connections. Using an Aurora Multi-AZ standby for queries is rejected because standby nodes do not serve read traffic. Shortening the ASG cooldown period is rejected because it leads to ASG thrashing.
Eliminating invalid configurations ensures the system does not introduce unnecessary cost, deployment thrashing, or architectural patterns that violate AWS service limits.

Key Concept

Optimizing compute and storage performance by utilizing local NVMe instance stores for high-performance scratch space and parallel range requests to maximize Amazon S3 read throughput.
Rate this question