A company has an internal web application that runs on Amazon EC2 instances behind an...

High availability for an EC2-based web application behind an ALB is primarily achieved by eliminating single points of failure at the infrastructure layer. A single Availability Zone (AZ) deployment is vulnerable to AZ-level impairment (power/network issues, facility events, or service disruptions). The most direct and standard AWS approach is to distribute the Auto Scaling group across multiple AZs within the same Region.

Updating the Auto Scaling group to use subnets in at least two AZs allows instances to be launched across AZs automatically. The ALB is built to route traffic across targets in multiple AZs, and Auto Scaling can replace unhealthy instances in any enabled AZ. This provides resilience without the complexity of multi-Region architectures.

Options A and B address capacity for peak load but do not address the core availability requirement. Even with more instances, a full AZ outage would still take the entire application down if all instances are in the same AZ.

Option D (multi-Region) can improve resilience further, but it introduces significantly more operational overhead: cross-Region traffic routing, data replication, DNS failover strategy, application state handling, and potentially active-active or active-passive designs. For “make the application highly available” from a single-AZ baseline, multi-AZ in the same Region is the standard, least-overhead improvement.