A developer initiates a service-to-service call inside your private network. Instead of routing directly to the target container, the request travels out to an external cloud gateway. It passes through a public load balancer and routes back into your virtual private cloud (VPC). This round-trip adds 45 milliseconds of unnecessary latency to a simple database query.
Platform architects must balance performance, security, and operational overhead when managing internal microservices traffic. External-facing APIs need heavy rate-limiting, billing integration, and public-facing developer portals. Internal APIs require low latency, service discovery, and mutual TLS (mTLS).
Selecting the right gateway architecture determines whether your internal network remains fast and maintainable or becomes a bottleneck.
The internal microservices challenge: Self-hosted vs. managed
When routing traffic between internal microservices, you face a fundamental choice — run a self-hosted gateway inside your own network boundary, or route traffic through a cloud-managed service.
[Self-Hosted Gateway] --> Runs inside VPC/Kubernetes --> Ultra-low latency (1-3ms)
[Cloud-Managed Gateway] --> Routes outside VPC boundary --> Higher latency (15-50ms)
Self-hosted gateways
Self-hosted gateways like Kong and Tyk run directly on your infrastructure — typically as Kubernetes ingress controllers or sidecars. Because they sit inside your private network, they eliminate external network hops. This proximity keeps latency to a minimum — often under 5 milliseconds.
You also retain complete control over data residency and network boundaries. However, self-hosted gateways require manual configuration, patching, scaling, and state management.
Managed cloud gateways
Managed services like AWS API Gateway or GCP Cloud Endpoints require almost zero infrastructure maintenance. The cloud provider handles scaling, availability, and provisioning.
The trade-off is latency and network complexity. Routing internal VPC traffic through a managed cloud gateway often requires configuring private VPC endpoints or NAT gateways. This architecture introduces virtualization overhead and network hops — factors that can degrade the performance of chatty microservices.
Kong: The extensible, high-performance Lua standard
Kong is built on top of Nginx and OpenResty. It uses Lua for its plugin architecture. It is one of the most widely deployed open-source API gateways in production environments.
Architecture and performance
Because Kong inherits Nginx’s event-driven architecture, it handles high throughput with minimal memory usage. It processes requests quickly. This makes it suitable for high-performance internal routing.
The plugin ecosystem
Kong relies on a modular plugin system. Features like authentication, rate limiting, and request transformation exist as separate plugins. You can write custom plugins in Lua or Go to meet specific internal security policies.
Operational complexity
Managing Kong requires managing its state. Historically, Kong required a PostgreSQL or Cassandra database to store configuration data. Running a stateful database just for an API gateway adds operational overhead for platform teams.
To address this, Kong offers a "DB-less" mode. In this mode, you define configurations in a declarative YAML file. This fits well into GitOps workflows and Kubernetes deployments — you can load configurations directly via ConfigMaps without managing a database.
Tyk: The feature-rich Go-based alternative
Tyk was written from the ground up in Go. It emerged as a direct competitor to Kong, aiming to provide a more cohesive out-of-the-box experience.
Architecture and performance
Tyk’s Go engine is highly concurrent. While Nginx-based gateways sometimes edge out Go in raw, single-threaded throughput tests, Tyk offers predictable, low-latency performance under heavy parallel workloads.
Built-in capabilities
Unlike Kong, which relies on a modular plugin model, Tyk includes many core features directly in its main binary. Rate limiting, detailed analytics, and developer portals do not require separate plugins. This makes the initial setup simpler — you do not have to research, install, and configure multiple add-ons to get basic functionality.
Licensing and open source
Tyk offers an open-source gateway engine under the Mozilla Public License 2.0. However, its management dashboard and multi-data center control plane require a commercial license. For teams that want a visual UI to manage internal APIs, Tyk's commercial licensing is often more straightforward than enterprise alternatives — though it can still be a barrier for small teams.
Cloud-native options: AWS API Gateway and GCP Cloud Endpoints
For teams already embedded in AWS or Google Cloud, using the cloud provider's native gateway is a common starting point.
AWS API Gateway
AWS API Gateway is a fully managed service that integrates with AWS IAM, Lambda, and CloudWatch. While convenient, using it for purely internal microservices introduces several challenges:
- Latency: Requests often route through AWS's public infrastructure before returning to your private subnets, adding latency.
- Cold starts: If your gateway triggers AWS Lambda functions internally, you may experience intermittent latency spikes during scaling events.
- Cost at scale: AWS API Gateway charges per million API calls. For high-volume internal service-to-service communication, this pricing model quickly becomes expensive.
GCP Cloud Endpoints
Google Cloud Endpoints uses the Extensible Service Proxy (ESP), which is based on Envoy. It runs as a container alongside your service inside Google Kubernetes Engine (GKE). Because ESP runs locally, it avoids the external network hops of AWS API Gateway — offering a closer approximation to a self-hosted gateway experience with managed control planes.
Decision framework: Choosing by team size and infrastructure scale
To choose the right gateway, look at your team's operational capacity rather than raw performance benchmarks.
Small teams (1 to 5 platform engineers)
If your team is small, minimize operational maintenance.
- Recommendation: Use DB-less Kong or a managed cloud-native gateway.
- Why: DB-less Kong allows you to manage configurations in Git without running a database. If latency is not a critical metric for your application, a cloud-managed service like AWS API Gateway keeps your maintenance burden near zero.
Mid-sized teams (5 to 15 platform engineers)
At this scale, you likely run multiple Kubernetes clusters and need consistent internal routing policies.
- Recommendation: Tyk or DB-less Kong.
- Why: Tyk provides a comprehensive feature set out of the box, reducing the time your team spends configuring plugins. Kong in DB-less mode integrated into a CI/CD pipeline offers a lightweight, high-performance footprint.
Large platform teams (15+ platform engineers)
Large organizations require multi-region deployments, custom security integrations, and complex routing rules.
- Recommendation: Kong with a hybrid control/data plane architecture, or a dedicated service mesh like Istio.
- Why: Kong’s hybrid mode allows you to run a central control plane that pushes configurations to data planes running in multiple clouds or regions. This provides maximum control and performance — provided you have the engineering hours to maintain the infrastructure.
An illustrative cost and performance comparison
Consider a mid-sized engineering team processing an average of 50 million internal API calls per day (an illustrative example).
- Scenario A (AWS API Gateway): At an illustrative rate of $3.50 per million requests, routing this internal traffic through AWS API Gateway costs $175 per day — or roughly $5,250 per month. This does not include data transfer fees or the latency overhead of routing traffic outside the VPC.
- Scenario B (Self-hosted DB-less Kong): The team deploys DB-less Kong on three small Kubernetes nodes within their existing cluster. The compute cost is roughly $150 per month. Latency drops from an average of 18ms per hop to under 2ms. The trade-off is that the team must manage their own deployment manifests and upgrade paths.
Compare API infrastructure options on StackMatch
Selecting the right API gateway requires analyzing specific technical specifications, licensing structures, and compatibility with your existing Kubernetes or cloud environment.
You can explore these trade-offs in detail on StackMatch. As a curated directory for developer tools, StackMatch allows platform engineers to compare API gateways side-by-side using comparison tables and editorial reviews. You can review editorial scores covering ease of use, pricing transparency, and integration support to find the gateway that fits your team's operational scale.
FAQs
Is Kong faster than AWS API Gateway for internal traffic?
Generally, yes. Because Kong can be deployed directly within your internal Kubernetes cluster or VPC, it avoids the external network hops and virtualization overhead associated with AWS API Gateway — resulting in lower, more predictable latency.
Can I run Tyk entirely open-source?
Yes, Tyk offers an open-source gateway engine under the MPL 2.0 license. However, some advanced management features, dashboards, and enterprise support require a commercial license.
What is DB-less mode in Kong, and should I use it?
DB-less mode allows you to configure Kong entirely via declarative YAML files rather than storing configuration in a PostgreSQL database. This is highly recommended for internal microservices as it simplifies deployments, fits into GitOps workflows — and removes a stateful dependency.
How do Kong and Tyk handle gRPC traffic?
Both gateways support gRPC routing and transcoding. Kong handles gRPC natively through Nginx's HTTP/2 capabilities, while Tyk provides built-in middleware to manage gRPC web clients and protocol buffer translations.