Use AWS Global Accelerator to front the API and route client traffic over the AWS global network to the closest edge location with endpoint groups targeting the API in eu-central-1 is correct because it accelerates dynamic, non-cacheable API traffic by routing clients to the nearest AWS edge and then over the AWS backbone to the eu-central-1 endpoints without requiring duplicate Regional stacks.

Global Accelerator reduces long-haul internet latency and jitter by moving traffic onto the AWS global network at an edge location and keeping the single Region deployment in place. This approach improves performance for real time API calls and keeps operational and infrastructure costs lower than running full EC2 environments in multiple Regions.

Create identical EC2-based API stacks in ap-southeast-1 and sa-east-1 and use Amazon Route 53 latency-based routing to direct users to the nearest Regional endpoint can reduce latency for distant users but it forces you to build and operate full environments in each Region which increases cost and complexity and therefore does not meet the requirement to keep costs low.

Provision AWS Direct Connect public VIFs from international customer networks to eu-central-1 and send API requests over those dedicated links is designed for predictable enterprise connectivity and is expensive and impractical to provision for many disparate consumer networks so it does not solve the global consumer latency problem effectively.

Put Amazon CloudFront in front of the API and enable aggressive caching with the CachingOptimized policy for dynamic responses is not suitable for near real time, non-cacheable API traffic because aggressive caching cannot preserve correctness for dynamic responses and therefore offers limited latency improvement compared with Global Accelerator.

Full AWS Practitioner Certification Question