Regional vs Edge vs Private API Gateway Endpoints (2026)

The most surprising thing about API Gateway endpoints is that "regional" and "edge" aren’t just about location; they fundamentally change how your API is accessed and scaled.

Let’s see this in action. Imagine you have a simple Lambda function that just returns a greeting.

{
  "statusCode": 200,
  "body": "{\"message\": \"Hello from Lambda!\"}"
}

If you deploy this as an API Gateway HTTP API, you’ll get an endpoint. The default is usually a "regional" endpoint. If you then create another API Gateway HTTP API and explicitly choose "edge-optimized" for its endpoint type, you’ll get a different URL.

Here’s what’s happening under the hood.

Regional Endpoints

When you create a regional API Gateway endpoint, the API Gateway service itself is deployed within a specific AWS Region. Your API requests are sent directly to the API Gateway endpoints in that region.

• How it works: Your clients send requests to an API Gateway endpoint like https://<api-id>.execute-api.<region>.amazonaws.com. API Gateway then routes these requests to your backend, which could be a Lambda function, an EC2 instance, or any other HTTP endpoint.
• When to use it: Regional endpoints are great for internal applications or APIs that are primarily accessed by users within the same AWS Region as your API Gateway. They offer lower latency for regional traffic and are generally simpler to set up.
• Scaling: API Gateway automatically scales to handle traffic within that region. You don’t need to provision capacity for API Gateway itself.

Edge-Optimized Endpoints

Edge-optimized endpoints leverage Amazon CloudFront, AWS’s Content Delivery Network (CDN), to distribute your API across multiple AWS Regions.

• How it works: When you choose an edge-optimized endpoint, API Gateway automatically creates a CloudFront distribution for you. Your API requests are sent to the CloudFront edge location closest to the user. CloudFront then caches responses (if configured) and forwards requests to the API Gateway endpoint in the primary region you specified during setup. This means that even though your API Gateway is deployed in a specific region (e.g., us-east-1), users worldwide will hit a CloudFront edge location near them, which then routes to that primary region. The endpoint URL looks like https://<api-id>.execute-api.<region>.amazonaws.com.
• When to use it: Edge-optimized endpoints are ideal for public-facing APIs that need to serve a global audience. They provide lower latency for geographically dispersed users by serving requests from edge locations and offer built-in DDoS protection and caching capabilities through CloudFront.
• Scaling: CloudFront handles the global distribution and caching. API Gateway handles the scaling of the backend within the primary region.

Private Endpoints

Private endpoints are designed for APIs that you want to expose only to resources within your Amazon Virtual Private Cloud (VPC) or on-premises networks connected to your VPC.

• How it works: You associate a private API Gateway with a VPC Endpoint (using AWS PrivateLink). This means your API is accessible only via private IP addresses within your VPC. Requests never traverse the public internet. The endpoint URL will look different, often like https://<api-id>.execute-api.<region>.amazonaws.com but accessed via a VPC endpoint DNS name or directly via the private IP.
• When to use it: Use private endpoints when you need to secure your API and ensure it’s not accessible from the public internet. This is common for internal microservices, data APIs used by applications within your VPC, or when integrating with on-premises systems.
• Scaling: Similar to regional endpoints, API Gateway scales automatically. The VPC endpoint itself is managed by AWS.

The Mental Model: Latency, Reach, and Security

Think of it this way:

• Regional: Your API lives in one AWS data center. Good for local access.
• Edge-Optimized: Your API has "front doors" all over the world (CloudFront). Fast global access, with one "back office" in a primary AWS region.
• Private: Your API is only accessible from inside your secure network. No public entry points.

The choice between these endpoint types hinges on your API’s audience and your security requirements. For a global user base, edge-optimized offers significant latency benefits. For internal services, regional or private endpoints might be more appropriate. Private endpoints are the most restrictive, offering the highest level of network isolation.

The most counterintuitive aspect for many is that the same API Gateway service and backend (like Lambda) can be exposed through these vastly different access patterns, and the choice of endpoint type is made at API Gateway creation time and cannot be changed for an existing API. You have to recreate the API with the desired endpoint type.

The next concept you’ll likely encounter is how to configure custom domains for these different endpoint types, especially integrating them with AWS Certificate Manager (ACM) for SSL/TLS certificates.