API Gateway: REST vs HTTP APIs — lessons from production

Opening Hook

AWS API Gateway is one of those services where the naming is genuinely confusing: you get REST API and HTTP API, two distinct products built on different architectures, priced differently, and with different feature sets. I've spent enough time deploying both in production to know that picking the wrong one costs you money and latency. In this article, I'll walk you through API Gateway: REST vs HTTP APIs so you can make that choice confidently.

Which One to Choose: Comparing HTTP API vs REST API

Let me start with the practical breakdown. HTTP API launched in 2020 as AWS's answer to "REST API is too expensive and slow for most workloads." They're fundamentally different under the hood, and that difference matters.

Cost and Performance

HTTP API is roughly 70% cheaper than REST API. You're paying $0.35 per million requests for HTTP API versus $3.50 per million for REST API—before you add any additional features. Latency is also notably lower; HTTP API is optimized for simple request-response patterns and typically has sub-100ms overhead, while REST API can add 50-100ms depending on your integration and stage configuration.

In one of our e-commerce projects, we migrated a high-traffic product catalog service from REST API to HTTP API. Our monthly API Gateway bill dropped from $800 to $120, and p99 latency improved by 40ms. For services handling millions of requests daily, this compounds quickly.

Feature Parity and Differences

Here's where it gets important. HTTP API supports:

• JWT authorizers (out of the box)
• CORS configuration
• Request/response transformation via $request and $response variables
• Integration with Lambda, HTTP endpoints, and AWS services
• CloudWatch logging and X-Ray tracing

REST API supports all of that plus:

• Usage plans and API keys
• Request validation (schema-based, built-in)
• Response caching with TTL control
• Method-level throttling (different limits per endpoint)
• Model schemas and request/response mapping templates
• Mutual TLS authentication

The key difference: REST API is feature-rich but heavy; HTTP API is lean and fast. If you need usage plans (to monetize or throttle per-customer), request validation at the gateway level, or response caching, you need REST API. Otherwise, HTTP API gets the job done cheaper and faster.

JWT Authorizers: A Concrete Example

Both support JWT authorizers now, but let me show how they differ in practice. With HTTP API, you configure it in a few lines:

aws apigatewayv2 create-authorizer \
  --api-id abc123xyz \
  --authorizer-type JWT \
  --identity-source '$request.header.Authorization' \
  --jwt-configuration Audience=myapp,Issuer=https://auth.example.com

With REST API, you'd either use a similar built-in JWT authorizer or implement a Lambda authorizer, which adds latency and complexity. For stateless JWT validation, HTTP API wins.

Default to HTTP APIs

My recommendation: start with HTTP API. It's the right default for most use cases because it covers 80% of what you actually need in production.

In the SaaS platform we built last year, we launched with HTTP API for our customer-facing API. We had:

• Lambda integrations for business logic
• JWT authorization via Cognito
• CORS for browser-based clients
• CloudWatch logging
• Custom domain mapping

All of that works flawlessly on HTTP API. No request validation? Fine—we handle schema validation in the Lambda function anyway. No usage plans? We enforce rate limiting via Lambda and DynamoDB. No response caching? Our service is stateless and fast enough that the 50ms API Gateway cache doesn't matter.

HTTP API also scales more predictably. You don't have to manage stage variables, method-level throttling, or deployment dependencies. You deploy once and move on.

The switching cost from HTTP API to REST API later is low if you actually need those features. You'd migrate your routes, update your domain certificate, and redeploy. It's maybe half a day of work. So optimizing for simplicity and cost upfront makes sense.

REST API When You Need It

There are specific scenarios where REST API is the right call.

Usage Plans and API Keys

If you're building a platform where customers consume your API and you need to track usage per customer or enforce per-customer rate limits, REST API's usage plans feature is built-in. You define a plan (e.g., "Standard: 1,000 requests/day"), issue an API key to each customer, and API Gateway enforces the limit automatically.

HTTP API doesn't have this. You'd have to implement it yourself: track API key → customer mapping in DynamoDB, check quota before each request in Lambda, and manage the whole thing. Suddenly you're adding latency and operational overhead to every request.

