A fintech runs active-active trading APIs in eu-west-1 and us-east-1 over TCP with TLS. Clients need fixed anycast IPs, sub-minute failover for TCP health failures, and no DNS caching delays. Compliance requires traffic to stay on the AWS backbone. Which global traffic routing strategy meets multi-Region TCP routing requirements?

Deploying AWS Global Accelerator is correct because it allocates two fixed static anycast addresses that announce from multiple edge locations, routes client TCP connections over the AWS private backbone to the nearest healthy endpoint group in eu-west-1 or us-east-1, performs continuous TCP health checks with sub-minute traffic shifting without DNS changes, and preserves TLS end-to-end to trading APIs. Configuring latency-based DNS still depends on resolvers caching records until TTL expiry, so clients experience delayed failover and do not receive true anycast ingress, violating the no-DNS-delay and fixed-IP needs despite sound health checking. Delivering APIs through a content distribution network provides static edge addresses and fast HTTP origin failover but operates at Layer 7 for HTTP/HTTPS caching and request routing, so it cannot proxy arbitrary TCP trading traffic and breaks the multi-Region TCP requirement. Peering Regions with Transit Gateway does keep inter-Region traffic on the AWS backbone with TCP health awareness, but it only interconnects VPCs internally and offers no public anycast front door for global clients, failing ingress and active-active global routing. Exam caveat is to map keywords precisely: fixed IPs plus no DNS plus TCP plus backbone points to Global Accelerator, while latency, alias, or geolocation signals DNS and distribution or caching signals HTTP. Practical check is to confirm two accelerator endpoint groups with correct TCP health-check ports, allowlist the accelerator IPs in client firewalls, and test forced endpoint failure to observe traffic remaining on the backbone with rapid recovery.