API Gateway — REST vs HTTP APIs, caching, throttling and plans

API Gateway is the managed API front door for Lambda functions and HTTP backends on AWS. It handles authentication, throttling, caching, request transformation, and usage metering so these concerns do not need to be reimplemented in every Lambda function. Understanding the two current API types — REST API and HTTP API — is essential because they have different feature sets, pricing models, and performance characteristics, and the wrong choice adds cost or limits capability in ways that become painful to change post-launch.

REST API is the original, feature-rich type supporting request and response transformations, API key-based usage plans, per-method caching, AWS service proxy integrations without Lambda, and resource policies for IP-based access control. HTTP API is the newer, streamlined type with lower latency, lower cost at approximately 70% less than REST API, native JWT authoriser support, and automatic CORS configuration, but without caching, usage plans, or AWS service proxy integrations.

Throttling and usage plans govern how API Gateway protects backends from overload and how operators monetise or meter API access. Stage-level throttling sets a default rate limit and burst limit for all methods in a deployment stage. Usage plans attach to API keys and apply per-API-key rate and quota limits, enabling differentiated access tiers for external API consumers. These controls collectively make API Gateway the traffic management layer that prevents a single client from overwhelming a serverless backend.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.