Does Putting CloudFront in Front of API Gateway Make Sense?

In this article, you’ll learn:

• API Gateway endpoint types
• Edge-optimized API Gateway vs API Gateway with Amazon CloudFront distribution
• Benefits of using Amazon CloudFront together with Amazon API Gateway
• Creating a CloudFront distribution in front of API Gateway

Amazon API Gateway is a managed service that lets you easily handle common API tasks such as routing, security, caching, throttling, and monitoring.

Because API is used widely, it’s common that customers want to have a global API presence. When using Amazon API Gateway, it’s possible to use an Edge-optimized API endpoint, which is a managed CloudFront distribution and API together in one service. But is it always sensible not to use your CloudFront distribution? Are there any benefits to starting using CloudFront in front of the API Gateway?

In this blog post, we’ll look at API Gateway endpoint types and the difference between Edge-optimized API gateway and API Gateway with CloudFront distribution.

API Gateway endpoint types

Frst, let’s look at the API endpoint types that you can use in AWS when you choose to use REST APIs:

Edge-optimized API endpoints

Edge-optimized API endpoints are best for geographically dispersed clients. API requests are routed to the nearest CloudFront edge location. This is the default endpoint type for API Gateway REST APIs. But this hosted CloudFront distribution is only there to help with connection latency and does not perform caching.

Regional API endpoints

Regional API endpoints are available for clients in the same region. Regional APIs can reduce connection overhead when clients running on EC2 instances call APIs in the same region, or when the API is designed to serve a small number of high-demand clients.

Private API endpoints

A private API endpoint is an API endpoint that is only accessible from your Amazon Virtual Private Cloud (VPC) through an interface VPC endpoint, which is an endpoint network interface (ENI) that you create in your VPC.

Edge-optimized API Gateway vs API Gateway with CloudFront distribution

Edge-optimized API Gateway

The main benefit to using an edge-optimized API gateway is that you get CloudFront distribution without the need to set it up or update or manage it. Everything is hidden behind the REST API. But this also has some drawbacks.

Benefits of using Amazon CloudFront together with Amazon API Gateway

The first and major benefit of CloudFront is caching which may be a motivation for using CloudFront with API Gateway. Although API Gateway offers a built-in caching mechanism, it has some drawbacks:

• It's only available for older REST APIs.
• It's priced by the hour (512MB costs 0.02$ per hour).
• If API Gateway returns an error, it will cache the error.

There are some more specific benefits to using your own CloudFront distribution in front of Amazon API Gateway:

• Currently, AWS Shield Advanced doesn't support enabling protection on API Gateways but supports CloudFront.
• You can add custom caching behaviors (for example static files on S3, and some paths going to an ALB+EC2), and some paths going to API Gateway in multiple regions. This allows you to have everything behind the same domain.
• CloudFront also supports geoblocking, which you can use to help block requests from particular geographic locations from being served.
• Set up Cloudfront access logs.
• Your own CloudFront distribution can be used with any type of API Gateway: WebSocket API, HTTP API, REST API.
• The data transfer costs to the Internet are smaller for CloudFront than API Gateway (0.085$ vs 0.090$), with data transfers between API Gateway and CloudFront are free of charge. And it’s possible to optimize CloudFront costs further with StormIT optimized pricing. CloudFront offers 1TB of DTO in the free tier.
• You can leverage Lambda@Edge to bring the code to the edge and enact HTTP header manipulations, URL rewrites/redirects, cache-key normalizations, and more.

Does putting CloudFront in front of API Gateway make sense?

As always, it depends on the API Gateway use cases and your requirements. If you find any benefits described interesting or you require only some of the CloudFront features, it’s very easy to start using CloudFront. In the next section, you will find a manual with steps that should help you get started.

Creating a CloudFront distribution in front of API Gateway

These simple steps should help you to create a CloudFront distribution in front of API Gateway.

When you create a CloudFront distribution, it’s recommended that you block access to API Gateway for anything other than CloudFront distribution. You can do this by following this manual: Prevent requests from accessing API directly.

1. Log in to the CloudFront console.
2. If you already have a CloudFront distribution that you want to use, you can create a new caching behavior setting. But we will start with creating a new distribution.

3. For the “Origin domain”, add the API gateway link and choose “HTTPS only” as the “Protocol”. API Gateway doesn't support unencrypted HTTP.

4. For “Viewer protocol policy”, select “Redirect HTTP to HTTPS” and choose “Get, Head, Options, Put, Post, Patch, Delete” for “Allowed HTTP methods”.

5. In Cache key and origin requests select “Legacy cache settings” and:

a. Headers: None. You can also choose “Include the following headers” and select what headers you need to forward to API Gateway. However, there is a problem with the Host header that causes a 403 forbidden error, so do not choose this header or option “All”, as it will not work.
b. Query strings: All
c. Cookies: All

6. Select Response headers policy: Simple CORS.

7. You can leave everything else on default or set what you need and click on “Create distribution”.
8. Your CloudFront distribution should be ready to use after couple of minutes. For example, you can proceed to add the cloudfront domain to Route 53 DNS.

Conclusion

This guide should describe the main benefits of using your CloudFront distribution with Amazon API Gateway. In a real-world scenario, it’s much more difficult to decide whether it’s a good idea or whether you should use an edge-optimized API.

Our team is ready to help with this decision and with the implementation of AWS services, so don’t hesitate to contact us.

Contact us