Soru

Zorluk: ZorAuto Scaling and Elastic Load Balancing (ELB)

A company hosts a high-traffic e-commerce application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The ALB target group health check is configured to query an application endpoint `/health` on port 443, which verifies the application's connection to a backend Amazon RDS database. During a scheduled database maintenance window, the database becomes temporarily unavailable, causing the `/health` endpoint to return HTTP 500 errors. Consequently, the ALB target group marks all EC2 instances as unhealthy. Because the ASG is configured to use ELB health checks, it begins terminating all instances in the fleet and launching new ones. This results in a continuous loop of instance provisioning and termination, generating high costs and delaying recovery when the database comes back online. Which action should a Solutions Architect take to resolve this issue and prevent the unnecessary termination of EC2 instances during database outages?

  1. A
    Modify the Network Access Control List (NACL) of the subnet containing the EC2 instances to stateless deny rules for outbound traffic on ephemeral ports to temporarily block the health check requests.
  2. Configure the Auto Scaling group to use EC2 health checks instead of ELB health checks, allowing the Application Load Balancer to stop routing traffic to the instances while preventing the Auto Scaling group from terminating them.Cevap
  3. C
    Change the Application Load Balancer target group health check configuration to query port 80 instead of port 443, assuming the instances will return a default healthy status on port 80.
  4. D
    Configure an Amazon Route 53 latency-based routing policy to automatically reroute the health check queries to a secondary Auto Scaling group in another AWS Region during the database outage.

Cevap

Configure the Auto Scaling group to use EC2 health checks instead of ELB health checks, allowing the Application Load Balancer to stop routing traffic to the instances while preventing the Auto Scaling group from terminating them.
Configuring the Auto Scaling group to use EC2 health checks instead of ELB health checks ensures that the Auto Scaling group only terminates instances if they fail EC2 status checks (hardware or hypervisor issues). The Application Load Balancer will still mark the instances as unhealthy and stop routing traffic to them when the database is unavailable, but the instances will not be terminated. Once the database becomes available again, the load balancer health checks will pass, and traffic will resume seamlessly.

Adım Adım Çözüm

1
Analyze the cause of the instance termination loop.
The Auto Scaling group is set to use ELB health checks, meaning any target group health check failure triggers instance termination and replacement.
To identify why the database outage results in instance termination rather than just traffic redirection.
2
Compare Auto Scaling group health check types (EC2 vs. ELB).
With EC2 health checks, the Auto Scaling group only replaces instances that fail hardware or system status checks. With ELB health checks, it also replaces instances that fail load balancer target group checks.
To determine how to decouple application-level dependencies (like the database) from instance lifecycle management.
3
Select the optimal configuration to handle temporary database maintenance.
By switching to EC2 health checks, the instances remain running during database downtime. The Application Load Balancer still marks them unhealthy and stops sending traffic, but the fleet is preserved, avoiding a high-cost provisioning loop.
To ensure high availability and cost-efficiency when the database recovers.

Anahtar Kavram

Decoupling Auto Scaling group health checks from Application Load Balancer health checks when downstream dependencies can cause transient failures.
Tahmini Süre:2m 0s
Bu soruyu puanla