What Is API Gateway in AWS? A Clear Breakdown

Amazon API Gateway is a fully managed AWS service that lets you create, publish, secure, and monitor APIs without running your own servers. It sits between your clients (web apps, mobile apps, third-party integrations) and your backend logic — typically AWS Lambda functions, EC2 instances, or other AWS services — and handles the plumbing: routing requests, authenticating callers, throttling traffic, transforming payloads, and logging everything to CloudWatch.

In practical terms, when someone searches "what is API gateway in AWS," they usually want to know one of two things: either they're evaluating it as infrastructure for a new project, or they've inherited a system that already uses it and need to understand what it's doing. This article covers both — what the service actually does, how it's structured, what it costs, and where it fits (or doesn't fit) compared to alternatives.

What Amazon API Gateway Actually Does

At its core, API Gateway is a request router with a lot of built-in middleware. You define routes (like GET /users/{id} or POST /orders), and for each route you configure an integration — the backend that actually handles the request. Common integration types:

• Lambda proxy integration — the most common pattern, where API Gateway forwards the entire request to a Lambda function and returns whatever the function responds with.
• HTTP integration — forwards requests to an existing HTTP endpoint, useful for exposing an internal service externally.
• AWS service integration — talks directly to another AWS service (like DynamoDB or SQS) without a Lambda function in between.
• Mock integration — returns a static response, useful for testing or stubbing endpoints during development.

On top of routing, API Gateway provides:

• Authentication and authorization via IAM, Cognito user pools, or custom Lambda authorizers
• Throttling and rate limiting per API key, per client, or globally
• Request/response transformation using mapping templates (mostly in REST APIs)
• Caching at the gateway level to reduce backend load
• Usage plans and API keys for exposing an API commercially to external developers
• CloudWatch logging and metrics for every request

REST APIs vs. HTTP APIs vs. WebSocket APIs

AWS actually offers three distinct products under the "API Gateway" name, and picking the wrong one is a common source of confusion:

1. REST APIs — the original, feature-rich option. Supports request validation, API keys, usage plans, mapping templates, and private VPC integration. More expensive and slightly higher latency.
2. HTTP APIs — a newer, leaner option built for the common case of proxying to Lambda or HTTP backends. Cheaper (up to 70% less than REST APIs) and lower latency, but fewer built-in features like request transformation.
3. WebSocket APIs — for persistent, bidirectional connections, useful for chat apps, live dashboards, or streaming updates.

If you're starting a new project and just need to expose Lambda functions behind HTTPS endpoints with JWT auth, HTTP APIs are usually the right default. REST APIs make sense when you need fine-grained request validation, response caching, or API key–based usage plans for external consumers.

A Minimal Example

Here's what a basic Lambda-backed route looks like once deployed — from the client's perspective, it's just an HTTPS call:

curl -X POST https://abc123.execute-api.us-east-1.amazonaws.com/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"item": "widget", "quantity": 3}'

Everything before that request hits your Lambda function — auth validation, throttling, logging — is handled by API Gateway. Your function just receives a parsed event object and returns a response.

Pricing and Limits Worth Knowing

API Gateway pricing is pay-per-request plus data transfer, with no minimum fee. As of writing, HTTP APIs cost less per million requests than REST APIs, and there's a default account-level throttle (typically 10,000 requests per second, adjustable via support ticket) that can surprise teams during traffic spikes. Caching, custom domains, and private VPC links each add incremental cost, so it's worth modeling expected traffic before committing to an architecture.

When API Gateway Is the Right Choice — and When It Isn't

API Gateway shines for serverless architectures: Lambda-backed APIs, event-driven backends, and situations where you don't want to manage load balancers or servers at all. It's also a solid choice when you need to expose an API commercially with usage plans and API keys, since that's built in rather than something you'd bolt on yourself.

It's less ideal when you need extremely low, predictable latency at very high volume (an Application Load Balancer in front of ECS or EC2 can be cheaper and faster at scale), or when your team's workload isn't natively AWS — running a self-hosted gateway like Kong or Envoy might give you more portability across clouds.

There's also a category of use case that has nothing to do with infrastructure hosting: turning an existing service you already pay for into a clean API. That's a different problem than "how do I route HTTP requests to my Lambda functions" — it's "I have access to a tool, and I want programmatic, authenticated, metered access to it without building auth and billing myself." For example, SubToAPI takes an existing Claude subscription and exposes it as a standard HTTPS API with its own sub_live_... keys, streaming, and usage metadata — you're not deploying a gateway yourself, you're consuming one that's already built. If you're evaluating API Gateway because you want to wrap a third-party AI tool for your team, it's worth checking whether a purpose-built layer like this saves you the integration work. See the quickstart or pricing for specifics.

Getting Started Practically

If you decide AWS API Gateway is the right tool, the fastest path is usually:

1. Write your backend logic as a Lambda function first, independent of the gateway
2. Create an HTTP API in the console or via AWS SAM/CDK
3. Wire up a route with Lambda proxy integration
4. Add a JWT authorizer (Cognito or your own) if the API needs auth
5. Deploy to a stage and test with curl before wiring up a frontend

Infrastructure-as-code tools (SAM, CDK, Terraform) are strongly recommended over manual console configuration — API Gateway resources get complex fast once you have more than a handful of routes.

FAQ

Is AWS API Gateway the same as an API gateway in general? No. "API gateway" is a general architecture pattern; Amazon API Gateway is AWS's specific managed implementation of that pattern, alongside similar products like Azure API Management or Kong.

Do I need API Gateway if I'm only using Lambda? Not strictly — you can invoke Lambda directly via the AWS SDK or a Lambda Function URL. API Gateway becomes valuable once you need routing, auth, throttling, or a clean public HTTPS interface for multiple functions.

Is API Gateway expensive at scale? It can be, especially with REST APIs at high request volumes. HTTP APIs are significantly cheaper, and many teams switch to an ALB or self-hosted gateway once traffic passes a certain threshold — model your expected volume against current pricing before committing.