AWS API Gateway

When you build something on the web — a mobile app, a website, a service that talks to another service — there is usually a point where one thing needs to ask another thing for data or trigger some action. That request has to go somewhere, and the piece of infrastructure that sits in the middle and handles it is called an API. AWS API Gateway is Amazon's managed service for creating, deploying, and running those APIs without having to manage the underlying server infrastructure yourself.

The simplest way to think about it: API Gateway is a front door. Someone sends an HTTP request — a browser loading a page, a mobile app fetching user data, an automated script running a task — and API Gateway receives it, decides what to do with it, and routes it to the right place. That place might be a Lambda function, an EC2 instance, another AWS service, or even an external HTTP endpoint. API Gateway does not run your business logic; it connects the request to whatever does.

There are three types of API Gateway you will encounter. REST APIs are the most feature-rich option and the one most people start with; they give you fine-grained control over request and response transformations, authorization, caching, and more. HTTP APIs are a newer, lighter alternative that strips out some of the advanced features in exchange for lower latency and lower cost — a good fit for simple Lambda-backed APIs. WebSocket APIs are built for real-time two-way communication, like a chat application or a live dashboard that needs to push updates to the client without the client having to keep asking.

For the vast majority of projects, you will be choosing between REST and HTTP APIs. The decision usually comes down to whether you need the extra control that REST APIs provide or whether you just want something fast and cheap to route requests to Lambda.

Using API Gateway typically starts in the AWS Management Console. Once you navigate to the API Gateway section, you create a new API, pick the type (REST, HTTP, or WebSocket), give it a name, and from there you start defining routes. A route is essentially a combination of an HTTP method and a path — something like GET /users or POST /orders — and each route gets connected to an integration, which is the thing that actually handles the request.

The most common integration by far is AWS Lambda. You write a function in Lambda that contains your logic, then you tell API Gateway to forward requests on a given route to that function. When a request comes in, API Gateway packages it up and hands it to Lambda, which runs your code and returns a response, which API Gateway then sends back to the caller. This pattern is sometimes called a serverless API because there is no server you are managing — you just write code and wire it up.

Beyond the basics, API Gateway has a few features that come up regularly in real projects. Authorization is one of them. You can protect routes using IAM permissions, Lambda authorizers (custom functions that check a token or cookie and decide whether to allow the request), or Cognito user pools if you are using Amazon's authentication service. Without some form of authorization on sensitive routes, anyone with the URL can call your API.

Stages are another concept worth understanding early. When you deploy an API in API Gateway, you deploy it to a stage — typically something like "dev", "staging", or "prod". Each stage gets its own URL and can have its own settings, including throttling limits and logging configuration. This lets you test changes on a dev stage without affecting the production version that real users are hitting.

Throttling is the last thing that catches people off guard. By default, API Gateway will handle a large volume of requests, but you can — and usually should — set limits. You can control how many requests per second your API allows (the rate limit) and how large a burst of simultaneous requests it will absorb. Setting these prevents a spike in traffic, or a mistake in your own code, from triggering thousands of Lambda invocations and generating an unexpected bill.

AWS API Gateway Getting Started: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started.html

API Gateway pricing is not complicated, but there are enough moving parts that it is worth going through carefully. The cost depends on which type of API you are using, how many requests come in, and how much data goes out. There is no flat monthly fee — you pay for what you use.

For REST APIs, the price in most regions sits around $3.50 per million API calls received. On top of that, you pay for data transfer out — roughly $0.09 per GB depending on region. If you use caching, there is an additional hourly charge based on the cache size you select, starting at a few cents per hour for the smallest option. These costs add up if you have a busy API, but for a project handling tens of thousands of requests per month rather than millions, the bill is typically small.

HTTP APIs are cheaper. The rate is around $1.00 per million requests for the first 300 million, dropping further at higher volumes. If your project does not need the advanced features of REST APIs, HTTP APIs are usually the better financial choice. The tradeoff is fewer built-in options for things like response caching and detailed usage plans.

WebSocket APIs are billed differently — you pay per million messages sent and received, and also per million connection minutes, which is the total time all active connections have been open. For most applications the connection cost is negligible, but for a service with thousands of long-lived open connections it becomes relevant.

The free tier includes one million API calls per month for REST APIs and one million calls per month for HTTP APIs, both for the first twelve months of your account. This is usually enough to get a personal project running, do all your testing, and reach a real launch without spending anything. After the free tier expires, REST APIs in particular can get expensive at scale, which is why many developers switch to HTTP APIs once they understand the feature differences.

One thing that does not get mentioned enough: API Gateway costs are only part of the picture. Every request that reaches Lambda from API Gateway triggers a Lambda invocation, which has its own pricing. And if your Lambda function calls other AWS services — writing to DynamoDB, reading from S3, sending a message to SQS — those services charge their own fees too. Billing in AWS is rarely a single line item. Getting into the habit of checking the full cost of a request end-to-end, not just what API Gateway charges, saves a lot of surprises later.

Full pricing details: https://aws.amazon.com/api-gateway/pricing/

API Gateway is one of those services that sounds more complicated than it is once you have actually used it a few times. At its core, it takes an incoming HTTP request, figures out where it should go, sends it there, and returns whatever comes back. The complexity comes not from the concept but from the configuration — routes, integrations, stages, authorization, throttling — and the fact that it connects to a lot of other AWS services, each with their own behavior.

If you are building something serverless, meaning Lambda-based without dedicated servers, API Gateway is almost certainly part of your stack. It is the standard way to give a Lambda function a public HTTP endpoint, and the combination of the two is reliable, scalable, and reasonably cheap for projects that are not handling tens of millions of requests per month.

The choice between REST and HTTP APIs is worth making deliberately rather than just defaulting to REST because it is the more familiar name. HTTP APIs are faster to set up, cost less, and are genuinely sufficient for most use cases. If you need request validation, response transformations, usage plans, or API keys for third-party developers, then REST APIs earn their complexity. If you just need to route a POST request to a Lambda function and get a response back, HTTP APIs do that cleanly at lower cost.

On the security side, never leave routes open without some form of authentication if they do anything sensitive — read data, write data, trigger processes. Lambda authorizers are flexible and worth learning early. Stages give you a clean way to separate development from production. And throttling limits are cheap insurance against runaway costs caused by traffic spikes or bugs in client code that loop endlessly.

Pricing is usage-based and broadly predictable, with a free tier that covers most personal projects through the first year. The main thing to keep in mind is that API Gateway costs are just one part of the total cost of a request — Lambda, DynamoDB, and any other services your function calls all add their own charges. Building a rough cost estimate for a full request path before you launch is a habit that pays off quickly.

At this point you have a working understanding of what API Gateway is, how to set it up, what it costs, and what to watch out for. The best way to solidify that understanding is to build something with it — even a simple API that takes a request, runs a Lambda function, and returns a response will teach you more than any amount of reading.