Question

Difficulty: Very hardOptimizing Compute and Storage Performance

An IoT fleet tracking platform processes telemetry data from 500,000 devices. The ingestion layer uses an Application Load Balancer (ALB) routing traffic to an Auto Scaling group (ASG) of Amazon EC2 c6i.xlarge instances. The instances write raw telemetry payloads to 100 GB Amazon EBS gp3 volumes (configured with default 3,000 IOPS and 125 MB/s throughput) for local validation, sorting, and batching before saving the consolidated records to an Amazon Aurora PostgreSQL database. During scheduled daily synchronization events, device telemetry spikes instantly by 10x. During these periods, users experience slow API responses, and CloudWatch metrics reveal high write latency on the EC2 instances, a significant spike in HTTPCode_ELB_5XX_Count at the start of the synchronization, and increased read replica lag on Aurora Reader instances. Which combination of architectural modifications will resolve these performance bottlenecks with the lowest latency and cost?

  1. Migrate the EC2 instances to c6id.xlarge instances and configure the application to write temporary validation files to the local NVMe instance store; request AWS Support to pre-warm the ALB prior to the scheduled daily synchronization events; and implement Aurora Auto Scaling for Aurora Replicas to handle the database read load.Answer
  2. B
    Increase the EBS gp3 provisioned IOPS to 16,000 and throughput to 1,000 MB/s; configure the ASG to scale out using a step scaling policy based on target CPU utilization; and configure RDS Multi-AZ deployment to route read queries to the standby database instance.
  3. C
    Modify the EBS gp3 volumes to 300 GB to increase baseline performance; configure the ASG to scale using a target tracking policy based on the ALB RequestCountPerTarget metric; and configure Aurora Auto Scaling for the database writer instance.
  4. D
    Migrate the local storage to Amazon EFS using Provisioned Throughput mode; configure a scheduled scaling policy for the ASG to scale out 30 minutes before the daily synchronization; and add a secondary writer to the Aurora cluster using multi-master configuration.

Answer

Migrate the EC2 instances to c6id.xlarge instances and configure the application to write temporary validation files to the local NVMe instance store; request AWS Support to pre-warm the ALB prior to the scheduled daily synchronization events; and implement Aurora Auto Scaling for Aurora Replicas to handle the database read load.
The correct solution addresses the storage bottleneck by migrating the processing nodes to c6id instances that include high-performance, low-latency local NVMe instance store. This is ideal for short-term processing and validation files, eliminating the cost and bottleneck of provisioned EBS volumes. For the sudden, scheduled 10x flash traffic spike, requesting AWS to pre-warm the Application Load Balancer ensures that the load balancer has the immediate capacity to handle the connection rate without dropping packets or throwing 5XX errors. Finally, implementing Aurora Auto Scaling for the replicas dynamically increases read capacity to prevent replication lag during heavy processing.

Step-by-Step Solution

1
Address the local storage bottleneck by replacing the EBS volumes with local NVMe instance stores.
Temporary validation files are written to low-latency, high-IOPS local NVMe disks on c6id instances, eliminating EBS write latency and queue depth issues.
Since the validation, sorting, and batching files are temporary before being stored in the database, they do not require persistent EBS storage and can leverage the high performance of ephemeral instance stores.
2
Address the ALB connection drops by preparing for the flash traffic spike.
AWS Support pre-warms the ALB to have sufficient capacity to handle the 10x instant traffic increase.
Standard Auto Scaling and load balancer scaling are reactive and take time. For scheduled events with massive instantaneous traffic spikes, pre-warming is required to avoid 503 Service Unavailable errors.
3
Address database read performance bottlenecks.
Aurora Auto Scaling automatically adds Aurora Replicas to the cluster as read lag increases, scaling out query capacity.
Aurora Reader instances handle read queries, and scaling them dynamically ensures the application maintains low latency under peak read traffic.

Key Concept

Optimizing compute and storage performance requires identifying ephemeral vs. persistent data access patterns, configuring appropriate instance-attached storage (NVMe instance store vs. EBS), pre-warming network resources for flash traffic, and correctly scaling databases using read replicas rather than standby instances.

Alternative Method

Instead of pre-warming the ALB, if the client telemetry ingestion protocol can be modified, decoupling the ingestion layer by placing Amazon Kinesis Data Streams or Amazon SQS directly behind the API Gateway or ALB can buffer the incoming telemetry data, allowing the EC2 instances to process the queue at a steady rate without overloading the storage layer or database.
Estimated Time:3m 0s
Rate this question