A trading platform exposes a stateful real-time order API over TCP and a separate UDP market-data feed from Network Load Balancers in three Regions. Users worldwide report inconsistent connection setup times and occasional jitter that breaches the platform's sub-50ms regional latency KPI, and packet captures show traffic taking variable public-internet paths to the nearest Region. The responses are user-specific and cannot be cached. The team wants to route each client to the closest healthy Region over the AWS backbone with stable entry points and the least operational overhead. Which approach MOST effectively improves performance?
- APlace an Amazon CloudFront distribution in front of both endpoints and disable caching with a zero time to live, so requests ride the edge network to the origin Regions while every response is fetched live from the load balancers.
- BAdd AWS Global Accelerator with the regional Network Load Balancers as endpoints, so clients connect to static anycast addresses and traffic enters the AWS backbone at the nearest edge and is routed to the closest healthy Region. Correct
- CCreate Amazon Route 53 latency-based records for the three load balancers with health checks, so DNS resolution sends each client to the Region that currently measures the lowest latency from its resolver location.
- DPublish the elastic IPs of the existing Network Load Balancers directly and let clients connect to those fixed regional addresses, so the TCP and UDP traffic reaches the application tier without any added global routing layer.
Why A is wrong: CloudFront accelerates HTTP and is optimised for cacheable content, but it does not front raw TCP and UDP listeners and adds little for fully dynamic, non-HTTP order and market-data traffic.
Why B is correct: Global Accelerator ingests TCP and UDP at the nearest edge onto the AWS backbone, gives fixed anycast entry points, and routes to the closest healthy endpoint, which cuts latency and jitter for non-cacheable traffic.
Why C is wrong: Latency-based DNS steers clients per Region but resolves to public IPs over variable internet paths and is subject to resolver caching, so it does not deliver the stable backbone-routed entry points the workload needs.
Why D is wrong: Publishing the regional Network Load Balancer IPs gives fixed entry points but keeps clients on public-internet paths to a single Region each, so it neither uses the AWS backbone nor routes globally to the closest healthy Region.