Case study


Does Putting CloudFront in Front of API Gateway Make Sense?

In this article, you’ll learn:

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:

Api gateway endpoint types

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.

FlashEdge CDN freetrial banner

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.

Cloudfront and API Gateway manual 1

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

Cloudfront and API Gateway manual 2

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

Cloudfront and API Gateway manual 2

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

Cloudfront and API Gateway manual 2

6. Select Response headers policy: Simple CORS.

Cloudfront and API Gateway manual 2

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.


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

Similar blog posts

See all posts
CategoryCase Studies

Windy - The Extraordinary Tool for Weather Forecast Visualization

StormIT helps Windy optimize their Amazon CloudFront CDN costs to accommodate for the rapid growth.

Find out more
CategoryCase Studies

AWS Well-Architected Review Series: Healthcare Industry Client

Transforming healthcare AWS operations with StormIT using our expertise and the AWS Well-Architected Framework. Learn more.

Find out more
CategoryCase Studies - Breaking the Legacy Monolith into Serverless Microservices in AWS Cloud

The StormIT team helps with the creation of the AWS Cloud infrastructure with serverless services.

Find out more
CategoryCase Studies

AWS Well-Architected Review Series: Renewable Energy Industry Client

See how StormIT optimized a renewable energy client's AWS infrastructure through the Well-Architected Framework. Explore now...

Find out more
CategoryCase Studies

Microsoft Windows in AWS - Enhancing Kemper Technology Client Solutions with StormIT

StormIT helped Kemper Technology Consulting enhance its technical capabilities in AWS.

Find out more

Introducing FlashEdge: CDN from StormIT

Let’s look into some features of this new CDN created and recently launched by the StormIT team.

Find out more