REST API vs HTTP API

When you put an API in front of a Lambda function, Amazon API Gateway gives you two main choices: a REST API or an HTTP API. They sound almost the same, but they are different products with different prices and feature sets. Picking the wrong one early can mean you either pay too much for features you never use, or you build something simple on the cheaper option and then hit a wall when you need a feature it does not have. This page explains the trade-offs in plain English so you can pick correctly the first time.

The short version

Both products let clients send HTTP (HyperText Transfer Protocol, the protocol web browsers use) requests that you route to a backend like AWS Lambda (a service that runs your code without servers) or an HTTP endpoint.

• HTTP API is the newer, leaner option. It is about 70% cheaper, has lower latency (the delay before a response), and is the right default for most simple serverless APIs.
• REST API is the older, fully featured option. It costs more and adds a little latency, but it supports features HTTP APIs simply do not have: request/response transformation, API keys with usage plans, native AWS WAF (Web Application Firewall) integration, caching, and more.

Default to HTTP API. Only move up to REST API when you actually need one of its exclusive features. Do not pay for REST API “just in case.”

Feature comparison

Feature	HTTP API	REST API
Price (per million requests)	~$1.00	~$3.50
Latency overhead	Lower	Higher
Lambda & HTTP proxy integration	Yes	Yes
JWT authorizer (built-in)	Yes	No (use Lambda authorizer)
Lambda authorizers	Yes	Yes
IAM authorization	Yes	Yes
Cognito user pools	Via JWT authorizer	Yes
API keys + usage plans (rate limits per customer)	No	Yes
Request validation (reject bad input)	No	Yes
Request/response transformation (mapping templates)	No	Yes
Native AWS WAF	No	Yes
Response caching	No	Yes
Private APIs (inside a VPC)	No	Yes
Edge-optimized endpoints	No	Yes
Usage cost note	Cheapest, fastest	Pay for richer features

A JWT (JSON Web Token) is a signed token a client sends to prove who it is. AWS WAF filters malicious traffic (like SQL injection) before it reaches your API. A VPC (Virtual Private Cloud) is your own private network inside AWS.

When to use HTTP API (the default)

Choose an HTTP API when:

• You are proxying requests straight to Lambda or an HTTP backend.
• Your auth is IAM, a Lambda authorizer, or a standard OIDC/OAuth 2.0 JWT (for example tokens from Amazon Cognito, Auth0, or Okta).
• You want the lowest cost and lowest latency.
• You do not need request transformation, per-customer API keys, caching, or WAF.

This covers the large majority of new serverless APIs.

Create an HTTP API (Console)

1. Open the API Gateway console.
2. Under HTTP API, click Build.
3. Click Add integration, choose Lambda, and select your function (for example orders-fn).
4. Give the API a name like orders-http, click Next.
5. Define a route, for example GET /orders, then click Next.
6. Accept the default $default stage with Auto-deploy on, then click Create.

Create an HTTP API (CLI)

aws apigatewayv2 create-api \
  --name orders-http \
  --protocol-type HTTP \
  --target arn:aws:lambda:us-east-1:111122223333:function:orders-fn

Output:

{
    "ApiEndpoint": "https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com",
    "ApiId": "a1b2c3d4e5",
    "Name": "orders-http",
    "ProtocolType": "HTTP"
}

Note the CLI uses apigatewayv2 for HTTP APIs (and WebSocket APIs). REST APIs use the older apigateway (v1) command set.

When to use REST API

Choose a REST API when you need one or more of these:

• API keys and usage plans — hand out keys to customers and throttle each one (for example 100 requests/second per key). HTTP APIs cannot do this.
• Request/response mapping templates — reshape the payload between client and backend (for example turn a query string into a JSON body). HTTP APIs only do simple parameter mapping.
• Request validation — reject requests that fail a JSON Schema before they ever hit Lambda, saving compute cost.
• Native AWS WAF — attach a Web ACL directly to the stage.
• Response caching — cache GET responses to cut backend load.
• Private APIs — expose the API only inside a VPC.

Create a REST API with a key + usage plan (CLI)

# 1. Create the REST API
aws apigateway create-rest-api --name orders-rest

# 2. Create an API key
aws apigateway create-api-key --name partner-acme --enabled

Output:

{
    "id": "k1l2m3n4o5",
    "name": "partner-acme",
    "enabled": true,
    "value": "9aQ7r2Xc8b...redacted"
}

# 3. Create a usage plan that throttles to 100 req/s, 200 burst, 1M/month
aws apigateway create-usage-plan \
  --name partner-tier \
  --throttle rateLimit=100,burstLimit=200 \
  --quota limit=1000000,period=MONTH

Output:

{
    "id": "p9q8r7",
    "name": "partner-tier",
    "throttle": { "burstLimit": 200, "rateLimit": 100.0 },
    "quota": { "limit": 1000000, "period": "MONTH" }
}

You then link the key to the plan with aws apigateway create-usage-plan-key.

Console path to the same features

1. Open the API Gateway console and click Create API.
2. Under REST API, click Build and name it orders-rest.
3. Build your resources/methods, then Deploy API to a stage like prod.
4. For keys: go to API Keys > Create API key, then Usage Plans > Create, set rate/burst/quota, and attach the key and stage.
5. For WAF: open AWS WAF, create a Web ACL, and associate it with your API Gateway stage.

Cost example

Say your API serves 10 million requests per month:

• HTTP API: ~$10/month in request charges.
• REST API: ~$35/month in request charges, plus extra if you enable caching (cache memory is billed per hour).

For most workloads that gap matters, and it grows linearly with traffic. At 1 billion requests/month the difference is roughly $1,000 vs $3,500.

Latency-sensitive or high-volume? HTTP API’s lower per-request overhead compounds at scale. But if you need API-key metering for paying customers, the REST API premium is usually worth it — you are buying billing and rate-control you would otherwise build by hand.

A simple decision flow

1. Do you need API keys/usage plans, request transformation, request validation, native WAF, caching, or a private (VPC) API? If yes, use REST API.
2. Otherwise use HTTP API — it is cheaper, faster, and supports JWT auth out of the box.

Best Practices

• Default to HTTP API; reach for REST API only when a specific exclusive feature is required.
• Use the built-in JWT authorizer on HTTP APIs instead of writing a custom Lambda authorizer when your identity provider issues standard tokens — it is faster and free.
• If you adopt REST API for API keys, remember keys are for identification and metering, not security — always pair them with a real authorizer.
• Turn on request validation on REST APIs to reject bad input before Lambda runs, which saves compute cost.
• Always deploy behind a stage (for example prod) and enable access logging so you can debug and audit traffic.
• Re-evaluate periodically: a feature you needed on REST API may now be supported on HTTP API, since AWS keeps closing the gap.

Related Topics

• What is API Gateway?
• Build a serverless API
• What is AWS Lambda?
• Create a Lambda function
• SAM and frameworks