Does Putting CloudFront in Front of API Gateway Make Sense?
Wondering if putting CloudFront in front of your API Gateway could benefit your architecture? In many cases, it can – by improving performance, adding caching, and reducing costs. This guide breaks down the differences between edge-optimized endpoints and a custom CloudFront setup, so you can decide what’s right for your API.
Using CloudFront in front of API Gateway adds caching, global edge performance, security features like AWS WAF/Shield and cost optimization. Unlike edge-optimized endpoint, a custom CloudFront allows advanced behaviors, logging, geo-restriction and can front multiple origins including API Gateway.
Understanding API Gateway in CloudFront Architecture
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.
Check your cloud infrastructure with a free AWS Well-Architected Review Our experts can focus on optimizing your CloudFront and API Gateway setup as part of this comprehensive evaluation. Get started today and ensure your architecture is robust, scalable, and secure.
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.
FAQs
Yes. You can place Amazon CloudFront in front of Amazon API Gateway to improve performance for global users, enable additional caching, apply AWS WAF, and potentially reduce latency and data transfer costs. This works for both REST and HTTP APIs.
Amazon CloudFront is a content delivery network (CDN) that caches and delivers content from edge locations worldwide to reduce latency. Amazon API Gateway is a fully managed service for creating, securing, and managing APIs, including routing, authorization, and throttling. CloudFront focuses on fast delivery, while API Gateway manages API traffic and integration with backends.
Use CloudFront in front of API Gateway when you need global low-latency access, additional caching beyond API Gateway’s capabilities, integration with AWS WAF, or custom domain management across multiple regions.
Benefits include enhanced caching options, and better possibility for cost optimization for data transfer.
Yes. Amazon API Gateway is AWS’s managed service for building, publishing, securing, and monitoring APIs at any scale, supporting REST, HTTP, and WebSocket APIs.
Conclusion: Should You Use CloudFront in Front of API Gateway?
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
An AWS Solutions Architect with over 5 years of experience in designing, assessing, and optimizing AWS cloud architectures. At Stormit, he supports customers across the full cloud lifecycle — from pre-sales consulting and solution design to AWS funding programs such as AWS Activate, Proof of Concept (PoC), and the Migration Acceleration Program (MAP).
