API management · Kong Gateway
API gateway for Saudi enterprises: what it does, where it runs and how to choose
An API gateway is the single entry point in front of your APIs. It routes each request to the right service and applies the same rules to every call: authentication, rate limits, request checks and logging. Each service then does not have to apply them separately. For Saudi organisations, the first design question is usually where the gateway runs, because the component that inspects payloads runs wherever the traffic flows. Interkey designs, implements and operates API gateways on Kong Gateway for organisations in Saudi Arabia, from Riyadh.
Published 5 min read
In short
- What it does: routing, authentication, rate limiting, request validation, logging and metrics, enforced in one layer for every API.
- Where it runs: with a database, without one (configuration from a file), or split into a control plane and data planes. On Kubernetes it can also run as the cluster's ingress.
- What decides the design: whether payloads may leave the Kingdom, who operates the platform, and how many teams publish APIs.
- What it does not do: make an unsafe service safe. The services behind it still need their own security review.
- What Interkey implements: Kong Gateway, a product of Kong Inc., one of Interkey's technology partners.
What an API gateway does
| Function | What it does | Kong Gateway examples (Kong Plugin Hub, 2 November 2026) |
|---|---|---|
| Routing | Sends each request to the right service and version | Routes and services defined in configuration |
| Authentication | Checks who is calling before the request reaches a service | Key Auth, JWT, Basic Auth, OAuth 2.0; OpenID Connect and Mutual TLS in the Enterprise edition |
| Access control | Limits which consumers and networks may call which API | ACL, IP Restriction |
| Traffic limits | Protects services from overload and enforces fair use per consumer | Rate Limiting, Request Size Limiting; Rate Limiting Advanced in the Enterprise edition |
| Request validation | Rejects malformed or unexpected requests before they reach a service | Request Validator and OAS Validation in the Enterprise edition |
| Browser access | Controls which web origins may call an API | CORS |
| Observability | Records each call, so failures can be traced to a caller | Logging and metrics sent to your observability platform |
Which features need the Enterprise edition changes over time, so check Kong's current Plugin Hub when you plan.
API gateway, API management, ingress controller: the difference
- API gateway: the runtime that every API call passes through, and the subject of this page.
- API management: the wider practice around it: an inventory of every API, a written policy, consumer onboarding, versioning and deprecation, and operation. The gateway enforces the policy. Read about Interkey's API management practice.
- Ingress controller: the component that brings external traffic into a Kubernetes cluster. Kong Ingress Controller runs Kong Gateway as that ingress. It supports Kubernetes Ingress resources and the Gateway API (HTTPRoute, TCPRoute and UDPRoute), and it configures Kong through Kubernetes custom resources.
- Microservices gateway: the same API gateway placed in front of many small services, so that each service does not carry its own authentication and limits.
Where the gateway runs: three deployment shapes
Kong documents three ways to run Kong Gateway:
| Shape | How it works | Suits | Trade-off |
|---|---|---|---|
| Traditional (with a database) | Every node connects to a database and acts as both control plane and data plane | Teams that need database-dependent plugins, such as rate limiting with the cluster strategy or OAuth 2.0 | Each node holds the full configuration, so a compromised node exposes all of it |
| DB-less | Configuration is loaded from a declarative YAML or JSON file and held in memory. There is no database | Small or static estates managed entirely as code | The Admin API cannot change configuration, and some plugins that need a database are not compatible |
| Hybrid | A control plane holds the configuration. Data planes carry the traffic and need no database of their own | Several environments or sites, with one place to manage policy | Two planes to operate. If the control plane goes offline, data planes keep running on their last known configuration |
The Saudi question is where each plane runs. If payloads may not leave the Kingdom, the data plane that inspects them must run in the Kingdom too. Kong can run self-managed, with both planes on infrastructure you operate in Saudi Arabia. Interkey's Kong implementation page compares the self-managed, hybrid and Kubernetes options and when each one suits.
What to require from an API gateway
Use this list to assess any gateway, including a proposal from Interkey:
- Configuration as code. Every route, plugin and consumer is defined in version-controlled configuration. Kong's decK tool manages this declaratively.
- One identity source. Authentication is delegated to the identity platform you already run, with no second credential store inside the gateway.
- Per-consumer limits, set from the API inventory rather than defaults, with an alert when a consumer reaches its limit.
- Telemetry by default. Every call is logged and measured in your observability platform.
- Rehearsed upgrades and a rollback plan before each version change.
- Secrets rotation for certificates and keys, on a schedule.
- Versioning and deprecation rules, so a change does not break three consumers at once.
- Arabic payloads tested. Right-to-left and mixed-script data passes through unchanged.
What a gateway does not fix
A gateway applies the same rules to every call. It cannot make an unsafe service safe. Weak authorisation inside a service, excessive data in responses and unpatched dependencies all still need fixing in the service itself. Public-facing APIs need stricter policies and a review of the gateway configuration.
How Interkey delivers an API gateway
-
Inventory and policy.
List the APIs you expose and their consumers, then write the policy the gateway will enforce.
-
Deploy in the right shape.
Choose traditional, DB-less or hybrid, decide where each plane runs, and decide whether Kubernetes ingress is part of the design.
-
Policy as configuration.
Express authentication, limits and validation in version-controlled configuration.
-
Move consumers.
Move each consumer onto the gateway, then close the old direct routes.
-
Operate.
Interkey operates the gateway as a managed service, or hands the configuration repositories and runbooks to your team.
Kong licensing, where the Enterprise edition is needed, is quoted on Kong's terms alongside Interkey's services. Organisations that have already chosen another gateway product can still use Interkey's API management practice. If you also route traffic to large language models, see Kong AI Gateway.
Questions buyers ask
How do we choose an API gateway?
No single gateway suits every organisation. Judge each option against the requirements above, where the data must stay, and who will operate it. Interkey implements Kong Gateway.
Is an API gateway the same as API management?
No. The gateway is the runtime that enforces policy. API management also covers the inventory, policy, onboarding, versioning and operation around it.
Can the whole gateway run inside the Kingdom?
Yes. With a self-managed deployment, the traffic plane and the configuration plane both run on infrastructure you operate in Saudi Arabia.
We already run Kubernetes. Do we still need a gateway?
Kong Ingress Controller runs Kong Gateway as the cluster's ingress, so one component can bring traffic into the cluster and apply gateway policies. Whether that is enough depends on how many APIs live outside the cluster.
Do we need the Enterprise edition?
That depends on the features you need. Some plugins, including OpenID Connect and Rate Limiting Advanced, are listed as Enterprise only. We confirm the edition against your requirements before quoting.
Next
Related pages
Next step
Discuss an API gateway
Tell us roughly how many APIs you expose, who calls them, where the data must stay and whether you run Kubernetes. We will propose a deployment shape and the first steps of an API inventory.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia