Soru

Zorluk: OrtaOptimizing Compute and Storage Performance

An enterprise digital media platform runs its content management system (CMS) on AWS. The application tier runs on a fleet of Amazon EC2 `t3.large` instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database tier uses an Amazon RDS for PostgreSQL DB instance. The CMS files and media assets are stored on an Amazon Elastic File System (Amazon EFS) file system configured with General Purpose performance mode and Bursting throughput mode.

During high-profile news release campaigns, users experience high latency and occasional timeouts. A review of Amazon CloudWatch metrics during these campaigns shows:
- The EC2 instances reach 100%100\% CPU utilization, and the `CPUCreditBalance` drops to 00.
- The EFS `BurstCreditBalance` drops to 00, and EFS throughput is throttled to approximately 2.5 MiB/s2.5\text{ MiB/s} due to the small size of the media storage (50 GiB50\text{ GiB}).
- The RDS DB instance shows high read latency, but CPU utilization is normal.

Which two actions should a Solutions Architect take to resolve these bottlenecks and optimize the performance of the compute and storage tiers?

  1. Modify the Auto Scaling group launch template to use a non-burstable instance type, such as `c6i.large`, to ensure consistent compute performance.Cevap
  2. B
    Configure the Application Load Balancer to route read-heavy database traffic to the standby DB instance of the Amazon RDS for PostgreSQL Multi-AZ deployment.
  3. Configure the Amazon EFS file system throughput mode to Elastic throughput to automatically scale throughput capacity based on workload activity.Cevap
  4. D
    Request AWS Support to pre-warm the Application Load Balancer, which will automatically increase the CPU credit capacity of the backend EC2 instances to handle the traffic spike.

Cevap

Modify the Auto Scaling group launch template to use a non-burstable instance type, such as `c6i.large`, and configure the Amazon EFS file system throughput mode to Elastic throughput.
Transitioning the EC2 instances to a non-burstable instance type (like `c6i.large`) resolves the compute bottleneck by removing the dependency on CPU credits. Setting the EFS throughput mode to Elastic throughput resolves the storage bottleneck by allowing the file system to dynamically deliver the necessary IOPS and throughput regardless of the small 50 GiB50\text{ GiB} storage size.

Adım Adım Çözüm

1
Analyze the compute tier performance metrics.
The CloudWatch metrics show 100%100\% CPU utilization and `CPUCreditBalance` dropping to 00 on the EC2 instances.
This indicates that the `t3.large` burstable instances have exhausted their CPU credits and are being throttled to their baseline performance, which causes latency. Moving to a non-burstable instance type like `c6i.large` guarantees consistent CPU performance.
2
Analyze the storage tier performance metrics.
The EFS `BurstCreditBalance` drops to 00 and throughput is restricted to 2.5 MiB/s2.5\text{ MiB/s} on a 50 GiB50\text{ GiB} file system.
In Bursting throughput mode, EFS baseline throughput scales linearly with the storage volume size (50 KiB/s50\text{ KiB/s} per GiB). With only 50 GiB50\text{ GiB} stored, the baseline is 2.5 MiB/s2.5\text{ MiB/s}. Switching to Elastic throughput allows the file system to scale up to dynamic throughput rates based on read/write load rather than stored volume size.
3
Evaluate the database and load balancer options.
RDS standby instances cannot accept read connections, and ALB pre-warming does not affect backend EC2 CPU credit metrics.
Eliminating invalid configurations ensures that read scaling is not attempted on passive RDS standby nodes and that the root cause of backend CPU throttling is directly addressed via compute adjustments.

Anahtar Kavram

Identifying CPU credit exhaustion in burstable EC2 instances and EFS throughput limitations on small datasets, and resolving them by transitioning to non-burstable compute instances and Elastic throughput mode.
Bu soruyu puanla