Examkin

Question

Difficulty: Very hardOptimizing Compute and Storage Performance

A company hosts a real-time financial transaction reconciliation application on AWS. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database tier utilizes an Amazon RDS for PostgreSQL Multi-AZ DB instance with 1 TB gp3 storage.

During scheduled end-of-day reconciliation events, the application experiences a massive, instantaneous surge in traffic. This results in HTTP 503 Service Unavailable errors from the ALB, high write latency on the database, and CPU utilization reaching 100% on the primary database instance due to concurrent read-heavy audit queries.

Which combination of actions should a Solutions Architect take to optimize the compute, database, and storage performance to handle the peak load?

  1. Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the scheduled reconciliation events. Deploy one or more Amazon RDS for PostgreSQL Read Replicas, and update the application to route read-heavy audit queries to the read replica endpoints. Increase the provisioned IOPS and throughput of the gp3 storage on the primary DB instance to meet the peak write requirements.Answer
  2. B
    Configure the Application Load Balancer to auto-scale dynamically by reducing the target group registration delay. Modify the application to route the read-heavy audit queries to the standby DB instance endpoint of the Multi-AZ deployment to distribute the CPU load. Upgrade the database storage from gp3 to gp2 to leverage burstable performance.
  3. C
    Deploy an Amazon CloudFront distribution in front of the Application Load Balancer to cache dynamic transaction traffic. Deploy an Amazon ElastiCache for Memcached cluster, configure it with multi-AZ replication, and use it to store and persist the transactional log data for audit queries. Increase the database instance size to scale the write throughput.
  4. D
    Modify the EC2 Auto Scaling group launch template to use a minimal Amazon Machine Image (AMI), and set the scaling cooldown period to 15 seconds to allow the compute tier to scale out rapidly during the spike. Deploy one or more Amazon RDS for PostgreSQL Read Replicas to offload audit queries. Migrate the primary database storage to an io2 volume with 64,000 provisioned IOPS to resolve write latency.

Answer

Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the scheduled reconciliation events. Deploy one or more Amazon RDS for PostgreSQL Read Replicas, and update the application to route read-heavy audit queries to the read replica endpoints. Increase the provisioned IOPS and throughput of the gp3 storage on the primary DB instance to meet the peak write requirements.
The correct solution resolves the Application Load Balancer capacity issues by proactively requesting pre-warming for scheduled events, offloads database reads to dedicated RDS Read Replicas (since standby instances in standard Multi-AZ deployments cannot accept connections), and increases gp3 provisioned IOPS and throughput to resolve write latency issues at the storage layer.

Step-by-Step Solution

1
Address load balancer bottleneck for scheduled flash traffic.
Request AWS Support to pre-warm the Application Load Balancer.
Since the traffic spike is instantaneous and scheduled, standard reactive scaling of the ALB is too slow and will cause dropped requests (HTTP 503 errors).
2
Address primary database CPU saturation caused by read operations.
Deploy Amazon RDS PostgreSQL Read Replicas and route read-heavy audit queries to their endpoints.
Standard Multi-AZ standby instances cannot serve read connections. Read replicas offload query workloads from the primary DB instance, freeing up resources for transaction writes.
3
Optimize storage performance on the primary database.
Increase provisioned IOPS and throughput for the existing gp3 storage volumes.
gp3 volumes allow independent scaling of performance characteristics (IOPS and throughput) up to 16,000 IOPS and 1,000 MB/s, mitigating write latency bottlenecks without requiring dynamic storage tier migrations.

Key Concept

Performance optimization across compute, database, and storage layers under high transactional load and flash traffic.
Rate this question

Topics

Optimizing Compute and Storage Performance