An application front end communicates with backend instances through a Network Load Balancer (NLB) in the same VPC. The application spans two Availability Zones and must minimize inter-AZ traffic. Front-end traffic should remain in the same Availability Zone unless there is no healthy target in that AZ, in which case it should fail over to the other AZ. Which configuration satisfies these requirements?

Disabling cross-zone load balancing on the NLB ensures that traffic primarily stays within the same Availability Zone. By default, NLBs distribute traffic across all healthy targets in all enabled Availability Zones. When cross-zone load balancing is disabled, each NLB node only routes traffic to targets within its own Availability Zone. To direct the front end to its local AZ, it must resolve the specific NLB DNS name for that AZ. If all targets in that AZ become unhealthy, the NLB will fail over to targets in other enabled Availability Zones, meeting the requirement for failover. Incorrect options: Weighted routing in a private hosted zone would distribute traffic based on weights, not necessarily keeping it within the AZ unless there are no healthy targets. It also adds unnecessary complexity for this specific requirement. Failover records in a private hosted zone could work, but the NLB's built-in cross-zone load balancing feature (when disabled) combined with AZ-specific DNS resolution is a more direct and simpler solution for this scenario. Sticky sessions (session affinity) are not applicable to the NLB's behavior for distributing new connections across Availability Zones. Sticky sessions maintain a user's session with a specific target instance, not a specific Availability Zone for initial connection routing.