A transit virtual interface is used to access Amazon VPC Transit Gateways which are not included in the solution.

As the requirement is to avoid the internet and use private IP addresses only. The best solution is to use a private virtual interface across the Direct Connect connection to connect to the VPC using private IP addresses.

A VPC endpoint for Amazon API Gateway can be created and this will provide access to API Gateway using private IP addresses and avoids the internet completely.

This will use the public internet, which is not suitable for our scenario.

A hosted virtual interface is used to allow another account to access your Direct Connect link.

1. "all API calls to use private addressing only and avoid the internet" - directly indicates to use Private virtual interface

AWS Global Accelerator is a service that improves the availability and performance of applications with local or global users. You can configure the ALB as a target and Global Accelerator will automatically route users to the closest point of presence.

Failover is automatic and does not rely on any client-side cache changes as the IP addresses for Global Accelerator are static anycast addresses. Global Accelerator also uses the AWS global network which ensures consistent performance.

 EC2 Proxy does not ensure deterministic routing the closest region and failover is happening within a region that does not protect against regional failure. Also, this introduces a potential bottleneck and lack of redundancy.
To read more about EC2 Proxy, click here

A Route 53 Alias record for each ALB with latency-based routing does provide routing based on latency and failover. However, the traffic will not traverse the AWS global network.

To read more about Route 53, click here. 

You can use CloudFront with multiple custom origins and configure for HA. However, the traffic will not traverse the AWS global network.

1. "routing to the closest region and automatic failover" - which leaves us with three options(AWS Global Accelerator, AWS Route 53, AWS Cloudfront) as EC2 proxy cannot route to the closest region and do the automatic failover.
2. "traverse the AWS global network" - Out of all options only AWS Global Accelerator utilizes AWS global network.

ELB is responsible for distributing connections to the instances not for launching instances into subnets.

The service responsible for launching instances into subnets is Auto Scaling here in our solution.

An Amazon Machine Image (AMI) is a master image for the creation of AWS EC2 instances. However, this option seems funny as if the AMI was missing from the launch configuration no instances would be running.

ELB is responsible for distributing connections to the instances not for launching instances into subnets.

The service responsible for launching instances into subnets is Auto Scaling here in our solution.

You can specify in ASG configuration, that new instances should be launched into which subnets. Auto Scaling will try to distribute EC2 instances evenly across AZs. If only one subnet has EC2 instances running in it the first thing to check is that you have added all relevant subnets to the configuration.

1. "Amazon EC2 instances, Amazon ELB and Auto Scaling" and
2. "only one subnet has EC2 instances running in it" - Out of the three mentioned services Auto Scaling is responsible for launching instances into subnets.