Request Validation and Caching

REST API's request validation is powerful. You define a JSON Schema, attach it to a method, and invalid requests get rejected at the gateway—before they reach Lambda. This saves Lambda invocations and money.

{
  "type": "object",
  "properties": {
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["email"]
}

Response caching is also REST-API-only. If your endpoint returns data that doesn't change often (product catalogs, config, reference data), you cache it at the gateway for 5 or 60 minutes. Huge performance win, and you're not re-executing Lambda for cached responses.

In our trading platform, we cached market reference data (symbols, trading hours, rules) in REST API with a 1-hour TTL. Thousands of requests hit the gateway cache instead of Lambda. Cache hit rates hit 85%, cutting Lambda costs by a third.

When I've Used REST API

In the CRM we built, customers connected via mobile and web. We needed per-customer rate limiting, response caching for frequently-accessed lead lists, and request validation to catch malformed data early. REST API was the right choice. The extra cost was acceptable because the feature value was high.

Custom Domains

Both HTTP API and REST API support custom domain mapping. You probably don't want your customers calling abc123xyz.execute-api.us-east-1.amazonaws.com. You want them calling api.mycompany.com.

The setup is identical for both:

1. Create or import an ACM certificate for your domain (must be in us-east-1 for API Gateway)
2. Create a domain name mapping in API Gateway, linking your domain to the API
3. Add a CNAME record in Route 53 (or your DNS provider) pointing to the API Gateway endpoint

Here's the practical flow:

# Create ACM certificate (if not already done)
aws acm request-certificate \
  --domain-name api.mycompany.com \
  --domain-name-options DomainName=api.mycompany.com,ValidationDomain=mycompany.com \
  --region us-east-1

# Create domain name in API Gateway (HTTP API)
aws apigatewayv2 create-domain-name \
  --domain-name api.mycompany.com \
  --domain-name-configurations CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/abc123

# Update Route 53 with CNAME
aws route53 change-resource-record-sets \
  --hosted-zone-id Z123ABC \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.mycompany.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "d111111abcdef8.cloudfront.net"}]
      }
    }]
  }'

Once configured, traffic to your custom domain is routed to your API. No difference between HTTP API and REST API here—both integrate with ACM and Route 53 the same way.

Common Mistakes

Mistake 1: Choosing REST API by default. I see teams spin up REST API because it's the "more powerful" option, then never use 90% of its features. You pay for complexity you don't need. Start with HTTP API.

Mistake 2: Implementing usage plans in Lambda instead of using REST API. If usage plans matter to your business, let REST API handle it. Doing it in application code adds latency and bugs. I've seen teams leak quota checks and let customers exceed their limits.

Mistake 3: Assuming HTTP API lacks features. HTTP API added JWT authorizers, CORS, and transformation capabilities. It's not a toy anymore. For most APIs, it's enough.

Mistake 4: Forgetting to enable caching on REST API. Teams set up REST API for its advanced features but forget to configure response caching. You're paying for the API and still hitting Lambda every time. That's leaving money on the table.

Mistake 5: Mixing up cost structure. REST API charges per request and per million data transfer units (for caching and requests). HTTP API is just per request. Read the pricing page carefully.

Key Takeaways

• HTTP API is the default. Start here. It's 70% cheaper, lower latency, and handles JWT auth, CORS, and basic transformations out of the box.
• REST API when you need usage plans, request validation, response caching, or method-level throttling. These features have real business value in specific scenarios.
• JWT authorization works on both now. This was a key REST-only differentiator; it's no longer a decision factor.
• Custom domains are identical between both. Use ACM certificates and Route 53 CNAME records for both HTTP and REST APIs.
• Switching costs are low. You can migrate from HTTP API to REST API later if needed. Optimize for simplicity first, add features when you need them.
• Cache HTTP API responses in CloudFront, not REST API. For sub-gateway caching, using CloudFront in front of HTTP API is often cheaper and more flexible than REST API's built-in cache.