AWS API Gateway: What It Is and When to Use It

What AWS API Gateway Actually Does

AWS API Gateway is a managed service for creating, publishing, and securing HTTP APIs without running your own reverse proxy or load balancer. It sits in front of backend compute — usually Lambda, but also EC2, ECS, or any HTTP endpoint — and handles routing, authentication, throttling, request/response transformation, and usage metering.

The core reason teams reach for it: you don't want to run and patch an Nginx or Kong instance, manage TLS certificates, or write your own rate-limiting logic. AWS handles scaling, availability, and the undifferentiated plumbing, and you pay per request instead of for idle servers.

REST API vs HTTP API vs WebSocket API

AWS API Gateway isn't one product — it's three API types under one console, and picking the wrong one is the most common early mistake.

• HTTP APIs — the newer, cheaper, lower-latency option. Good default for Lambda proxy integrations, JWT authorizers, and simple CRUD-style routing. Fewer features than REST APIs, but that's rarely a problem.
• REST APIs — the original product. Supports request/response mapping templates, usage plans with API keys, private VPC endpoints, and AWS WAF integration. Choose this if you need fine-grained request validation or you're billing per-key usage.
• WebSocket APIs — for persistent, bidirectional connections (chat, live dashboards, streaming updates). Routes messages based on a $connect, $disconnect, or custom action field instead of HTTP verbs.

If you're building a typical backend-for-frontend or public API, start with an HTTP API and only move to REST if you hit a feature gap.

When You Need AWS API Gateway

It's a strong fit when:

• Your backend is serverless (Lambda) and you need a stable HTTP front door for it.
• You need per-client API keys, usage plans, or throttling without building that logic yourself.
• Traffic is bursty or unpredictable and you don't want to size servers for peak load.
• You're already deep in AWS and want IAM, Cognito, or WAF to plug in directly.

When to Skip It

API Gateway adds latency (typically single-digit to low double-digit milliseconds per hop) and a per-request cost that adds up at high volume. It's also easy to over-engineer:

• If your backend is a single containerized service behind steady traffic, an Application Load Balancer is cheaper and simpler.
• If you need long-lived streaming HTTP responses (like token-by-token LLM output), API Gateway's payload and timeout limits can get in the way — this is a common pain point for teams building AI features.
• If you just need to expose an existing model or service as a keyed API with usage tracking and don't need custom routing logic, building the whole API Gateway + Lambda + DynamoDB usage-tracking stack yourself is a lot of infrastructure for a narrow problem. This is exactly the gap something like SubToAPI fills for AI access specifically: you get sub_live_... API keys, streaming, tool use, and usage metadata out of the box, without wiring together a gateway, an authorizer, and a metering pipeline. See the quickstart if that's closer to what you're actually trying to build.

Setting Up a Basic AWS API Gateway

A minimal HTTP API in front of a Lambda function looks like this using the AWS CLI:

# create the HTTP API
aws apigatewayv2 create-api \
  --name "my-service-api" \
  --protocol-type HTTP \
  --target arn:aws:lambda:eu-west-1:123456789012:function:my-function

For anything beyond a single-route proxy, you'll typically:

1. Create the API and a default stage (or use $default for auto-deploy).
2. Add routes (GET /items, POST /items/{id}) mapped to Lambda integrations.
3. Attach a JWT or Lambda authorizer for auth.
4. Configure throttling limits (burst and steady-state rate) per stage or per route.
5. Enable access logging to CloudWatch for debugging and audit trails.

Once deployed, a route is callable directly:

curl https://abc123.execute-api.eu-west-1.amazonaws.com/items/42

The setup is straightforward for a handful of routes but grows in complexity fast once you add custom domains, request validation, canary deployments, and per-client rate limits — at which point Infrastructure-as-Code (CDK, Terraform, SAM) becomes necessary rather than optional.

AWS API Gateway Pricing, Briefly

Pricing is usage-based: you pay per million API calls, plus data transfer out, and (for REST APIs) an additional charge for caching if enabled. HTTP APIs are cheaper per request than REST APIs. There's no charge for idle time — if nobody calls your API, you pay nothing beyond storage for logs. This makes it attractive for low-traffic or spiky internal tools, and less attractive at very high, steady request volumes where a load balancer plus fixed compute can end up cheaper.

Always model cost against your actual request volume and payload size before committing — the per-request math changes meaning depending on whether you're serving a handful of internal services or a public API with millions of daily calls.

Alternatives Worth Considering

• Application Load Balancer (ALB) — simpler and cheaper for steady traffic to containers or EC2, but no built-in API key management or usage plans.
• Self-hosted gateway (Kong, Nginx, Envoy) — full control, no per-request AWS fee, but you own patching, scaling, and TLS renewal.
• Cloudflare Workers / other edge gateways — good for global low-latency routing with less AWS lock-in.
• A managed layer built for a specific use case — if the "API" you're exposing is really just access to an AI model with metering and team seats, a general-purpose gateway is more infrastructure than the problem needs. Check pricing for a narrower, purpose-built alternative before building the AWS stack from scratch.

Choosing the Right Tool

AWS API Gateway is the right default when you're already on AWS, your backend is Lambda-based, and you need standard REST/HTTP routing with authentication and throttling. It's the wrong tool when your actual need is narrower — like exposing a single AI provider behind API keys with usage tracking — because you end up rebuilding metering, key issuance, and streaming support that a focused product already ships.

FAQ

Is AWS API Gateway the same as an API management platform like Apigee? No. API Gateway handles routing, auth, and throttling for your own backend. Full API management platforms add developer portals, monetization, and analytics on top — features you'd need to build separately on AWS.

Does AWS API Gateway support streaming responses? HTTP APIs support response streaming in limited cases, but there are payload size and timeout constraints that make it a poor fit for long-lived token-by-token streaming, such as LLM output. Purpose-built API layers handle this more directly — see /docs/streaming for an example.

Can I use AWS API Gateway without Lambda? Yes. It can proxy to any HTTP backend — EC2, ECS, on-premises servers via VPC Link, or third-party APIs — Lambda is just the most common integration, not a requirement.