AWS Global Accelerator is a service that improves the availability and performance of applications for global users. By adding an accelerator in AWS Global Accelerator and configuring the ALB as the origin, the traffic from users outside the United States will be routed through the Global Accelerator network, which uses the AWS global network infrastructure to optimize the delivery of the application traffic.

Not B. Because Gateway Edge-Optimized API Endpoint improve the performance by caching API responses. But (un)link the call is not supported by API Gateway so the rest will be passed to ALB anyway. So unlikely API gateway will cache and no benefit for performance improvement.

Answer: C AWS Global Accelerator is a service in which you create accelerators to improve the performance of your applications for local and global users. https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html When you create an ALB or NLB, you can optionally add an accelerator at the same time. Elastic Load Balancing and Global Accelerator work together to transparently add the accelerator for you. The accelerator is created in your account, with the load balancer as an endpoint. Using an accelerator provides static IP addresses and improves the availability and performance of your applications. https://docs.aws.amazon.com/global-accelerator/latest/dg/about-accelerators.alb-accelerator.html

A: No B: No, API Gateway doesn’t support LINK, UNLINK, LOCK, UNLOCK. C: No, GA doesn’t have the concept of “origin” - this is a CloudFront concept. D: Yes, because this addresses the main concern which is latency.

imho answer is C. Here is my thinking: There are two issues that we need to consider: 1- Non US Users are reporting long and inconsistent response times for these APIs 2- The APIs are running in EKS and are exposed by the ALB (i.e., not the other way round) So the issue is about latency not API design.

b IS ANS Minimal operational overhead: API Gateway edge-optimized endpoints offer several advantages: Reduced latency: They leverage AWS's global network of edge locations, significantly reducing latency for users outside the United States. Scalability: They automatically scale to handle traffic spikes, eliminating the need for manual intervention. Security: They offer built-in security features, including access control and throttling, minimizing the need for additional configuration. Non-standard methods compatibility: API Gateway supports a wide range of HTTP methods, including custom methods like LINK, UNLINK, LOCK, and UNLOCK, ensuring compatibility with the existing APIs. Ease of configuration: Configuring API Gateway with ALB as the target is straightforward and requires minimal changes to the existing infrastructure.

Amazon CloudFront primarily supports standard HTTP/HTTPS request methods like GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH. It does not natively support non-standard methods such as LINK and UNLINK, LOCK...etc HOWEVER>>>>> If you need to use these non-standard methods, you have a couple of options: Custom Handling with Lambda@Edge API Gateway Integration: If you require more complex routing and method handling, integrating AWS API Gateway with CloudFront might be a more suitable solution. API Gateway provides robust support for various HTTP methods and can be set up to handle non-standard methods. Clearly its B

Option C, GA is safest option.

there is no proper use case for API gateway here

A is invalid because cloudFront only support standard Rest Methods B C D all technically feasible but let's consider "minimized operational overhead" requirement, it's must be C.

Answer: B I don't understand why people are choosing GA. I would rather go with option D. From AWS documentation: Edge-optimized API endpoint The default hostname of an API Gateway API that is deployed to the specified Region while using a CloudFront distribution to facilitate client access typically from across AWS Regions. API requests are routed to the nearest CloudFront Point of Presence (POP), which typically improves connection time for geographically diverse clients. I couldn't find any document mentioning that Edge-optimized API endpoints won't support non-standard REST methods.

Cloudfront cannot handle non standard REST methods. There are Clod front involved behind API Gateway edge-optimized. So only C make sense here

It only can B... Here is a AWS entry. https://repost.aws/knowledge-center/api-gateway-cloudfront-distribution

B would be nice if edge-optimized was supported for HTTP APIs

By adding an accelerator in AWS Global Accelerator and configuring the ALB as the origin, the traffic to the ALB will be routed through the global network, reducing latency and improving response times for users outside the United States. This solution minimizes operational overhead as AWS Global Accelerator handles the routing and optimization automatically, without requiring additional infrastructure deployment or configuration changes.

I was also supporting answer B, however just tested API Gateway and it seems that it only supports GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS methods. I personally couldn't find a way to create a custom method which is part of the requirement. Please share if you find a way

It's B. That's the point of an edge-optimized API endpoint.