API Gateway Endpoint Types: Regional, Edge-Optimized, and Private

The three endpoint types

| Type | Where requests terminate | Client location | Use case | |---|---|---|---| | Regional | AWS region (e.g., us-east-1) | Same region or behind own CDN | Internal services, custom CloudFront setup | | Edge-optimized | CloudFront edge PoP nearest to client | Geographically distributed public clients | Public APIs with global reach, no custom CDN | | Private | VPC Interface Endpoint (PrivateLink) | Inside the VPC or connected network | Internal microservices, no internet exposure |

Regional

Regional endpoints terminate at the API Gateway service in the specified AWS region. The request path is:

Client → [internet] → API Gateway (us-east-1) → Lambda/HTTP backend

Regional is the right default for:

• APIs called from the same region (e.g., backend-to-backend)
• APIs where you want to attach your own CloudFront distribution with custom cache behaviors, WAF rules, or multiple origins
• APIs where you control geographic routing through Route 53 geolocation or latency routing

The TLS certificate for a regional endpoint is provisioned in the same region as the API.

Edge-optimized

Edge-optimized endpoints sit behind a managed CloudFront distribution that AWS creates and maintains automatically:

Client (Tokyo) → CloudFront PoP (Tokyo) → API Gateway (us-east-1) → Lambda

The client connects to the nearest CloudFront edge, which maintains a persistent TCP connection to API Gateway in the home region. This reduces connection setup latency for clients far from the API's region.

Limitations that often make regional + custom CloudFront better:

• You cannot configure cache behaviors on the managed CloudFront distribution
• You cannot attach a WAF WebACL directly to the managed distribution
• Custom domain TLS certificates must be in us-east-1 (CloudFront requirement), regardless of API region
• The managed distribution's behaviors are not visible in your CloudFront console

Edge-optimized routes to a fixed home region — the CloudFront PoP reduces TCP handshake latency but does not cache API responses by default

GotchaAWS API Gateway / CloudFront

The CloudFront distribution in front of an edge-optimized API does not cache responses by default. Requests still go all the way to the API Gateway regional endpoint — the edge only reduces the round-trip for connection establishment (TCP handshake, TLS negotiation). For a client in Tokyo connecting to an API in us-east-1, the edge PoP in Tokyo handles the TLS termination and maintains a warm connection to us-east-1 over AWS's backbone. Actual response caching requires enabling API Gateway caching separately, which is stage-level and independent of the endpoint type.

Prerequisites

• CloudFront edge locations
• TCP connection latency
• API Gateway stages

Key Points

• Edge-optimized ≠ cached. Requests still reach the backend on every cache miss (default: always miss).
• Custom domain TLS cert for edge-optimized must be in us-east-1 — ACM cert in any other region won't work.
• For custom WAF/cache behavior: use regional endpoint + your own CloudFront distribution.
• Edge-optimized is best when clients are globally distributed and you don't need custom CDN behavior.

Private

Private endpoints are only reachable through a VPC Interface Endpoint (powered by AWS PrivateLink):

Lambda/ECS (in VPC) → Interface VPC Endpoint → Private API Gateway → backend
                        (vpce-xxx.execute-api.region.vpce.amazonaws.com)

Setup requires:

1. Create an Interface VPC Endpoint for execute-api in the VPC
2. Create a resource policy on the API restricting access to the VPC or VPC endpoint
3. Optionally restrict to specific VPCs using aws:SourceVpc condition

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "arn:aws:execute-api:us-east-1:123456789:api-id/*",
    "Condition": {
      "StringEquals": {
        "aws:SourceVpc": "vpc-abc123"
      }
    }
  }]
}

Private APIs have no public DNS resolution — they're only resolvable via the VPC endpoint's private DNS.

You need a public REST API serving mobile clients worldwide. You also want to attach a WAF to block malicious IPs and cache GET responses at the CDN layer. Which endpoint type and architecture?

medium

Edge-optimized uses a managed CloudFront distribution you can't configure. Regional lets you attach your own.

• AEdge-optimized — it already has CloudFront and handles global distribution automatically

  Incorrect.Edge-optimized's managed CloudFront distribution cannot have WAF WebACLs attached or cache behaviors configured. You'd get global routing but no WAF or CDN caching.
• BRegional endpoint + your own CloudFront distribution with a WAF WebACL and custom cache behaviors

  Correct!Regional API Gateway + custom CloudFront gives full control: attach WAF WebACL to the CloudFront distribution, configure cache behaviors per path pattern (e.g., cache GET /products/* for 60s, no cache for POST), set custom error pages, and use multiple origins. The TLS certificate can be in any region. This is the standard pattern for production public APIs requiring WAF and caching.
• CPrivate endpoint with a public-facing ALB in front

  Incorrect.Private endpoints are not reachable from the internet — only from VPCs via PrivateLink. Putting an ALB in front doesn't help because the ALB would need to reach the private endpoint through a VPC endpoint, and you'd still need to handle WAF and caching at the ALB/CloudFront layer.
• DEdge-optimized with API Gateway caching enabled at the stage level

  Incorrect.Stage-level API Gateway caching (the $default cache cluster) works regardless of endpoint type, but it doesn't replace CDN-layer caching and doesn't let you attach a WAF to the CloudFront distribution.

Hint:What can you configure on a managed CloudFront distribution vs your own?