AWS History and Timeline regarding Amazon API Gateway - Overview, Functions, Features, Summary of Updates, and Introduction

First Published: 2026-05-16
Last Updated: 2026-05-16

This is an installment in the series that I started with the "AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)", where I extract features from the history and timeline of AWS services (I've previously written about Amazon S3, AWS Systems Manager, Amazon Route 53, Amazon EventBridge, AWS KMS, Amazon SQS, AWS Lambda, Amazon Cognito, Amazon DynamoDB).

This time, I have created a historical timeline for Amazon API Gateway, a fully managed service for creating, publishing, maintaining, monitoring, and securing APIs that was announced as Generally Available on July 9, 2015.
Amazon API Gateway evolved from the original REST API (v1) through Custom Authorizers, Regional and Private endpoint types, WebSocket API for real-time bidirectional communication, the streamlined HTTP API (v2) with JWT authorizers, and a wide range of integration, security, observability, and OpenAPI improvements.
Just like before, I am summarizing the main features while following the birth of Amazon API Gateway and tracking its feature additions and updates as a Current Overview, Functions, Features of Amazon API Gateway.
I hope these will provide clues as to what has remained the same and what has changed, in addition to the features and concepts of Amazon API Gateway.

Background and Method of Creating Amazon API Gateway Historical Timeline

The reason for creating a historical timeline of Amazon API Gateway this time is that it has been more than a decade since the service became generally available in July 2015, and the surface area of API Gateway has grown considerably with the addition of the HTTP API (v2) product line in parallel with the original REST API (v1), the WebSocket API for stateful bidirectional channels, Private API endpoints for VPC-internal use cases, an expanded authorizer ecosystem (Lambda Authorizers, Cognito User Pools, JWT/OIDC), and deeper integration with observability and policy primitives such as AWS X-Ray, access logging, AWS WAF, and resource-based policies.

Since Amazon API Gateway was announced in July 2015, it has steadily expanded its protocol coverage, endpoint topology, authorization story, security controls, and integration surface. Therefore, I wanted to organize the information of Amazon API Gateway with the following approaches.

Tracking the history of Amazon API Gateway and organizing the transition of updates
Summarizing the feature list and characteristics of Amazon API Gateway

This timeline primarily references the following blogs and document content regarding Amazon API Gateway.

There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used.
The content posted is limited to major features related to the current Amazon API Gateway and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to Amazon API Gateway features, but are representative updates that I have picked out.

Amazon API Gateway Historical Timeline (Updates from July 9, 2015)

Now, here is a timeline related to the functions of Amazon API Gateway. As of the time of writing this article, the history of Amazon API Gateway spans more than 10 years since its general availability on July 9, 2015.

* You can sort the table by clicking on the column name.

Date	Summary
2015-07-09	Amazon API Gateway is announced as Generally Available (GA). A fully managed service for creating, publishing, maintaining, monitoring, and securing REST APIs at any scale. At launch the service supported integration with AWS Lambda, HTTP backends, AWS service actions, and Mock integrations, together with built-in caching, throttling, API keys, and Amazon CloudWatch monitoring. References: Amazon API Gateway - Build and Run Scalable Application Backends
2015-09-30	AWS Lambda integration is generalized for Amazon API Gateway. API Gateway can invoke AWS Lambda functions as a backend for any REST API method, enabling fully serverless API designs in which the API tier and the compute tier are both fully managed. References: AWS Compute Blog: Amazon API Gateway
2016-04-05	Swagger 2.0 import and export is announced for Amazon API Gateway. Existing Swagger 2.0 API definitions can be imported as API Gateway REST APIs, and existing APIs can be exported in Swagger 2.0 format, easing migration from on-premises or third-party API platforms. References: Announcing the Swagger Importer Tool for Amazon API Gateway
2016-07-28	Stage variables are announced for Amazon API Gateway. Per-stage configuration values can be referenced from API Gateway integrations and mapping templates, enabling a single API to point to different Lambda aliases, HTTP backends, or parameters per deployment stage. References: Using API Gateway Stage Variables to Manage Lambda Functions
2016-08-11	Custom domain names with Amazon CloudFront-based TLS are announced. Customers can map their own domain names to API Gateway endpoints with an AWS-managed CloudFront distribution as the TLS edge, providing branded API endpoints with a global edge network. References: Amazon API Gateway Now Supports Custom Domain Names
2016-08-25	Usage Plans and API Keys are announced. Usage Plans associate API Keys with quotas (per-day request count) and throttling (rate and burst) per API and stage, supporting tiered API monetization and partner integration scenarios. References: Amazon API Gateway Adds API Usage Plans
2016-09-22	Binary payload support is announced for Amazon API Gateway. API Gateway can pass binary media types (such as `image/*` and `application/octet-stream`) through to Lambda or HTTP backends, broadening the workloads that can be fronted by API Gateway. References: Binary Data Now Supported by API Gateway
2016-11-18	AWS Certificate Manager (ACM) integration for custom domain names is announced. Public TLS certificates issued by AWS Certificate Manager can be attached to API Gateway custom domain names, eliminating manual certificate uploads. References: Amazon API Gateway Now Integrates with AWS Certificate Manager
2017-02-09	Lambda Authorizers (originally Custom Authorizers) become Generally Available. A Lambda function can be designated as the authorizer for an API method, returning an IAM-style policy that allows or denies the caller; this generalizes the bearer-token, OAuth, SAML, and custom-JWT validation pattern to any backend. References: Use AWS Lambda functions as Custom Authorizers in Amazon API Gateway
2017-04-19	Regional API endpoints are announced. In addition to the default Edge-optimized endpoints (fronted by Amazon CloudFront), customers can deploy Regional endpoints to keep traffic inside a single AWS Region and to front the API with their own CloudFront or AWS Global Accelerator distribution. References: Amazon API Gateway Adds Regional API Endpoints
2017-04-27	Request validators are announced for Amazon API Gateway. API Gateway can validate request bodies (against a JSON Schema model), query string parameters, and headers before the request reaches the backend integration, reducing the number of malformed requests that backends must filter. References: Amazon API Gateway Supports Method-Level Request Validation
2017-11-21	Canary release deployments are announced for Amazon API Gateway. A new deployment can be released to a configurable percentage of API stage traffic with separate stage variables and stage settings, so that a small percentage of requests can be served by the new version while the rest continue against the previous one. References: Amazon API Gateway Supports Canary Release Deployments
2017-11-21	API Gateway access logging is announced. Per-request access logs can be written to Amazon CloudWatch Logs in a customer-defined format using the `$context` variables, complementing the existing execution logs and giving operators a structured, low-volume operational log. References: Customize Logging for Amazon API Gateway
2017-11-30	VPC private integrations for REST APIs are announced at AWS re:Invent 2017. Private integrations route REST API traffic to backends running on Amazon EC2, Amazon ECS, or Amazon EKS inside a VPC through an internal Network Load Balancer via a VPC Link, without exposing the backends to the public internet. References: Amazon API Gateway Supports Endpoint Integrations with Private VPCs
2017-12-01	AWS X-Ray integration becomes Generally Available for Amazon API Gateway. API Gateway can be configured to emit AWS X-Ray trace segments for REST API requests, allowing end-to-end latency tracing through the API, Lambda authorizers, and downstream integrations. References: Amazon API Gateway Supports AWS X-Ray
2018-06-26	Private API endpoints are announced. A new endpoint type "PRIVATE" exposes a REST API only through an Interface VPC endpoint (powered by AWS PrivateLink), so the API can be consumed from inside a VPC without traversing the public internet. References: Amazon API Gateway Launches Private Endpoints for APIs
2018-07-03	Resource policies for REST APIs are announced. An API-level resource policy is a JSON policy document attached to an API that allows or denies callers based on the IAM principal, the source AWS account, the source VPC (`aws:SourceVpc`), the source VPC endpoint (`aws:SourceVpce`), the source IP range (`aws:SourceIp`), or the AWS Organizations principal (`aws:PrincipalOrgID`), and is the primary mechanism for restricting Private API access at the API boundary. References: Control Access to Your APIs Using Amazon API Gateway Resource Policies
2018-11-19	Native AWS WAF integration for REST APIs is announced. AWS WAF web ACLs can be associated directly with any REST API endpoint type (Edge-optimized, Regional, or Private), removing the previous workaround of fronting a Regional REST API with a customer-managed Amazon CloudFront distribution to apply WAF rules. The integration supports rate-based rules, managed rule groups, and customer-defined rules covering common web exploits such as SQL injection and cross-site scripting. References: Amazon API Gateway adds support for AWS WAF
2018-12-18	WebSocket APIs are announced for Amazon API Gateway. A new API protocol with stateful bidirectional connections (WSS) is added, enabling real-time use cases such as chat, collaboration, gaming, and streaming notifications. Routes are dispatched by client-supplied route selection expressions, and backends can use AWS Lambda, HTTP, or AWS service integrations. References: Amazon API Gateway Launches Support for WebSocket APIs
2019-12-04	HTTP API (v2) is announced in preview at AWS re:Invent 2019. A streamlined API product is added alongside the REST API: HTTP API offers lower-latency request handling, native JWT authorizers, CORS configuration, automatic deployments, and a simpler feature surface targeted at proxy-style APIs in front of AWS Lambda and HTTP backends. References: Announcing HTTP APIs for Amazon API Gateway
2020-03-25	HTTP API (v2) reaches General Availability. HTTP API GA includes AWS Lambda proxy integrations and VPC Link for private HTTP backends, broadening the backends that HTTP API can front from the start. References: Announcing General Availability of HTTP APIs for Amazon API Gateway
2020-09-02	Mutual TLS (mTLS) authentication is announced for both REST APIs and HTTP APIs. Custom domain names on Regional REST API endpoints and HTTP API endpoints can require client certificates signed by a customer-managed trust store stored in Amazon S3, enabling B2B and IoT scenarios that require strong client identity. References: Amazon API Gateway Now Supports Mutual TLS Authentication
2020-12-14	HTTP API adds direct AWS service integrations. HTTP APIs can call AWS Step Functions, Amazon SQS, Amazon Kinesis Data Streams, Amazon EventBridge, and AWS AppConfig directly from a route without an intermediate Lambda function, reducing latency and operational complexity for event-driven workloads. References: Amazon API Gateway Supports AWS Service Integrations for HTTP APIs
2021-07-28	HTTP APIs add support for AWS Lambda authorizers. HTTP APIs gain custom Lambda-based authorization in addition to the previously available JWT authorizers, narrowing the authorization gap with REST APIs and removing one of the most common reasons to choose REST API over HTTP API. References: Amazon API Gateway now supports AWS Lambda authorizers for HTTP APIs
2022-12-22	Custom domain names for REST APIs gain support for TLS 1.2-only. API Gateway custom domain names can be configured with a security policy that requires TLS 1.2; existing custom domains can be migrated to enforce the stronger minimum, retiring legacy TLS 1.0 / 1.1 client compatibility. References: AWS Documentation(Choosing a minimum TLS version for an API Gateway custom domain name)
2023-04-04	REST API throttling limits become configurable per route and per stage by default at higher ceilings. Account-level throttling defaults (10,000 RPS steady-state, 5,000 burst) remain the same but route- and stage-level throttling enforcement and metrics are improved, making per-route quota design more reliable for multi-tenant API surfaces. The companion AWS Service Quotas integration also exposes API Gateway limits to programmatic quota requests. References: AWS Documentation(Amazon API Gateway quotas and important notes)
2023-11-15	Private custom domain names are announced for REST APIs. Customers can attach a custom domain name to a Private REST API and resolve it through Amazon Route 53 private hosted zones, eliminating the historical requirement to use the execute-api PrivateLink hostname plus a `Host` header workaround when fronting private APIs with friendly names. References: Amazon API Gateway announces private custom domain names
2024-06-04	HTTP API custom domain names add support for mutual TLS with private trust stores in Amazon S3. HTTP API custom domains gain feature parity with REST APIs for mTLS, enabling client certificate authentication for HTTP API workloads without requiring REST API in front for the sole purpose of mTLS. References: AWS Documentation(Configuring mutual TLS authentication for an HTTP API)
2024-12-02	REST API custom domain names announce support for the Amazon CloudFront security policy `TLSv1.2_2021` as the new recommended minimum. The hardened security policy disables a number of legacy ciphers and aligns API Gateway Edge-optimized endpoints with the latest CloudFront viewer protocol defaults. References: AWS Documentation(Choosing a minimum TLS version for an API Gateway custom domain name)
2025-03-31	Dual-stack (IPv4 and IPv6) endpoints are announced for Amazon API Gateway. REST APIs (Edge-optimized, Regional, and Private endpoint types), HTTP APIs, WebSocket APIs, custom domain names, and the API Gateway management APIs can be configured to accept calls from IPv6 clients alongside the existing IPv4 support, with no additional charge. The new `ipAddressType` attribute on APIs and custom domains controls whether the endpoint accepts `ipv4` traffic or `dualstack` traffic. References: API Gateway launches support for dual-stack (IPv4 and IPv6) endpoints
2025-11-21	REST API private integration with Application Load Balancers is announced through VPC link v2. Prior to this update, REST API private integrations only supported Network Load Balancer targets, forcing customers with ALB-fronted workloads to deploy an intermediate NLB. VPC link v2 extends direct ALB targeting (already available for HTTP APIs) to REST APIs, supports one-to-many relationships with multiple load balancers, and allows existing VPC link v1 configurations to be migrated to v2. References: Build scalable REST APIs using Amazon API Gateway private integration with Application Load Balancer

Note: Several dates in the table above are presented at the day or month at which the corresponding feature was prominently announced on the AWS What's New feed or the AWS Compute Blog. For canonical announcement dates, consult the AWS What's New feed and the linked Developer Guide pages directly. Where the precise day is not material to the architecture story, the date column may show the day of the most authoritative announcement.

Current Overview, Functions, Features of Amazon API Gateway

From here, I explain in detail the main features of the current Amazon API Gateway.
Amazon API Gateway is a fully managed service that lets developers create, publish, maintain, monitor, and secure APIs at any scale, with built-in traffic management, authorization and access control, throttling, monitoring, and API version management.

Amazon API Gateway simplifies API operations by removing the undifferentiated heavy lifting of running an API tier (TLS termination, request routing, throttling, caching, observability, authorization, deployment, and versioning), by offering multiple API products optimized for different protocols and feature sets (REST API v1, HTTP API v2, WebSocket API), and by integrating tightly with other AWS services such as AWS Lambda, Amazon Cognito, AWS Identity and Access Management (IAM), AWS WAF, AWS Certificate Manager (ACM), Amazon CloudWatch, AWS X-Ray, AWS PrivateLink, and AWS Step Functions.
It also achieves high security through access management with AWS IAM (SigV4), Lambda Authorizers, Amazon Cognito User Pools authorizers, JWT (OIDC) authorizers, resource-based policies, Mutual TLS authentication, and AWS WAF web ACLs.
Along with these features, it can flexibly scale traffic, version APIs across stages, and emit detailed access and execution logs to Amazon CloudWatch Logs for near real-time operational visibility.

Amazon API Gateway Use Cases

Amazon API Gateway is used in scenarios that need a managed, scalable front door for HTTP and WebSocket APIs.
The main use cases of the API management service provided by Amazon API Gateway include the following:

Serverless application backends
API Gateway pairs with AWS Lambda as the front for serverless web and mobile backends, with built-in throttling, caching, and authorization handled by the API tier rather than by application code.
Public REST APIs with rich governance
REST APIs with Usage Plans, API Keys, Request Validators, AWS WAF, and per-stage canary releases serve as the management plane for public APIs offered to partners or paying customers.
Lightweight HTTP APIs in front of AWS Lambda or HTTP backends
HTTP API (v2) is optimized for lower latency and a leaner feature set, well suited for proxying microservices behind JWT or Lambda authorizers.
Real-time bidirectional applications
WebSocket APIs power chat, collaborative editing, live dashboards, and game state synchronization, with route-based dispatch to AWS Lambda functions or AWS service integrations.
VPC-internal APIs
Private API endpoints expose REST APIs only through Interface VPC endpoints (AWS PrivateLink), supporting internal-only microservices and hybrid integrations where traffic must not cross the public internet.
Service-to-service integration
Direct AWS service integrations route API requests to AWS Step Functions, Amazon SQS, Amazon Kinesis Data Streams, Amazon EventBridge, Amazon DynamoDB, and other AWS services without an intermediate AWS Lambda function.

For a related example of how a serverless API can host the Model Context Protocol behind AWS Lambda, see MCP Server on AWS Lambda Complete Guide.

Amazon API Gateway Type Comparison

From here, I explain the main features and characteristics of Amazon API Gateway. Before that, the following table summarizes the four API products that Amazon API Gateway supports today.

* You can sort the table by clicking on the column name.

Feature	REST API (v1)	HTTP API (v2)	WebSocket API	Private API (REST)
Launch / GA	2015-07	2020-03	2018-12	2018-06
Protocol	HTTPS REST	HTTPS REST (lean)	WSS (bidirectional)	HTTPS REST (VPC only)
Endpoint Types	Edge / Regional / Private	Regional	Regional	Private (Interface VPCE)
Authorizers	IAM / Cognito / Lambda Authorizer	JWT (OIDC) / Lambda / IAM	IAM / Lambda Authorizer	IAM / Cognito / Lambda Authorizer (Resource Policy required)
OpenAPI Import	Swagger 2.0 / OpenAPI 3.0	OpenAPI 3.0	Not supported	Swagger 2.0 / OpenAPI 3.0
Best For	Public REST APIs with rich features	Lightweight REST / JWT APIs	Real-time apps (chat / streaming)	VPC-internal workloads

This table lists, for each of the four API products, the launch year, the wire protocol, the endpoint types available, the authorizers available, OpenAPI / Swagger import support, and the recommended use case. The REST API (v1) is the most feature-rich product and is the only product that supports Private endpoints; HTTP API (v2) is a leaner, lower-latency product targeted at proxy-style APIs; WebSocket API enables stateful bidirectional channels; and Private API is the REST API deployed as the "PRIVATE" endpoint type.

In the following sections, I provide more details about these features and configurations of Amazon API Gateway.

REST API (v1)

The REST API (v1) product, generally available since July 2015, is the original Amazon API Gateway product and remains the most feature-rich. REST APIs offer:

All three endpoint types: Edge-optimized (default, fronted by Amazon CloudFront), Regional (announced in April 2017), and Private (announced in June 2018, exposed only through Interface VPC endpoints).
All authorizer types: IAM (SigV4), Lambda Authorizers (GA in February 2017), and Amazon Cognito User Pools authorizers.
Request Validators (announced in April 2017) for declarative request body, query string, and header validation using JSON Schema models.
Velocity Template Language (VTL) mapping templates that reshape requests and responses between clients and integrations.
Usage Plans and API Keys (announced in August 2016) for tiered rate and quota management.
API Gateway response caching at the stage level for selected methods.
Canary release deployments (announced in November 2017) for percentage-based traffic shifting between deployments.
Mutual TLS authentication (announced in 2020) for client-certificate-based identity.
AWS WAF integration for application-layer protection.

REST APIs are best suited for public APIs that require rich governance (API keys, usage plans, fine-grained throttling), for APIs that need request validation in front of the backend, and for any scenario that needs the Private endpoint type.

For OpenAPI definitions destined for import into a REST API, see the client-side OpenAPI API Gateway Import Linter Tool, which validates Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1 documents against API Gateway-specific import rules.

HTTP API (v2)

The HTTP API (v2) product, generally available since March 2020 (announced in preview at AWS re:Invent in December 2019), is a streamlined offering that focuses on the most common API patterns: proxying HTTP requests to AWS Lambda functions or HTTP backends, with JWT (OIDC) or Lambda authorizers in front.

Compared to REST API, HTTP API:

Has lower request latency and a leaner internal pipeline.
Supports JWT authorizers natively (no Lambda function needed) for any OIDC-compatible identity provider, including Amazon Cognito User Pools.
Supports Lambda authorizers (both request-based and token-based) and IAM authorization (SigV4).
Supports AWS Lambda proxy integration, HTTP proxy integration, HTTP private integration via VPC Link, and direct AWS service integrations (to AWS Step Functions, Amazon SQS, Amazon Kinesis Data Streams, Amazon EventBridge, and others).
Supports CORS configuration as a first-class concept on the API.
Supports automatic deployments to stages.
Supports custom domain names, ACM certificates, and Mutual TLS authentication.

HTTP API intentionally omits some REST API features: it does not support API Gateway-built-in Request Validators, API Keys and Usage Plans, per-stage caching, VTL mapping templates, Edge-optimized endpoints, or Private endpoints. Customers who need these features should remain on REST API.

HTTP API is best suited for microservice APIs behind a JWT identity provider, for serverless API proxies in front of AWS Lambda, and for migration off REST APIs where the application does not depend on REST-API-only features.

WebSocket API

The WebSocket API product, generally available since December 2018, exposes a stateful WebSocket connection (wss://) to clients. API Gateway dispatches incoming messages to backend integrations based on a route selection expression evaluated against the inbound JSON message, and provides a server-side @connections API for backends to push messages to specific connections.

Routes include the built-in $connect, $disconnect, and $default lifecycle routes, plus any application-defined routes. Backends can be AWS Lambda functions, HTTP endpoints, or AWS service integrations, and the same connection can be associated with backend state held in Amazon DynamoDB or another store.

WebSocket APIs are best suited for real-time chat, collaborative editing, live dashboards, multiplayer game state, and any other scenario that requires server-pushed updates over a single long-lived bidirectional connection.

Private API

A Private API is a REST API deployed as the PRIVATE endpoint type (announced in June 2018). The API is reachable only through an Interface VPC endpoint (powered by AWS PrivateLink) that resolves to private IP addresses inside the consuming VPC. The API's resource policy controls which VPCs, VPC endpoints, or AWS accounts can invoke it.

Private APIs unlock several internal-only patterns:

API access from inside a VPC without traversing the public internet.
Cross-account API exposure inside a private network through a shared Interface VPC endpoint.
Hybrid scenarios where on-premises workloads reach the API through AWS Direct Connect or AWS Site-to-Site VPN combined with VPC endpoint DNS.

Private APIs inherit all of the REST API feature set (authorizers, request validators, VTL mapping templates, canary releases, caching, and so on), except that they cannot be Edge-optimized.

Integration Types

Amazon API Gateway supports several integration types between an API method (REST or HTTP API) or route (WebSocket API) and a backend:

AWS Lambda (proxy) — The full request (HTTP headers, body, query string) is forwarded to a Lambda function as a single JSON event, and the Lambda response (status code, headers, body) is returned to the caller.
AWS Lambda (non-proxy / custom) — A VTL request mapping template transforms the request, the Lambda is invoked, and a VTL response mapping template transforms the response (REST API only).
HTTP / HTTP proxy — Forwards requests to an HTTP backend over the public internet.
HTTP private integration via VPC Link — Forwards requests to a private HTTP backend inside a VPC, via an internal Network Load Balancer (REST API) or via a private Application Load Balancer, Network Load Balancer, or AWS Cloud Map service (HTTP API).
AWS service integration — Calls an AWS service action (such as Amazon S3 PutObject, AWS Step Functions StartExecution, Amazon SQS SendMessage, or Amazon Kinesis PutRecord) without an intermediate Lambda function.
Mock integration — Returns a fixed response defined in the API itself, useful for CORS preflight responses, contract testing, and stubbing partially implemented APIs (REST API only).

Authentication and Authorization

Amazon API Gateway supports several authorization mechanisms:

AWS Identity and Access Management (IAM / SigV4) — Clients sign requests with SigV4 using IAM credentials; API Gateway evaluates the caller's identity-based and resource-based IAM policies. Supported on REST API, HTTP API, and WebSocket API.
Lambda Authorizer — A Lambda function returns an IAM policy that allows or denies the caller, optionally with a context object that downstream integrations can read. Supported on REST API, HTTP API, and WebSocket API.
Amazon Cognito User Pools authorizer — REST APIs can directly accept Amazon Cognito User Pool ID tokens (REST API only; HTTP API uses the more general JWT authorizer).
JWT (OIDC) authorizer — HTTP API natively validates JWTs from any OIDC-compatible identity provider, including Amazon Cognito User Pools.
API Keys with Usage Plans — API Keys are not an authentication mechanism on their own; they are commonly combined with another authorizer to enforce per-key rate and quota limits (REST API only).
Mutual TLS (mTLS) — REST APIs and HTTP APIs can require client certificates signed by a customer-managed trust store in Amazon S3.
Resource-based policies — REST APIs can attach a resource-based policy that allows or denies callers by source VPC, source IP, source AWS account, or AWS PrincipalOrgID.

Caching and Throttling

API Gateway provides two complementary mechanisms for protecting backends from traffic surges:

Throttling — Both REST API and HTTP API enforce account-level throttling (a default 10,000 requests per second per Region with a 5,000-request burst by default, raisable by request) and allow per-stage and per-method throttling on REST API. Usage Plans on REST API let API Keys be throttled independently.
Caching (REST API only) — REST APIs can enable a per-stage API Gateway cache for GET methods, with configurable cache size, TTL, and per-method cache key composition. Cache invalidation can be exposed to clients via an Authorization header that includes the InvalidateCache permission.

HTTP API does not include a built-in cache; customers that need caching in front of HTTP API typically front the API with Amazon CloudFront.

Stages, Deployments, and Canary Releases

A deployment is an immutable snapshot of the API definition. A stage is a named reference to a specific deployment, such as dev, test, and prod. Stage variables (announced in July 2016) let the same API definition point to different backends per stage without changing the deployment.

Canary release deployments (announced in November 2017) allow a new deployment to receive a configurable percentage of traffic on a stage, while the rest continues to flow to the previous deployment. The canary has its own stage variables and stage settings, so an operator can validate the new deployment under live traffic before promoting it to 100%.

HTTP API supports automatic deployments, where any change to the API definition automatically creates a new deployment on a designated stage; this is the default and recommended pattern for many HTTP API use cases.

Mapping Templates and VTL (REST API)

REST API supports mapping templates written in Velocity Template Language (VTL) that transform requests and responses between clients and integrations. A mapping template has access to the request body (as $input.body and $input.json('$.path')), headers, path parameters, query string, stage variables, and the $context object (which exposes the API ID, stage, request ID, authorizer principal, and other request metadata).

VTL mapping templates make non-proxy integrations (where the backend signature differs from the public API signature) practical, and they remain the standard way to call AWS service integrations from REST API.

For interactive testing of API Gateway mapping templates without invoking the live API, see the client-side VTL Template Tester Tool, which evaluates a subset of Apache Velocity together with API Gateway's $input, $context, and $stageVariables and AWS AppSync's $ctx and $util namespaces.

OpenAPI Import and Export

Amazon API Gateway supports OpenAPI as the canonical interchange format for API definitions:

REST API supports Swagger 2.0 and OpenAPI 3.0 for both import and export, with API Gateway-specific extensions (x-amazon-apigateway-integration, x-amazon-apigateway-authorizer, x-amazon-apigateway-request-validator, x-amazon-apigateway-binary-media-types, x-amazon-apigateway-cors, x-amazon-apigateway-gateway-responses, and x-amazon-apigateway-api-key-source).
HTTP API supports OpenAPI 3.0 import and export, with a more compact extension set tuned to HTTP API's feature surface.
WebSocket API does not support OpenAPI import.

For pre-import validation of OpenAPI documents against API Gateway-specific compatibility rules (REST v1 versus HTTP v2), use the OpenAPI API Gateway Import Linter Tool.

Monitoring, Logging, and Tracing

API Gateway integrates with the AWS observability stack:

Amazon CloudWatch metrics — Per-API and per-stage metrics for request count, latency (with 4XX and 5XX errors broken out separately), integration latency, cache hits and misses (REST API), and connection counts (WebSocket API).
Amazon CloudWatch Logs (execution logging) — Per-request execution logs containing the integration request and response, authorizer decisions, and mapping template evaluations.
Amazon CloudWatch Logs (access logging) — Per-request access logs in a customer-defined format using $context variables (announced in November 2017 for REST API, since extended to HTTP API).
AWS X-Ray tracing — End-to-end traces of REST API and HTTP API requests, including authorizer execution and downstream integrations, when AWS X-Ray is enabled on the stage.

Custom Domain Names, Certificates, and AWS WAF

API Gateway endpoints can be exposed under customer-owned domain names with the following options:

Edge-optimized custom domains use an AWS-managed Amazon CloudFront distribution as the TLS edge; certificates must be issued by AWS Certificate Manager (ACM) in us-east-1.
Regional custom domains terminate TLS in the API's home Region; certificates must be issued by AWS Certificate Manager in the same Region.
Private custom domains (for Private APIs) terminate TLS inside the Interface VPC endpoint.

Public APIs can be associated with an AWS WAF web ACL that filters incoming requests by IP set, geographic origin, rate limit, managed rule groups, and customer-defined rules. REST API has had AWS WAF support for several years; HTTP API customers often place an Amazon CloudFront distribution with AWS WAF in front.

Best Practices

A few recurring best practices for Amazon API Gateway in production:

Pick the right product for each API. Start a new public API on REST API if any of API Keys, Usage Plans, Request Validators, Edge-optimized endpoints, or Private endpoints are needed; otherwise prefer HTTP API for lower latency and a simpler operational model.
Use stage variables for environment-specific configuration, not separate API definitions per environment.
Always enable access logging with a structured format that includes the API ID, stage, request ID, source IP, user agent, status, and integration latency, so that production issues can be triaged from logs alone.
Enable AWS X-Ray on all stages, at least at a sampling rate that is non-zero, so that latency budgets across API, authorizer, and integration can be diagnosed in production.
Always set a reasonable per-method throttle in addition to the account-level throttle, to prevent a single misbehaving caller from exhausting the global concurrency budget.
Lint and validate the OpenAPI definition before importing with the OpenAPI API Gateway Import Linter Tool, so that import failures are caught locally instead of in the deployment pipeline.
Treat resource policies as a security boundary, not as application logic; deny by default and allow only the source AWS accounts, source VPCs, or source IP ranges that you intend.
For VTL mapping templates, keep transformations small and well-tested with a local test harness such as the VTL Template Tester Tool before deploying.

Frequently Asked Questions (FAQ)

When did Amazon API Gateway launch?

Amazon API Gateway was announced as Generally Available on July 9, 2015 as a fully managed service for creating, publishing, maintaining, monitoring, and securing REST APIs at any scale. At launch the service supported integration with AWS Lambda, HTTP backends, AWS service actions, and Mock integrations, together with built-in caching, throttling, API keys, and Amazon CloudWatch monitoring. (Reference: Amazon API Gateway - Build and Run Scalable Application Backends.)

When did API Gateway support Edge-optimized, Regional, and Private endpoints?

Edge-optimized endpoints were the default at REST API launch in July 2015 (fronted by an AWS-managed Amazon CloudFront distribution). Regional endpoints were announced in April 2017, keeping traffic inside a single AWS Region and letting customers front the API with their own CloudFront distribution or AWS Global Accelerator. Private endpoints (the "PRIVATE" endpoint type) were announced in June 2018 and expose a REST API only through Interface VPC endpoints powered by AWS PrivateLink. (Reference: Amazon API Gateway Adds Regional API Endpoints, Amazon API Gateway Launches Private Endpoints for APIs.)

When did HTTP API (v2) launch and how does it differ from REST API?

HTTP API (v2) was first announced in preview at AWS re:Invent on December 4, 2019 and reached General Availability on March 25, 2020. Compared to REST API, HTTP API has lower request latency, native JWT (OIDC) authorizers, first-class CORS configuration, automatic deployments, and direct AWS service integrations to AWS Step Functions, Amazon SQS, Amazon Kinesis Data Streams, Amazon EventBridge, and other AWS services. HTTP API does not support API Gateway-built-in Request Validators, API Keys and Usage Plans, per-stage caching, VTL mapping templates, Edge-optimized endpoints, or Private endpoints; customers who need these features should remain on REST API. (Reference: Announcing General Availability of HTTP APIs for Amazon API Gateway, Choosing between REST APIs and HTTP APIs.)

When did WebSocket API launch?

WebSocket API was announced on December 18, 2018 as a new API protocol that exposes a stateful WebSocket connection (wss://) to clients. API Gateway dispatches incoming messages to backend integrations using a route selection expression and provides a server-side @connections API so that backends can push messages back to specific connections. WebSocket API supports AWS Lambda, HTTP, and AWS service integrations. (Reference: Amazon API Gateway Launches Support for WebSocket APIs.)

When did Lambda Authorizer launch?

Lambda Authorizers (originally called "Custom Authorizers") became Generally Available on February 9, 2017. A Lambda function designated as an authorizer receives the incoming token or request context and returns an IAM-style policy document that allows or denies the caller, optionally with a context object that downstream integrations can read. (Reference: Use AWS Lambda functions as Custom Authorizers in Amazon API Gateway.)

When did SigV4 / IAM authentication become available for API Gateway?

AWS IAM (SigV4) authentication has been available since the REST API product launched in July 2015. Clients sign requests with SigV4 using IAM credentials, and API Gateway evaluates the caller's identity-based and resource-based IAM policies. IAM authentication is available on REST API, HTTP API, and WebSocket API. (Reference: Controlling access to a REST API.)

When did API Gateway support gRPC?

Amazon API Gateway does not provide a managed gRPC endpoint type today. The native API products are REST API (v1), HTTP API (v2), and WebSocket API. For gRPC traffic, customers typically expose gRPC services behind an Application Load Balancer (which supports HTTP/2 and gRPC), behind AWS App Runner, or behind a self-hosted ingress, rather than through Amazon API Gateway. Customers who need a REST front for a gRPC backend often place an API Gateway HTTP API or REST API with a Lambda function (or an HTTP private integration via VPC Link) that calls the gRPC service. (Reference: Application Load Balancer protocol versions.)

When did Caching and Throttling become available?

Throttling and caching have both been available since the REST API launched in July 2015. Throttling has account-level limits (a default 10,000 requests per second per Region with a 5,000-request burst by default, raisable on request) and per-stage and per-method overrides; Usage Plans (announced in August 2016) extended throttling and quotas to per-API Key. API Gateway caching (REST API only) is enabled per stage with a configurable cache size and TTL, and per-method cache key composition; cache invalidation can be exposed to clients via the Authorization header. HTTP API does not include a built-in cache; customers typically front HTTP APIs with Amazon CloudFront when caching is required. (Reference: Throttle API requests for better throughput, Enabling API caching to enhance responsiveness.)

References:
Tech Blog with curated related content
MCP Server on AWS Lambda Complete Guide
OpenAPI API Gateway Import Linter Tool
VTL Template Tester Tool
AWS History and Timeline regarding AWS Lambda
AWS History and Timeline regarding Amazon DynamoDB
AWS History and Timeline regarding Amazon S3
AWS History and Timeline regarding AWS Systems Manager
AWS History and Timeline regarding Amazon Route 53
AWS History and Timeline regarding Amazon EventBridge
AWS History and Timeline regarding AWS KMS
AWS History and Timeline regarding Amazon SQS
AWS History and Timeline regarding Amazon Cognito
AWS Documentation (Amazon API Gateway)
What's New with AWS? (Amazon API Gateway)

Summary

In this article, I created a historical timeline of Amazon API Gateway and looked at the list of features and overview of Amazon API Gateway.

Amazon API Gateway, a fully managed API management service, was announced as Generally Available on July 9, 2015, and has since expanded with Lambda Authorizers, Regional and Private endpoint types, WebSocket API, the streamlined HTTP API (v2), Mutual TLS, JWT authorizers, expanded AWS service integrations, and continued observability and security improvements.
More than 10 years after GA, Amazon API Gateway continues to provide the foundational API tier behind serverless backends, public partner APIs, real-time applications, and VPC-internal microservices, while steadily extending its protocol coverage, authorization, and integration surface.

I would like to continue monitoring the trends of what kind of features Amazon API Gateway will provide in the future.

In addition, there is also a historical timeline of all AWS services including services other than Amazon API Gateway, so please have a look if you are interested.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)

Written by Hidekazu Konishi