What is API Gateway?

Amazon API Gateway is a fully managed service that acts as the “front door” for your APIs. An API (Application Programming Interface) is a set of endpoints that clients — web apps, mobile apps, or other services — call over the internet. Instead of writing and operating your own web server to receive those requests, API Gateway receives them for you, then routes each request to whatever runs your logic (most often an AWS Lambda function, but also any HTTP backend or other AWS service). It handles the boring-but-critical plumbing — routing, authentication, rate limiting, and request validation — so your code only has to handle business logic.

Why use a managed API front door

When you expose an API to the public internet, you need much more than just code that returns data. You need TLS (Transport Layer Security — the encryption behind HTTPS), authentication to check who the caller is, throttling to stop one client from overwhelming you, and a stable URL that does not change when your backend does. API Gateway gives you all of that without running a single server.

It sits between your clients and your backend and does the following on every request:

Routing — maps a path and HTTP method (like GET /orders/{id}) to a specific backend integration.
Authentication and authorization — checks API keys, AWS IAM (Identity and Access Management) credentials, Amazon Cognito user tokens, or your own Lambda authorizer before the request reaches your code.
Throttling and quotas — limits requests per second and total requests per day so a traffic spike (or an abusive client) cannot melt your backend.
Request/response transformation — validate, reshape, or map payloads between client and backend.
Monitoring — built-in metrics, logging to Amazon CloudWatch, and tracing with AWS X-Ray.

When to use this: Reach for API Gateway when you are building a public or partner-facing API that needs auth, rate limiting, custom domains, or multiple stages (dev/test/prod). It is the default choice for serverless REST/HTTP APIs backed by Lambda.

API Gateway API types

API Gateway offers three flavors. Picking the right one matters for both cost and features.

API type	Best for	Auth options	Relative cost	Notes
HTTP API	Simple, low-latency Lambda or HTTP proxying	JWT, IAM, Lambda authorizer	Lowest (~70% cheaper than REST)	Modern default for most serverless APIs
REST API	Rich features: request validation, API keys + usage plans, WAF, edge caching	IAM, Cognito, API keys, Lambda authorizer	Higher	Use only when you need its extra features
WebSocket API	Real-time two-way apps (chat, live dashboards)	IAM, Lambda authorizer	Per-message + connection-minutes	Maintains persistent connections

For a deeper feature-by-feature breakdown, see the dedicated REST vs HTTP comparison page linked below. As a rule of thumb in 2026: start with HTTP API and only move to REST API if you hit a feature it lacks (such as built-in usage-plan API keys or per-method request validation).

The cost and throttle gotcha

This is the trap most teams fall into. API Gateway charges per request, and your account has a default region-wide throttle of 10,000 requests per second with a 5,000-request burst, shared across all your APIs in that region. That account-wide limit is a soft quota you can raise, but it bites at scale.

Gotcha — don’t reach for API Gateway by reflex. If your endpoint is just a thin proxy in front of a single Lambda function, a Lambda Function URL gives you an HTTPS endpoint with no per-request API Gateway charge. For very high, steady traffic, an Application Load Balancer (ALB) invoking Lambda can be far cheaper because you pay roughly by the hour plus capacity units rather than per request. Always check your request-volume economics first.

A concrete cost sketch (us-east-1, 2026 list prices, illustrative):

Volume / month	HTTP API	REST API	Lambda Function URL
1 million requests	~$1.00	~$3.50	$0 (you pay only Lambda)
100 million requests	~$100	~$350	$0 (you pay only Lambda)

Function URLs and ALBs lose the built-in auth, usage plans, and custom request validation — so the savings come with real feature trade-offs. Use them when you genuinely don’t need API Gateway’s features.

Creating a simple HTTP API

Say you have a Lambda function named getOrders (ARN arn:aws:lambda:us-east-1:123456789012:function:getOrders) and you want to expose it at GET /orders.

Using the AWS Management Console

Open the API Gateway console and choose Create API.
Under HTTP API, click Build.
Click Add integration, choose Lambda, and select the getOrders function.
Give the API a name like orders-api and click Next.
On Configure routes, set Method to GET and Resource path to /orders.
On Define stages, keep the default $default stage (it auto-deploys) and click Next, then Create.
Copy the Invoke URL shown — it looks like https://abc123def4.execute-api.us-east-1.amazonaws.com.

Using the AWS CLI

# 1. Create the HTTP API with a Lambda proxy integration in one step
aws apigatewayv2 create-api \
  --name orders-api \
  --protocol-type HTTP \
  --target arn:aws:lambda:us-east-1:123456789012:function:getOrders \
  --route-key "GET /orders"

Output:

{
    "ApiEndpoint": "https://abc123def4.execute-api.us-east-1.amazonaws.com",
    "ApiId": "abc123def4",
    "Name": "orders-api",
    "ProtocolType": "HTTP",
    "RouteSelectionExpression": "$request.method $request.path"
}

You must also let API Gateway invoke the function:

aws lambda add-permission \
  --function-name getOrders \
  --statement-id apigw-invoke \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:us-east-1:123456789012:abc123def4/*/*/orders"

Now test it:

curl https://abc123def4.execute-api.us-east-1.amazonaws.com/orders