Loading learning content...
Having explored Kong, AWS API Gateway, Ambassador, and Envoy in depth, you've seen that each solution embodies different architectural philosophies and trade-offs. There is no universally "best" API Gateway—only the best gateway for your specific context.
This page provides a structured decision framework to guide gateway selection. We'll examine dimensions of comparison, common scenarios with recommended solutions, mistakes to avoid, and a practical evaluation methodology.
By the end of this page, you will have a structured framework for evaluating gateway solutions, understand which solutions fit common scenarios, know what questions to ask stakeholders, and be equipped to make defensible gateway decisions.
Gateway selection should evaluate multiple dimensions. No single dimension should dominate—consider the holistic picture.
| Dimension | Key Questions | Impact |
|---|---|---|
| Infrastructure | Kubernetes? AWS-native? Multi-cloud? On-prem? | Determines viable options |
| Operational Model | Self-managed? Managed service? GitOps? | Affects Total Cost of Ownership |
| Scale Requirements | Requests/second? Concurrent connections? Global reach? | Eliminates unsuitable options |
| Protocol Needs | HTTP only? gRPC? WebSocket? GraphQL? TCP? | Filters by capability |
| Extensibility | Custom plugins needed? Standard features sufficient? | Open-source vs. managed trade-off |
| Team Expertise | What does the team know? Learning budget? | Affects time-to-production |
| Budget | CapEx vs. OpEx preference? License costs acceptable? | Commercial vs. OSS decision |
| Compliance | Data residency? Audit requirements? Certifications? | May mandate specific solutions |
Infrastructure is typically the strongest filter. Your existing infrastructure often narrows choices significantly:
Fighting your infrastructure's grain creates operational burden. If your organization is all-in on AWS and Lambda, deploying self-hosted Kong adds complexity without proportional benefit. Conversely, if you're multi-cloud by design, managed cloud gateways create lock-in.
| Capability | Kong OSS | Kong Enterprise | AWS API GW | Ambassador | Envoy Direct |
|---|---|---|---|---|---|
| Deployment Model | Self-hosted | Self-hosted | Managed | Self-hosted (K8s) | Self-hosted |
| Primary Config | Admin API/DB-less | Admin API/UI | Console/IaC | K8s CRDs | YAML/xDS |
| Learning Curve | Medium | Medium | Low (AWS users) | Medium | High |
| Extensibility | Lua plugins | Lua + Enterprise | Lambda only | Ext services | Filters/WASM |
| gRPC Support | Good | Good | Limited | Excellent | Excellent |
| Rate Limiting | Built-in + Redis | Advanced | Basic | External svc | External svc |
| Auth Options | Multiple | OIDC/SAML++ | IAM/Cognito/Lambda | External | External |
| Ops Overhead | Medium | Medium | Very Low | Medium | High |
| Cost Model | Free + Ops | License + Ops | Per-request | Free + Ops | Free + Ops |
| Vendor Lock-in | Low | Medium | High (AWS) | Low | None |
Cost comparisons must include Total Cost of Ownership (TCO), not just license fees:
Self-Hosted (Kong, Envoy, Ambassador):
TCO = Infrastructure + Operations + Opportunity Cost
- Infrastructure: Compute, networking, storage
- Operations: Team time × rate (deployment, maintenance, debugging)
- Opportunity Cost: What else could the team build?
Managed (AWS API Gateway):
TCO = Request Fees + Additional Services + Customization Limits
- Request Fees: Predictable, scales with usage
- Additional Services: Lambda authorizers, caching
- Customization Limits: Cost of workarounds when features are missing
Self-hosted gateways appear 'free' but consume engineering time. A senior engineer spending 4 hours/week on gateway maintenance costs $400-800/week in loaded cost. Factor this into TCO calculations versus managed alternatives.
Context: Small team, serverless architecture, AWS-native, cost-conscious, velocity-focused.
Recommendation: AWS API Gateway (HTTP API)
Context: Platform team supporting multiple product teams, Kubernetes standardization, need for self-service, existing Istio investment.
Recommendation: Ambassador Edge Stack or Istio Ingress Gateway
Context: Services across AWS, GCP, and on-prem data centers. Avoid vendor lock-in. Significant API customization needs.
Recommendation: Kong (OSS or Enterprise)
Context: Internal service mesh edge, ultra-low latency requirements, team with C++/networking expertise.
Recommendation: Envoy Direct
Context: Public API for third-party developers, need developer portal, monetization via API keys and quotas, documentation.
Recommendation: Kong Enterprise or Apigee
Context: Migrating from monolith, tight budget, team knows NGINX, need gradual rollout.
Recommendation: NGINX Plus or Kong OSS
Don't over-engineer gateway selection. Start with the simplest solution that meets current needs. AWS API Gateway today doesn't prevent Kong tomorrow. Gateway migrations are work but rarely catastrophic. Optimize for time-to-value.
Before evaluating solutions, document requirements explicitly:
Functional Requirements:
Non-Functional Requirements:
Operational Requirements:
Apply hard filters to create a shortlist of 2-3 candidates:
| Filter | Question | Eliminates |
|---|---|---|
| Infrastructure | Must run on X? | Incompatible platforms |
| Protocol | Need gRPC/WebSocket? | Limited protocol support |
| Budget | Zero license budget? | Commercial-only solutions |
| Compliance | Specific certifications? | Non-compliant options |
| Scale | >1B requests/month? | Per-request pricing models |
For each shortlisted candidate, build a minimal PoC:
PoC Checklist:
□ Deploy gateway in target environment
□ Configure basic routes to sample service
□ Implement authentication (your actual auth method)
□ Configure rate limiting (your actual limits)
□ Integrate with your monitoring stack
□ Load test to verify performance claims
□ Simulate failure scenarios
□ Document deployment & operation complexity
□ Estimate operational burden
Allocate 2-3 days per candidate. This investment prevents months of regret.
Score each candidate objectively:
| Criteria | Weight | Kong OSS | AWS API GW | Ambassador |
|---|---|---|---|---|
| Meets functional requirements | 25% | 9/10 | 7/10 | 8/10 |
| Operational simplicity | 20% | 6/10 | 9/10 | 7/10 |
| Performance | 15% | 8/10 | 7/10 | 8/10 |
| Team expertise fit | 15% | 7/10 | 8/10 | 6/10 |
| Total cost (3-year) | 15% | 7/10 | 6/10 | 8/10 |
| Vendor/lock-in risk | 10% | 9/10 | 4/10 | 9/10 |
| Weighted Score | 100% | 7.6 | 7.1 | 7.5 |
The weights above are examples. A startup might weight simplicity at 30% and lock-in risk at 5%. An enterprise might weight compliance at 20%. Customize weights to your actual priorities.
Features matter less than operational mastery. A well-operated NGINX outperforms a poorly operated Envoy deployment. Match technology choice to your team's ability to operate it effectively.
┌─────────────────────┐ │ What's your │ │ primary platform? │ └──────────┬──────────┘ │ ┌───────────┬───────────┼───────────┬───────────┐ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ AWS │ │ GCP │ │ K8s │ │Multi- │ │ VMs │ │Serverless│ │Serverless│ │ Only │ │ Cloud │ │On-prem│ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ AWS API GW GCP API GW Ambassador Kong OSS Kong/ HTTP API or Contour NGINX ┌─────────────────────┐ │ Operational │ │ preference? │ └──────────┬──────────┘ │ ┌───────────────────┼───────────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ Zero-Ops │ │ Some Ops OK │ │ Full Control │ │ Managed │ │ (GitOps) │ │ Preferred │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ ▼ ▼ ▼ Cloud Provider Kong DB-less Envoy Direct Gateway (AWS, Ambassador Custom xDS GCP, Azure) ContourModule Complete:
You've now explored the major API Gateway solutions—Kong, AWS API Gateway, Ambassador, Envoy—and have a framework for choosing among them. This knowledge equips you to make defensible gateway decisions and understand the trade-offs inherent in each approach.
Congratulations! You've completed Module 6: API Gateway Solutions. You now understand the landscape of API Gateway technologies, their architectural philosophies, and have a structured methodology for selecting the right gateway for your context.