A financial services firm runs a real-time risk analysis engine on Amazon EC2 instances in… — AWS Certified Solutions Architect - Professional

A financial services firm runs a real-time risk analysis engine on Amazon EC2 instances in an Auto Scaling group. The instances process large market feeds retrieved from an Amazon S3 bucket, write large temporary datasets to attached $1\text{ TB}$ EBS `gp3` volumes, and query metadata from an Amazon Aurora PostgreSQL database.

During market open hours, the following performance bottlenecks are observed:
* The EC2 instances experience high I/O wait times; the EBS volumes are operating at the baseline performance of $3{}000\text{ IOPS}$ and $125\text{ MB/s}$ throughput.
* The application receives HTTP $503$ (Slow Down) errors from Amazon S3 due to a high volume of concurrent GET requests directed at a single date-based folder structure (e.g., `s3://bucket/year=2026/month=07/day=16/`).
* Read queries to the Aurora database experience high latency due to transient read spikes, and the application requires read-scaling without impacting write performance.

Which combination of actions will optimize compute and storage performance while resolving these bottlenecks? (Select TWO.)

Modify the configurations of the existing EBS `gp3` volumes to increase the provisioned throughput and IOPS to meet the peak write demands, and implement a prefix partitioning strategy for the S3 bucket keys by prepending a hash value to the object paths.Answer
Configure Amazon Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas based on CPU utilization, and configure the application to route read queries to the cluster's reader endpoint.Answer
C
Request AWS Support to pre-warm the Application Load Balancer (ALB) servicing the EC2 instances to handle the burst in traffic and resolve the S3 HTTP $503$ (Slow Down) errors.
D
Enable Multi-AZ standby deployment for the Aurora PostgreSQL cluster and configure the application's read traffic to target the standby instance endpoint to distribute the query load.
E
Decrease the Auto Scaling group scale-out cooldown period to $10\text{ seconds}$ to quickly spin up new EC2 instances to handle the concurrent S3 request spikes.

Answer

Modify the EBS gp3 volume configurations to provision higher IOPS and throughput, implement S3 prefix partitioning by prepending a hash to key paths, configure Amazon Aurora Auto Scaling to dynamically provision Aurora Replicas, and route read queries to the cluster's reader endpoint.

Modifying the gp3 volume configurations to provision higher IOPS and throughput resolves the EBS performance bottleneck immediately. Prepending a hash value to S3 object keys creates distinct logical prefixes, which dynamically scales S3 throughput limits and eliminates HTTP 503 errors. In addition, implementing Aurora Auto Scaling for replicas combined with the reader endpoint scales out read throughput dynamically based on workload demands.

Step-by-Step Solution

Analyze the EBS gp3 storage constraint.

Identify that the volumes are hitting the baseline limits (

3{}000\text{ IOPS}

and

125\text{ MB/s}

throughput) despite having

1\text{ TB}

of storage capacity.

By default, gp3 volumes offer these baseline parameters; performance can be scaled up to

16{}000\text{ IOPS}

and

1{}000\text{ MB/s}

independently of volume size by adjusting the provisioned throughput and IOPS settings.

Address S3 HTTP 503 (Slow Down) errors.

Implement a hash-based prefix partitioning scheme for object keys.

Amazon S3 supports

5{}500\text{ GET}

requests per second per prefix. Prepending a hash distributes the data across multiple prefixes, allowing S3 to scale throughput horizontally.

Scale the database read capacity.

Enable Aurora Auto Scaling and configure reader routing.

Aurora Replicas share cluster storage and can serve read traffic. Dynamic scaling based on CPU utilization combined with the reader endpoint handles read spikes transparently.

Eliminate inappropriate architectural responses.

Rule out ALB pre-warming, Multi-AZ standby routing, and aggressive cooldown modifications.

ALB pre-warming does not affect S3; standby DB instances cannot process query workloads; a 10-second cooldown causes cluster instability.

Key Concept

Identifying and scaling compute, storage, and database bottlenecks across S3, EBS, and Aurora PostgreSQL.

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics