Choosing the Right Amazon API Gateway Endpoint Type
Learn how to restrict access to Amazon API Gateway REST APIs using IP allowlisting. This blog explains two practical approaches, API Gateway resource policies and AWS WAF, and shows when to use each method to protect public APIs from unwanted traffic.
When you build an API on AWS, Amazon API Gateway is often one of the first services you look at. It helps you create, publish, secure, monitor, and manage APIs without running your own API infrastructure. API Gateway supports different API styles, including REST APIs, HTTP APIs, and WebSocket APIs. But when you create a REST API, there is one choice that can affect performance, security, and architecture from the beginning: the endpoint type.
For REST APIs, API Gateway gives you three endpoint types: Regional, edge-optimized, and private. The transcript explains these three options and focuses on how to choose the right one based on where your users are and how much control you need over networking and routing. This choice may look small in the AWS console. In practice, it matters a lot.
What Is an API Gateway Endpoint Type?
An endpoint type controls how clients reach your API. You can think of it as the “front door” of your API. Some doors are public and optimized for global users. Some are public but stay inside one AWS Region. Others are private and only available from inside your VPC.
AWS officially defines the REST API endpoint types as edge-optimized, Regional, and private. Edge-optimized APIs route requests through CloudFront points of presence, Regional APIs are intended for clients in the same Region, and private APIs are accessed from within an Amazon VPC. So, which one should you choose?
Private Endpoints: For Internal APIs
A private endpoint is the easiest option to understand. Choose a private API when your API should not be exposed to the public internet. For example, you may have internal services running in a VPC, such as Lambda functions, EC2 instances, or backend applications, and only those services should call the API.
AWS says a private REST API is callable only from within an Amazon VPC. To access it, you use an interface VPC endpoint, which creates endpoint network interfaces inside your VPC.
This is useful when you are building:
- Internal microservice APIs
- Backend-only admin APIs
- APIs used by private workloads
- Systems with stricter network isolation requirements
You can also use API Gateway resource policies to control which VPC endpoints can call the private API. That gives you another layer of access control.
In simple terms, use a private endpoint when the API is not meant for public users.
Edge-Optimized Endpoints: For Simple Global Access
An edge-optimized endpoint is designed for APIs used by clients across different geographic locations.
When you choose this option, API Gateway routes requests through the nearest CloudFront point of presence. This can help reduce connection time for users who are far away from the AWS Region where your API is deployed. AWS also notes that edge-optimized is the default endpoint type for API Gateway REST APIs.
For example, imagine your API is deployed in the US, but your users are in Sri Lanka, New Zealand, and Europe. With an edge-optimized endpoint, users connect to a nearby CloudFront edge location first. From there, traffic travels through AWS’s network toward API Gateway. That sounds convenient. And it is.
But there is one important trade-off: the CloudFront distribution is managed by API Gateway. When you create an edge-optimized custom domain, API Gateway sets up the CloudFront distribution and maps the API domain to it.
That means you do not get the same level of control you would have with your own CloudFront distribution. If you want to customize cache behavior, add multiple origins, or manage routing rules yourself, edge-optimized may feel limited.
Use edge-optimized endpoints when your API is public, your users are globally distributed, and your setup is simple enough that you do not need custom CloudFront control.
Regional Endpoints: For More Control
A Regional endpoint exposes the API from a specific AWS Region. It is usually a good fit when your clients are in the same Region, or when you want to place your own CDN in front of the API.
AWS describes Regional API endpoints as intended for clients in the same Region. For example, if an EC2 instance in the same Region calls your API, a Regional endpoint can reduce connection overhead. But Regional endpoints are not only for local users.
They are also a strong choice when you want to use your own CloudFront distribution. The AWS Serverless Applications Lens says Regional endpoints do not provide a CloudFront distribution by default, but they let you associate your own CloudFront distribution or another CDN. This gives you more control.
You can configure:
- Cache policies
- Multiple origins
- Custom routing behavior
- Security headers
- CDN-level rules
- Integration with other backend services, such as an Application Load Balancer
This is why many production systems prefer a Regional API behind a custom CloudFront distribution. You still get global delivery benefits, but you control the CloudFront layer yourself.
Can You Put CloudFront in Front of an Edge-Optimized API?
Technically, yes. But it is usually not the cleanest design. An edge-optimized API already uses a CloudFront distribution managed by API Gateway. If you add your own CloudFront distribution in front of it, you may create an extra CDN layer. That can make routing harder to reason about and may add unnecessary complexity.
A cleaner pattern is this:
Use a Regional API Gateway endpoint, then place your own CloudFront distribution in front of it.
That way, there is only one CloudFront layer, and you manage it directly.
A Simple Decision Guide
Here is a practical way to decide:
- Choose private when the API should only be available inside your VPC.
- Choose edge-optimized when the API is public, global, and simple, and you are comfortable with API Gateway managing CloudFront for you.
- Choose Regional when your users are mostly in one Region, or when you want to use your own CloudFront distribution for better control.
Final Thoughts
API Gateway endpoint types are not just console options. They shape how traffic reaches your API, how much control you have, and how secure or flexible your architecture can be.
For internal APIs, private endpoints are usually the right answer. For simple public APIs with global users, edge-optimized endpoints are easy to start with. For production systems that need custom caching, multiple origins, or more CDN control, a Regional endpoint with your own CloudFront distribution is often the better long-term choice.
The best endpoint type depends on your traffic, your security needs, and how much control your team wants over the network path. Choose it early, because this “small” setting can influence the whole API architecture.