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?
- 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
- BIncrease 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.
- CModify 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.
- DMigrate 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.