An API gateway sits at the edge of your services, handling cross-cutting concerns that would otherwise be duplicated across every API: authentication, rate limiting, request routing, SSL termination, logging, and transformation. The choice of gateway shapes your API architecture for years—and switching later is painful.
Kong, AWS API Gateway, and Apigee represent three distinct models: open-source infrastructure you operate, a managed AWS service, and an enterprise API management platform. They’re not interchangeable.
What API Gateways Actually Do
Before comparing products, it’s worth being precise about scope. An API gateway is not a load balancer (though it routes traffic), not a service mesh (though it handles inter-service concerns), and not an API management platform (though some gateways include management capabilities).
Core gateway functions:
- Traffic routing: Route requests to the appropriate upstream service based on path, method, headers, or other criteria
- Authentication/authorization: Validate API keys, JWTs, OAuth tokens, or mTLS certificates before passing requests to services
- Rate limiting: Throttle consumers to prevent abuse or protect upstream capacity
- Request/response transformation: Modify headers, rewrite paths, transform payloads
- Observability: Log requests, emit metrics, generate traces
API management adds: developer portals, API versioning governance, monetization, consumer analytics, lifecycle management. Some gateways include these; others don’t.
Kong Gateway
Kong is an open-source API gateway built on Nginx and OpenResty (LuaJIT). It’s the most widely deployed self-managed gateway, used by organizations that need flexibility, Kubernetes integration, or don’t want to be tied to a cloud provider.
Architecture: Kong runs as a proxy process backed by PostgreSQL (or a DBless declarative config). In Kubernetes, Kong Ingress Controller manages routing via Ingress and Gateway API resources. The plugin system (Lua, Go, Python plugins) extends every aspect of request handling.
Plugin ecosystem: 150+ plugins cover authentication (JWT, OAuth 2.0, LDAP, OIDC, API key, mTLS), rate limiting (fixed window, sliding window, token bucket), traffic control (request size limiting, response caching, circuit breaking), transformations, logging (HTTP log, file log, Datadog, Splunk, Kafka), and observability. Custom plugins can be written in Lua or Go.
Kong’s strengths:
- Deep Kubernetes integration via Kong Ingress Controller and Gateway API support
- Plugin flexibility covers most requirements without custom code
- Runs anywhere: Kubernetes, bare metal, VMs, any cloud
- Active open-source community; Kong Inc. provides the commercial Kong Gateway Enterprise
- Declarative configuration (deck) enables GitOps workflows
Kong’s trade-offs:
- You operate it: HA deployment, database, upgrades, scaling
- Lua plugin development has a learning curve for teams not familiar with it
- Rate limiting at scale requires Redis for distributed state
- Kong Gateway Enterprise (with RBAC, developer portal, FIPS) is commercial
AWS API Gateway
AWS API Gateway is a fully managed service in two variants:
REST API: The original, more feature-rich variant. Supports request/response transformation with Velocity templates, request validation, usage plans, API keys, and direct service integrations (invoke Lambda, Step Functions, DynamoDB, SQS directly—without a compute layer in between).
HTTP API: The newer, simpler, cheaper variant (~70% cheaper than REST API). Supports JWT authorization, Lambda proxy integration, VPC links, and basic routing. Doesn’t support request transformation, usage plans, or direct service integrations.
AWS API Gateway’s strengths:
- Zero infrastructure to operate—fully managed, auto-scaling
- Native Lambda integration: a Lambda function behind API Gateway is the fastest path from code to HTTPS endpoint
- AWS IAM integration for authorization
- Built-in usage plans and API keys for consumer management
- Tight integration with CloudFront, WAF, Cognito, and other AWS services
AWS API Gateway’s trade-offs:
- Tied to AWS—migrating away is a meaningful effort
- Limited extensibility compared to Kong: no plugin system, transformation logic is Velocity templates (REST) or Lambda authorizers (HTTP)
- Per-request pricing ($1–3.50/million requests) becomes significant at high volume
- 29MB response payload limit
- HTTP API’s limitations (no transformation, no usage plans) often push teams to REST API, which is more expensive and complex
Best fit: Services that are Lambda-native or deeply embedded in the AWS ecosystem. If your API surfaces Lambda functions with standard auth and minimal transformation needs, AWS API Gateway is the lowest-friction option.
Apigee
Apigee (now Google Cloud Apigee) is an enterprise API management platform—a superset of what Kong and AWS API Gateway do, with a full developer portal, API analytics, monetization, and lifecycle management built in.
Architecture: Apigee runs as a managed service on Google Cloud (Apigee X) or in a hybrid model with the data plane on your infrastructure (Apigee hybrid). Policies (XML-based) handle request/response transformation, authentication, rate limiting, and traffic management. The management plane provides API versioning, developer onboarding, app registration, and analytics.
Apigee’s strengths:
- The most complete API management platform: developer portal, API catalog, consumer analytics, monetization out of the box
- Sophisticated policies for transformation, mediation, and security without custom code
- Strong support for API product management (bundling APIs into products, managing consumer access)
- Hybrid deployment model for organizations with data residency requirements
- Enterprise support, SLA, and professional services
Apigee’s trade-offs:
- Enterprise pricing ($2,500+/month minimum; large deployments run $100k+/year)—not a developer tool
- XML policy language is verbose and has a learning curve
- Google Cloud dependency for Apigee X; hybrid reduces this but adds operational complexity
- Significant platform to learn: developer portal, environments, API products, organizations
- Overkill for teams that need routing and auth, not a full API management lifecycle
Best fit: Large enterprises exposing APIs to external partners and developers, where API products, developer self-service, consumer analytics, and monetization are actual requirements—not just routing and auth.
When to Use Each
Choose Kong if:
- You want to self-manage your gateway with maximum flexibility
- You’re on Kubernetes and want native Kubernetes-aware routing
- You’re multi-cloud or cloud-agnostic
- You need custom plugins or deep extensibility
- Cost at high volume is a concern (Kong’s compute cost is more predictable than per-request pricing)
Choose AWS API Gateway (HTTP API) if:
- Your backends are Lambda functions
- You’re fully committed to AWS
- You want zero gateway infrastructure to manage
- Traffic volume is moderate (under ~100M requests/month where per-request pricing is manageable)
Choose AWS API Gateway (REST API) if:
- You need direct AWS service integrations (Lambda, Step Functions, DynamoDB without a compute layer)
- Usage plans and API key management matter
- Request validation and transformation via Velocity templates is sufficient
Choose Apigee if:
- You’re managing APIs as products for external developers or partners
- Developer portal, API catalog, and consumer analytics are genuine requirements
- Your organization has the budget and the need for enterprise API management
- You’re on Google Cloud and want native integration
The Hidden Option: Ingress Controller as Gateway
For Kubernetes deployments, the line between ingress controller and API gateway has blurred. Kong Ingress Controller, Nginx Ingress, Traefik, and Envoy-based options (Emissary, Contour) can handle most gateway requirements with a simpler operational model than a standalone gateway deployment.
If your needs are primarily routing, TLS termination, and basic auth—and you’re on Kubernetes—evaluate whether your ingress controller already covers the requirement before adding a dedicated gateway layer.