HTTP APIs are cheaper: a practical guide for developers

HTTP APIs are cheaper—and you should know why

If you've been running production workloads on API Gateway REST APIs, you're likely paying more than you need to. HTTP APIs are cheaper, faster, and still handle the vast majority of real-world use cases. I've migrated three internal services at my last role and saw monthly bill reductions of 40–60% on gateway costs alone, with zero impact on application logic.

Lower price per million requests

The pricing difference is straightforward. REST APIs cost $3.50 per million requests; HTTP APIs cost $0.90 per million requests. That's roughly a 75% reduction on gateway charges. For a service handling 100 million requests per month—which isn't unusual for e-commerce or SaaS platforms—you're looking at $350 per month on REST APIs versus $90 on HTTP APIs.

The Lambda compute costs remain identical. You pay the same for function execution time, memory, and invocations. What you're saving is purely the API Gateway layer. On high-volume services, this compounds quickly. I worked on a travel booking platform processing around 500 million requests monthly. Switching from REST to HTTP APIs saved us roughly $1,300 per month, which funded dedicated observability tooling for the entire backend team.

The catch is that HTTP APIs don't support every REST API feature. Before you celebrate the savings, you need to audit your current setup. If you're using VPC integrations, request/response models, or certain authorization patterns, you might not be able to migrate everything immediately. But for most transactional APIs—the ones handling CRUD operations, webhooks, and mobile backends—HTTP APIs are the right fit.

Lower latency

HTTP APIs are built on a simpler architecture than REST APIs. REST APIs have more stages of processing, richer feature sets, and higher overhead. In practice, this means HTTP APIs typically have 10–20% lower latency. That might sound marginal, but in high-concurrency scenarios or when every millisecond matters (trading systems, real-time notifications), it adds up.

I measured this on a NestJS backend handling ride-hailing requests. With REST APIs, the p99 latency from client to Lambda execution was around 45ms. After migrating to HTTP APIs, it dropped to 38ms. That 7ms difference came entirely from the gateway layer. Combined with Lambda cold start optimizations, we went from occasional user-facing delays to consistently fast response times.

Latency also matters for cost optimization. If your Lambdas spend less time waiting for gateway overhead, they finish faster, consuming fewer compute units. It's a small secondary benefit, but it exists. On a containerized backend, you might not notice it. On serverless, every millisecond of execution time is billed.

Native JWT authorizers

HTTP APIs have first-class support for JWT validation without writing custom authorizer code. You point it at a JWKS endpoint, configure claims validation, and you're done. REST APIs require you to write Lambda authorizers, manage caching, and handle token validation yourself.

Here's a practical example. With HTTP APIs, your configuration looks like this:

{
  "authorizers": {
    "jwt": {
      "identitySource": "Authorization",
      "jwtAudience": ["api.example.com"],
      "issuer": "https://auth.example.com",
      "jwksUri": "https://auth.example.com/.well-known/jwks.json"
    }
  }
}

With REST APIs, you'd write a Lambda authorizer to fetch the JWKS, validate the token, and return an IAM policy. That's extra code, extra Lambda invocations, extra latency, and extra cost. For services using Auth0, Cognito, or any standard OIDC provider, HTTP APIs eliminate this boilerplate entirely.

The authorizer runs on the HTTP API side, not in your Lambda. If validation fails, the request never reaches your function. If it passes, the JWT claims are injected into the request context. Your application code receives clean, pre-validated data. This is exactly how it should work.

Check feature gaps before migrating

HTTP APIs are powerful, but they're not REST APIs. Here's what you lose:

• VPC link integrations (HTTP APIs can't reach resources inside a private VPC via integration endpoints)
• Request/response transformation models (you'll need to do this in your Lambda or middleware)
• Binary media types (not natively supported; you need Base64 workarounds)
• Custom domains with mutual TLS (HTTP APIs don't support this yet)
• WAF integration (REST APIs integrate directly; HTTP APIs use a CloudFront distribution as a workaround)

Before migrating, audit your current setup. Write a small script to pull your REST API definition and check against these constraints. If you're not using any of these features, you're safe. If you are, you have options: refactor your architecture, use a hybrid approach (some services on HTTP, some on REST), or stay on REST until AWS adds the features you need.

I've migrated services in both categories. A CRM backend using HTTP-only patterns? Straightforward, zero friction. An internal admin API with VPC links and binary uploads? We kept it on REST because the refactoring cost outweighed the savings. Be pragmatic about this.

Common mistakes

Assuming you can migrate everything at once: Don't. Test on a non-critical service first. HTTP APIs have different CloudWatch metrics, CORS behavior, and error responses. Your observability tooling might need updates.

Forgetting about CORS: HTTP APIs handle CORS differently than REST APIs. The configuration is simpler, but if you copy-paste your REST API setup, you'll get it wrong. Read the docs, test with your actual clients, and validate before going live.

Not benchmarking JWT authorizers: The built-in JWT validation is fast, but if your auth service is slow or your JWKS endpoint has high latency, that becomes your bottleneck. Monitor the authorizer execution time. If it's consistently high, consider caching the JWKS locally or moving to a different auth approach.

Ignoring the stage environment: HTTP APIs stage configuration is simpler than REST APIs, which is good. But "simpler" also means fewer options for complex deployments. If you need per-stage Lambda aliases or complex traffic shifting, test thoroughly.

Key takeaways

• HTTP APIs cost roughly 75% less than REST APIs on a per-request basis—significant savings at scale.
• Lower latency is a secondary benefit; HTTP APIs are 10–20% faster in practice due to simpler processing.
• JWT authorizers come built-in, eliminating boilerplate Lambda code and reducing complexity for standard auth patterns.
• Feature gaps (VPC links, binary media types, request/response models) are real—audit your current setup before migrating.
• Start with non-critical services. Test CORS, observe authorizer latency, and validate with real clients before rolling out to production.
• HTTP APIs are the right choice for transactional, high-volume backends. REST APIs still have their place for complex, feature-rich integrations.