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?
- AModify 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.
- 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
- CChange 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.
- DConfigure 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.