Endpoint Types: Edge, Regional, & Private

When you create a REST API, you must choose its endpoint type — this determines how traffic physically reaches your API and which AWS infrastructure sits in front of it. This is a deployment-time decision that affects latency, cost, and security posture.

1. Edge-Optimized (The Default)

• Architecture: AWS automatically provisions a CloudFront Distribution in front of your API. You don't manage this distribution — it's hidden and AWS-controlled.
• Flow: User in Tokyo → CloudFront Edge PoP (Tokyo) → AWS private backbone → API Gateway (us-east-1).
• Why it's faster for global users: Instead of a user in Tokyo traversing the public internet all the way to us-east-1, their request hits the nearest CloudFront Point of Presence (PoP) within milliseconds, then travels the rest of the way over AWS's private, optimized backbone network. The slow, unpredictable public internet leg is minimized.
• Use Case: APIs with geographically distributed clients where you want AWS to manage the CDN layer automatically.
• Limitation: Because the CloudFront distribution is AWS-managed, you cannot customize its behaviors (cache policies, origin settings, etc.). If you need custom CloudFront configuration, use Regional instead.

2. Regional

• Architecture: No CloudFront. The API is directly accessible via a public endpoint in the specific AWS region.
• Flow: User → Public Internet → API Gateway (us-east-1).
• Use Cases:
  • Clients are in the same region (e.g., EC2 instances or ECS tasks calling the API from within us-east-1 — no benefit from a CDN).
  • You want to bring your own CloudFront distribution in front of the API, giving you full control over cache behaviors, custom headers, geo-restriction rules, and WAF associations at the CDN layer.
  • You're building a multi-region active-active architecture with Route 53 latency-based routing — each region gets its own Regional API, and Route 53 routes users to the nearest one.

3. Private

• Architecture: The API has no public internet endpoint. It is only accessible from within your VPC via an Interface VPC Endpoint (powered by AWS PrivateLink).
• Flow: EC2 / ECS / Lambda (in VPC) → Interface VPC Endpoint (ENI in your subnet) → API Gateway.
• Access Control: A Resource Policy on the API explicitly allows or denies access based on VPC, VPC Endpoint ID, or AWS account. Without an explicit Allow in the resource policy, all requests are denied.
• Use Case: Internal microservice APIs, data plane APIs called by backend services, or any API that must never be reachable from the public internet — even accidentally.