A global company runs applications in us-east-1 inside a VPC. A London office connects to that VPC using a virtual private gateway for a Site-to-Site VPN. The company has a transit gateway peered with the VPC and other departmental VPCs. London users experience latency when accessing the applications. What should a network engineer do to reduce latency?

The correct solution involves creating a new Site-to-Site VPN connection with the Transit Gateway as the target and enabling acceleration. This leverages AWS Global Accelerator's network for improved performance over the public internet, reducing latency for users in London. The existing VPN terminates on a Virtual Private Gateway (VPG), which is not directly compatible with VPN acceleration. Modifying the existing VPN is incorrect because you cannot change the target gateway of an existing VPN connection from a VPG to a Transit Gateway, nor can you enable acceleration on a VPG-terminated VPN. Creating a new Transit Gateway in eu-west-2 and peering it is an overly complex solution that doesn't directly address the latency issue for the existing us-east-1 application and doesn't utilize VPN acceleration. AWS Global Accelerator works with endpoints like EC2 instances or load balancers, not directly with a Site-to-Site VPN connection as an endpoint itself.