AWS API Gateway
This page is a decision brief, not a review. It explains when AWS API Gateway tends to fit, where it usually struggles, and how costs behave as your needs change. Side-by-side comparisons live on separate pages.
Quick signals
What this product actually is
AWS-native managed gateway: fast setup and tight IAM integration for AWS-first orgs, but per-call pricing and lock-in mechanics decide long-term fit.
Pricing behavior (not a price list)
These points describe when users typically pay more, what actions trigger upgrades, and the mechanics of how costs escalate.
Actions that trigger upgrades
- Per-request cost becomes material and you need architectural changes (caching, consolidation)
- You need consistent policy templates across many teams and environments
- You need an enterprise API program model (portals, keys, quotas, governance workflows)
When costs usually spike
- Cost drivers include requests, features used, and environment/gateway sprawl
- Lock-in grows as auth, policies, and routing patterns become AWS-specific
- Cross-account patterns and governance require deliberate standardization
Plans and variants (structural only)
Grouped by type to show structure, not to rank or recommend specific SKUs.
Plans
- Usage-based - Per request - Model expected monthly cost at your target request volume (verify official pricing)
- Managed convenience - AWS integration - Best fit when your APIs live inside AWS and IAM is the default control plane
Costs & limitations
Common limits
- Portability is limited; policies and auth patterns become AWS-coupled
- Pricing can cliff at high request volume (per-call + features + environments)
- Governance and consistency across many teams is hard without a platform program
- Gateway sprawl across accounts/environments can become an operational and cost issue
What breaks first
- Cost predictability as traffic becomes steady and request volume grows
- Consistency across teams (policy drift) without templates and platform enforcement
- Portability when you later need cross-cloud governance or migration
- Gateway sprawl across accounts/environments increases both cost and operational surface area
Fit assessment
Good fit if…
- AWS-first organizations exposing APIs primarily inside AWS
- Teams prioritizing managed convenience and cloud-native integration
- Smaller API programs where governance needs are moderate and speed matters
- Internal APIs where AWS-native identity and networking are already standardized
Poor fit if…
- You must remain portable across clouds/clusters with a consistent policy model
- You expect very high request volume and haven’t modeled per-call pricing and growth
- You need deep enterprise governance processes across many producer teams
Trade-offs
Every design choice has a cost. Here are the explicit trade-offs:
- Managed convenience → more cloud coupling and less portability
- Fast time-to-ship → cost cliffs can appear later
- Native IAM integration → harder to standardize across non-AWS environments
Common alternatives people evaluate next
These are common “next shortlists” — same tier, step-down, step-sideways, or step-up — with a quick reason why.
-
Kong — Step-sideways / portable gatewayPreferred when you need a consistent gateway/policy model across environments and can own operations.
-
Apigee — Step-up / enterprise governance platformChosen when governance depth and external API program needs exceed a managed gateway model.
-
Azure API Management — Same tier / cloud enterprise gatewayComparable option for Azure-first orgs with enterprise policy and portal needs.
-
MuleSoft Anypoint API Manager — Step-up / enterprise program platformChosen when API management is part of a broader integration and governance program.
Sources & verification
Pricing and behavioral information comes from public documentation and structured research. When information is incomplete or volatile, we prefer to say so rather than guess.