Using Global Settings to Configure the Implicit API

With the Lambda Proxy integration, API Gateway just packages all the request properties and forwards them to Lambda. However, if you look at one of the request logs carefully (see figure here), you’ll notice some headers that do not look like they are coming from a browser. For example, CloudFront-Viewer-Country shows the ISO country code where the request originated. This is because the request did not go directly from a browser to API Gateway. Instead, it first went to the AWS global content distribution system called CloudFront, which put in some additional headers.

API Gateway configurations #

SAM can set up two types of API Gateway configuration:

1. edge-optimised
2. regional

Edge-optimised APIs #

Edge optimised APIs are served from a specific region, but the clients connect to the nearest AWS presence point. So far, you’ve been deploying an API to the us-east-1 region in North Virginia, USA. With edge-optimised APIs, a user from Germany will likely connect to an AWS CloudFront endpoint in Frankfurt first, then the request will pass to the API through the internal AWS links, not through the public internet. AWS has fast links between regions and using the nearest point of presence generally improves connection latency for global users. But this also means that someone trying to access the API from North Virginia will go through an unnecessary intermediary.

Regional APIs #

Regional APIs do not set up an intermediary connection using CloudFront. If you deployed a regional API to us-east-1, a user from Germany would connect to the AWS endpoint in North Virginia through the public internet. That would likely make global connections worse, but local connections would be slightly faster.

Although CloudFront adds additional cost to each request, removing it may not actually reduce the overall price significantly. Both API Gateway and CloudFront charge for the number of requests and for data transfer. Data transfer through CloudFront is slightly cheaper than using API Gateway, and AWS does not charge for transfer between its own services. With both services in the pipeline, the requests are slightly more expensive, but data transfers are slightly cheaper. In conclusion, don’t deploy regional endpoints expecting to save money, but do it if you want to remove an intermediary for connections in a specific territory.

By default, SAM assumes that you want to take advantage of edge-optimised APIs, so your users globally get faster responses if you deploy it to just one region. If you plan to deploy entire stacks in different AWS regions, so you can serve users locally, tell SAM to use regional APIs.

To change the endpoint type of the API that SAM creates automatically, create an Api property in the Globals section. Then add a sub-property called EndpointConfiguration inside, and set it to REGIONAL (add lines 4-5 from the following listing to your template).