HTTP API vs REST API in API Gateway: Differences and When to Use Each

Feature comparison

| Feature | HTTP API (v2) | REST API (v1) | |---|---|---| | Price (per million requests) | ~$1.00 | ~$3.50 | | Latency overhead | ~6ms | ~11ms | | JWT authorizer (native) | Yes | No (Lambda authorizer only) | | Lambda authorizer | Yes | Yes | | IAM auth | Yes | Yes | | Cognito authorizer | Yes (via JWT) | Yes (native) | | CORS auto-config | Yes | Manual (Gateway response + method response) | | Usage plans + API keys | No | Yes | | Request/response transformation | No | Yes (mapping templates, VTL) | | WAF integration | No (attach via CloudFront) | Yes (direct) | | Per-route throttling | Yes (stage-level) | Yes (per-method) | | Caching | No | Yes ($0.02/hr per cache cluster) | | WebSocket | Yes | No (separate WebSocket API) | | Private integrations (VPC Link) | Yes (v2 VPC Link) | Yes (v1 VPC Link) | | $default route | Yes | No | | Stage variables | Yes | Yes |

HTTP API: the common setup

HTTP API is designed for Lambda proxy and HTTP integrations with minimal configuration:

# CloudFormation / SAM example
HttpApi:
  Type: AWS::Serverless::HttpApi
  Properties:
    Auth:
      DefaultAuthorizer: JWTAuth
      Authorizers:
        JWTAuth:
          IdentitySource: $request.header.Authorization
          JwtConfiguration:
            Audience:
              - my-client-id
            Issuer: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_POOL_ID
    CorsConfiguration:
      AllowOrigins:
        - https://app.example.com
      AllowMethods:
        - GET
        - POST
        - DELETE
      AllowHeaders:
        - Authorization
        - Content-Type
      MaxAge: 300

The JWT authorizer validates the token signature and expiry without a Lambda function — no cold starts or additional cost per request.

The $default route

HTTP API's $default route catches all requests that don't match any other route:

Routes:
  GET /users        → Lambda A
  POST /users       → Lambda B
  $default          → Lambda C (catches everything else: PUT, DELETE, /other-paths)

This enables building a single Lambda function that handles all routing internally (e.g., a full Express or Gin app), using API Gateway purely as the ingress rather than for routing logic.

// Lambda behind $default — handles all routes internally
exports.handler = async (event) => {
    const { routeKey, rawPath, body } = event;
    // routeKey is "$default" for catch-all
    // rawPath has the actual request path
    return router.handle(rawPath, event);
};

HTTP API lacks request/response transformation — use REST API when you need to reshape payloads between client and backend

ConceptAWS API Gateway

REST API supports Velocity Template Language (VTL) mapping templates that transform request payloads before they reach the backend and transform responses before they reach the client. This lets you adapt a legacy backend's response format, add fields, remove sensitive data, or translate between JSON and XML — all without a Lambda function. HTTP API has no equivalent. To do transformation with HTTP API, you must add a Lambda function in the request path, adding cost and latency.

Prerequisites

• Lambda proxy integration
• VTL templates
• API Gateway integration types

Key Points

• REST API mapping templates run in API Gateway itself — no Lambda needed for simple transformations.
• HTTP API integration type is always 'proxy' — the raw request hits the backend unchanged.
• Usage plans (rate limits + quotas per API key) are REST API only — HTTP API has stage-level throttling but no per-consumer keys.
• WAF: REST API supports direct WAF attachment. HTTP API requires CloudFront in front.

Migration considerations

HTTP API is API Gateway v2. Migrating from REST API to HTTP API is not a drop-in replacement:

• API keys and usage plans: no equivalent in HTTP API. If you sell API access with per-key quotas, stay on REST API or implement quota tracking in Lambda.
• Request validators: REST API validates request body/headers against JSON Schema before the Lambda is invoked. HTTP API has no built-in validation — validate in Lambda.
• VTL mapping templates: all transformation logic must move into Lambda functions.
• Authorizer caching: REST API Lambda authorizers cache results by identity token (configurable TTL). HTTP API JWT authorizers don't need caching (validation is local, no Lambda invocation).
• Stage-level execution logs: REST API logs each request/response in CloudWatch with detailed integration logs. HTTP API supports access logging (structured JSON) but not execution logging.

You're building an API for third-party developers. They need rate limiting (100 req/min per developer), per-developer usage tracking, and the ability to suspend individual developers. Which API Gateway product fits?

easy

HTTP API has stage-level throttling but no per-consumer API keys. REST API has usage plans with per-key throttling and quotas.

• AHTTP API with a Lambda authorizer that enforces per-developer limits in DynamoDB

  Incorrect.This works but requires you to build and maintain the rate limiting logic, quota tracking, and suspension checks in Lambda. You'd also need DynamoDB storage and atomic counters. REST API usage plans provide this out of the box.
• BREST API with usage plans: each developer gets an API key, assigned to a usage plan with rate limit=100/min and quota. Suspending a developer means revoking or disabling their key

  Correct!REST API usage plans are designed exactly for this: create an API key per developer, assign to a usage plan (throttle: 100 req/min, burst: 200, daily quota: X). API Gateway enforces limits before the Lambda is invoked — no Lambda cold start cost on rejected requests. Disabling an API key immediately blocks that developer. Usage data is available via the GetUsage API.
• CHTTP API — it's cheaper and faster, so it's always the better choice

  Incorrect.HTTP API is cheaper and faster but lacks usage plans. Cost and performance are not the only factors — feature requirements determine which product fits.
• DNeither — use a dedicated API gateway product like Kong or AWS WAF rate limiting

  Incorrect.REST API usage plans solve this use case natively. An external API gateway adds operational overhead. WAF rate limiting is IP-based, not per-API-key.

Hint:Which API Gateway product has API keys and usage plans with per-key rate limiting?