Amazon API Gateway or Kong Gateway open source: which fits your API estate
Amazon API Gateway fits best when your APIs live inside AWS and your team wants to avoid running gateway infrastructure. If a renewal, a rising per-call bill or a need to run APIs in other clouds or your own data centers is pushing you to look at Kong Gateway open source, the decision turns on three things: which features you need from Kong's paid editions, whether your team can operate Kubernetes or EKS, and where your data and traffic are allowed to go. API Gateway stays the simpler choice for Lambda-backed and IAM-secured workloads, where its native integrations and low operating appetite matter more than portability. Kong Gateway OSS fits when you want declarative configuration kept in Git, a gateway you run on clusters you control, and one set of policies across AWS, other clouds and on-premises networks.
Kong Gateway is licensed under Apache-2.0 and runs in DB-less mode, where configuration lives in declarative files that can be versioned and synced with decK. That model suits teams that already manage infrastructure as code. The open-source edition does not include every capability you may rely on today. Only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, and Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of Kong Gateway Enterprise. Before you commit, map each feature your API Gateway usage plans, authorizers and throttling depend on to an open-source plugin or to a paid edition, and confirm the result with Kong against your exact deployment topology.
Operating Kong means owning the cluster. Your team will run the data plane, the database for traditional mode if you need it, certificates, upgrades and monitoring, and the Kong Ingress Controller if you deploy on Kubernetes. Check whether your engineers already run EKS or another Kubernetes platform well enough to take on that load, because that skill, not the software license, is often the largest cost. Write down where traffic must terminate and where logs and configuration may be stored, since a self-run gateway keeps those inside your boundary by design. Ask DeployOpen or another implementation partner for a written scope covering topology, plugin mapping, upgrade cadence and runbooks before you set a migration date.
Which option fits which scenario
This table maps common operating scenarios to a better-fit choice between Amazon API Gateway and self-hosted Kong Gateway open source, with the reason for each. Where the answer depends on your environment, the row says so and names what to confirm before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| APIs sit mainly in AWS with Lambda and VPC link integrations | Amazon API Gateway | Native integrations, IAM-based access and AWS-managed scaling remove gateway nodes your team would otherwise run, though per-call billing still applies. |
| APIs span several clouds or your own data centers | Kong Gateway OSS | One self-hosted gateway with the same plugins and declarative files can run in each location, instead of separate managed gateways per cloud. |
| Gateway configuration must live in Git with review and rollback | Kong Gateway OSS | DB-less mode reads declarative files that can sit in Git, and decK syncs them to the gateway, which fits a pull request workflow. |
| High, steady call volume that makes per-call pricing the largest line item | Depends on environment | Self-hosting shifts cost to nodes, databases and operations staff, so the break-even point depends on your own node sizing and staffing. Model it with your call data before deciding. |
| Need for database-dependent features such as cluster-strategy rate limiting or OAuth2 plugins | Depends on environment | These need traditional mode with a database rather than DB-less mode, so confirm your topology and the operational load of that database. |
| Need for a developer portal, dashboard or fully licensed management features | Amazon API Gateway or a paid Kong edition | Kong's fully self-hosted local control plane and data plane are part of the commercial Kong Gateway Enterprise offering, so OSS alone does not provide them. Confirm the feature list against Kong's pricing page before choosing. |
| Need for a published support window for the gateway software | Amazon API Gateway or a paid Kong edition | Kong's version support policy covers only Kong Gateway Enterprise, so the OSS edition has no published support window. Ask Kong and your internal team who owns patching. |
| Team with no Kubernetes or container operations skills | Amazon API Gateway | Running Kong on EKS or Docker adds upgrades, certificates, monitoring and on-call work that a managed service removes. |
How Kong Gateway OSS maps to what API Gateway does
In API Gateway, a stage is a deployed copy of an API with its own invoke URL, and routes map methods and paths to integrations. Kong Gateway OSS models this with services, routes and upstreams. The Kong Gateway repository lists routing, load balancing and health checking among its core features. Stage separation is not a built-in Kong concept you should assume carries over, so you decide whether development, test and production run as separate Kong deployments or as separate declarative files.
- Routes and services: Each exported API stage becomes a Kong service with one or more routes that match hosts, paths and HTTP methods.
- Load balancing and health checks: Upstream targets and health checks replace the backend selection you configured for Lambda, HTTP or VPC link integrations. Confirm that every integration type in your inventory has a reachable upstream.
- Stage variables: API Gateway stage variables have no one-to-one object in Kong. Plan how hosts and upstream addresses will be parameterized per environment.
- Environment isolation: One data plane per environment, or separate declarative files per environment, makes promotion explicit. Choose the model that fits your change process.
- Hybrid mode: Kong supports separating the control plane from the data plane, which lets you manage routes centrally while gateways run closer to the backends.
Check each backend type in your current API Gateway inventory against an upstream your Kong deployment can reach, including any private network paths.
API Gateway authorization is built from IAM authorization, Cognito user pool authorizers and Lambda authorizers. The Kong Gateway README lists JWT, basic auth, OAuth and ACL authentication plugins. Together these cover many token-based and role-based patterns. Lambda authorizer code, which often carries custom claim checks, usually has to be re-expressed as plugin configuration or as a custom plugin that your team owns and maintains.
- JWT plugin: Validates tokens issued by your identity provider. Map the issuer, audience and claim checks from your existing authorizer configuration.
- OAuth plugin: The OAuth plugin is listed in the README, but Kong's deployment documentation places OAuth2 among database-dependent plugins, which need traditional mode.
- ACL and basic auth: ACL groups can express role checks that Lambda authorizers or usage plans performed. Basic auth fits internal callers, not public clients.
- Custom logic: Authorization logic outside the bundled plugins requires a custom plugin, with its own build, test and upgrade cycle.
- IAM and Cognito equivalents: AWS IAM signature checks and Cognito user pool authorizers are not listed in the README. Confirm how your callers will authenticate before you retire them.
Test every authorizer path with the same token types that production callers use before you remove the API Gateway authorizer.
API Gateway usage plans combine throttling, quotas and API keys, and they are attached to API stages. Kong's rate limiting plugin, listed among the README's features, covers the throttling side. Where the counters are stored determines your operating model. Kong's deployment documentation states that cluster-strategy rate limiting is database-dependent, so it requires traditional mode and not DB-less deployment.
- Throttling and quotas: Usage plans set request rate and period quotas per key. Confirm which of these limits your plugin configuration can express for each plan tier.
- Cluster strategy: Cluster-wide counters depend on a database, so they require traditional mode.
- DB-less counters: If you run DB-less, confirm which counter strategies the plugin supports in your release, using the plugin reference for that version.
- API keys and tiers: Usage plan keys have no direct copy. Confirm how consumer and key handling works in your release before you design tiers.
- Database operations: Traditional mode adds a database to back up, patch and monitor. That is a recurring operations cost to include in your estimate.
Decide your rate limiting strategy early, because it determines whether you run DB-less or traditional mode. The deployment topologies documentation explains both options.
API Gateway request and response mapping templates transform payloads between the client and the integration, and request validators check payloads against models. Kong Gateway OSS offers transformation plugins for common header, body and request changes, as the README lists. Mapping logic written in API Gateway templates usually needs to be rewritten, because the plugin set and scripting options differ from those templates.
- Simple transforms: Header and body changes that are direct field operations usually map to transformation plugin configuration.
- Template logic: Conditional or looped template logic has no drop-in equivalent. Rewrite it as plugin configuration, move it into the backend, or implement it in a custom plugin.
- Payload validation: Confirm which request validation your Kong release provides, or plan schema checks in the backend.
- Custom code: Heavy transformations are a reason to write a custom plugin, which adds ongoing maintenance for each Kong upgrade.
- Export baseline: Use exported OpenAPI definitions as the contract for each route, so tests compare against what clients already expect.
Run contract tests against every transformed route so response shapes stay the same for existing clients.
Capabilities, licensing and editions side by side
This table compares what Amazon API Gateway provides as a managed service with what the open-source Kong Gateway offers when you run it yourself. Read the licensing and edition rows first, because they decide which features you can run without a commercial agreement.
| Capability | Amazon API Gateway | Kong Gateway open source (Apache-2.0) |
|---|---|---|
| Routing and load balancing | Routes and integrations configured per API stage in AWS | Routing, load balancing and health checking are in the Kong Gateway README; confirm the exact set against your version |
| Authentication | Lambda, Cognito and IAM authorizers, plus API keys | JWT, basic auth, OAuth and ACL plugins; OAuth2 plugin needs traditional mode with a database |
| Rate limiting | Usage plans and throttling tied to API keys | Rate limiting plugin; cluster-strategy limiting needs a database, so it is not available in DB-less mode |
| Transformation | Mapping templates and request or response transforms | Transformation plugins are listed in the README; confirm each plugin's behavior before migrating mappings |
| Declarative configuration | Exported OpenAPI definitions per stage | DB-less mode reads declarative files that can live in Git; decK dumps and syncs configuration (Apache-2.0) |
| Hybrid control and data planes | Managed by AWS; no customer-run control plane | Hybrid separation is supported; a fully self-hosted local control plane and data plane is part of Kong Gateway Enterprise |
| Kubernetes ingress | Not applicable; API Gateway is an AWS service | Kong Ingress Controller is Apache-2.0 licensed and maintained by Kong |
| Developer portal and analytics | Developer portal and metrics come from AWS and related services | Not covered by the OSS edition; confirm which portal or analytics features Kong offers under commercial licensing |
| Support window | Governed by AWS service terms | Version support policy covers Kong Gateway Enterprise only; the OSS newest line is 3.9 |
Where traffic and config live, and what that means for compliance
Moving from Amazon API Gateway to self-run Kong changes where requests are processed, where configuration is stored and who can see logs. Each decision below affects which controls you can evidence to an assessor, so settle them before the first production route moves.
Regional endpoints or your own clusters
Amazon API Gateway runs as an AWS-managed regional service, so request handling sits inside AWS's control plane. Self-run Kong Gateway runs in your own accounts or on EKS clusters you operate, which puts data plane nodes, network paths and patching under your ownership. Map each API's data flows and ask which network boundaries, subnets and encryption settings your assessor will expect to see.
Konnect control plane versus self-run
Kong Konnect hosts the control plane, while data plane nodes can be self-hosted, serverless or Kong-managed Dedicated Cloud Gateways on AWS, Azure or GCP. Each option moves a different part of configuration and telemetry outside your boundary. Confirm with Kong where control plane metadata is stored and which regions apply before you choose a topology.
DB-less Git config as an audit trail
In DB-less mode, Kong reads declarative files that can be stored in Git, so every route, consumer and plugin change has a commit, author and review record. Using decK to sync those files adds a repeatable deployment path. Note that the read-only Admin API cannot be used to change state, and that database-dependent plugins such as cluster-strategy rate limiting and OAuth2 require traditional mode.
Identity and logging integration
API Gateway relies on IAM, Lambda authorizers and CloudWatch for much of its identity and logging. With Kong, you choose the authentication plugins (JWT, OAuth, ACL and others), the identity provider and the log destinations yourself. Document which identity source issues each credential, how revocation reaches every node, and where access logs are retained and who can read them.
Edition limits affect evidence
Features such as self-managed control planes and some management capabilities sit in Kong Gateway Enterprise, and the open-source edition has no published support window in Kong's version support policy. If an assessor asks for a vendor-supported patch timeline, the answer for the OSS edition has to come from your own maintenance plan. Ask Kong which edition covers each control you need.
Controls and evidence, prepared by DeployOpen
DeployOpen can help plan the placement, configuration pipeline, logging and access controls, and can collect the operational evidence an assessment needs. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, so agree on the evidence list and control mapping with them in writing before implementation starts.
How DB-less mode and decK change day-to-day operations
Running Kong Gateway without a database changes who touches the configuration and how changes reach production. In DB-less mode, the gateway needs no database. It loads its configuration from declarative files, which teams can keep in Git and review like application code. The Admin API is read-only in this mode, so routes, services and plugins are changed by editing files and redeploying, not by calling the API on a running node. Before committing to this model, confirm with your platform team that every change path (emergency fixes included) goes through the repository, and that your release process can roll back a bad file quickly.
The trade-off is that some plugins depend on a shared database. The Kong deployment topologies documentation states that only traditional mode supports database-dependent plugins, such as cluster-strategy rate limiting and OAuth2. If your API Gateway usage plans and per-client quotas map to cluster-wide rate limits, or you rely on OAuth2 token issuance, DB-less mode may not fit those flows. Check each plugin you plan to use against the topology documentation and decide early whether you need traditional mode with a PostgreSQL database and its operating cost.
decK is the Apache-2.0 command-line tool that bridges files and running gateways. Its deck gateway dump command exports the current configuration to a file, which is a practical starting point for an inventory. Its sync commands apply declarative files to open-source Kong Gateway, to Kong Gateway Enterprise and to Konnect, so the same workflow can be reused if you later change editions. Test the round trip before relying on it: dump a staging node, sync the file to a clean node, and compare routes, plugin settings and secrets references. Confirm which decK version matches your gateway version, and pin both in your pipeline.
Cost components on each side and what drives them
Moving from Amazon API Gateway to Kong Gateway open source changes which bills you pay and who pays them. The AWS side is metered per call and per cache hour, while the Kong side has no license fee for the open-source edition but adds compute, load balancing, Kubernetes and staff time that you own. The cards below separate one-time work from recurring costs and name the drivers you can influence.
Per-call API Gateway charges
Amazon API Gateway bills per API call, with the rate depending on the API type (REST, HTTP or WebSocket) and the volume tier you reach. This line recurs and grows with traffic, so it is the cost that makes self-hosting attractive at high volume. Pull your last 12 months of request counts per API type from AWS Cost Explorer and check the current rates on the AWS pricing page before comparing.
Caching and data transfer on AWS
Caching on API Gateway is billed by the hour for each cache size you enable, and data transfer out of AWS is billed separately. Both are easy to miss in a per-call comparison because they continue even when request volume is low. Ask your team which stages have caching turned on and what outbound traffic your APIs generate, since these costs do not disappear when you move the gateway.
Kong Gateway OSS license cost
The Kong Gateway repository is licensed under Apache-2.0, so the open-source edition carries no license fee. Fully self-hosted gateways with a local control plane and data plane are part of the commercial Kong Gateway Enterprise offering, so a move to Enterprise adds a recurring subscription. Confirm with Kong which edition covers the features you need, such as database-dependent plugins, before you budget for either path.
Compute and load balancers for gateway nodes
Kong nodes run on compute you provision and pay for, usually in your own AWS account or data center, and a load balancer sits in front of them. These costs recur monthly and scale with the number of nodes, the traffic peak you size for and the number of regions. Ask for a sizing estimate based on your peak requests per second, and plan for at least two nodes per environment so a single failure does not stop traffic.
Database or database-less mode
In DB-less mode Kong needs no database, and it reads declarative files that you can keep in Git, which removes a recurring database cost. Traditional mode needs a database and adds backup, patching and failover work, and it is required for database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Choose the mode before sizing infrastructure, because the choice drives both the database line and the plugins you can use.
Kubernetes and EKS operating costs
Running Kong on EKS adds a control plane fee and worker node costs for the cluster, plus any add-ons you run for ingress, certificates and logging. These costs recur whether or not the gateway is busy, and they are shared with other workloads if the cluster is shared. Check whether your platform team already runs a cluster that can host Kong, because a dedicated cluster can change the cost comparison more than the gateway itself.
Monitoring, logging and staff time
Observability tooling for metrics, logs and traces is a recurring cost you must add, and the people who upgrade, patch, rotate certificates and respond to incidents are the largest variable. One-time work includes migrating routes, authentication and rate limits and testing them before DNS cutover. Ask for a fixed-scope estimate that separates the migration effort from the ongoing operating hours your team will carry after go-live.
What a move from API Gateway to Kong Gateway involves
The sequence turns API Gateway stages, authorizers and usage plans into Kong services, routes, plugins and declarative files that can be tested and promoted before any client traffic moves. The output is a self-hosted Kong runtime that serves the same APIs with the same consumers.
Inventory APIs, stages and exports
Your platform or API team lists every REST, HTTP and WebSocket API, its stages, custom domains, integrations, authorizers, usage plans and API keys. Export the OpenAPI definitions per stage and record what the export leaves behind, such as usage plans, keys and authorizer code. Done when each API has a named owner, a stage inventory and a list of behaviors that must be rebuilt by hand.
Map stages and integrations to Kong objects
Decide how each API Gateway stage becomes Kong services, routes and upstreams, and how Lambda, HTTP and VPC link integrations will reach their backends from the Kong data plane. Confirm the network path from your Kong nodes to each private backend. Done when a written mapping table exists for every API and a reviewer has signed off on the network design.
Convert OpenAPI to declarative configuration
Convert the exported OpenAPI files into Kong declarative configuration, then reconcile it with decK so the file is the source of truth. Store the files in Git and review changes through pull requests. Done when decK can dump the running configuration and the diff against your Git copy is empty for every service.
Re-create authorizers with authentication plugins
Replace each Lambda or Cognito authorizer with an equivalent Kong authentication plugin, such as JWT, OAuth or key-based auth, and document any claim or scope logic that the old authorizer code applied. Confirm which consumers and credentials move across. Done when test tokens and keys that worked on API Gateway are accepted or rejected on Kong in the same way across the test cases you wrote.
Replace usage plans with rate limiting
Translate each usage plan and API key quota into Kong rate limiting and consumer groups. Check whether your chosen deployment mode supports the database-dependent limiting strategy you need, because only traditional mode supports cluster-strategy rate limiting and OAuth2. Done when each consumer's limits are documented, tested with load and matched to what finance and partners expect.
Build the runtime on EKS or elsewhere
Deploy the Kong Gateway open-source runtime on EKS through the Kong Ingress Controller, on EC2 or on another platform you operate, and choose between traditional mode and DB-less mode with hybrid control and data plane separation where needed. Confirm the packaging and TLS setup, logging and monitoring, and the backup of configuration. Done when a staging environment serves the test APIs and its configuration matches Git.
Test behavior, latency and failure paths
Run functional, security and load tests against Kong with the same requests used on API Gateway, including error responses, throttling, timeouts and health-check failures. Compare headers, status codes and payloads with the baseline. Done when every test case has a recorded pass result and the open issues are assigned to an owner before cutover is scheduled.
Shift traffic by DNS or weighted routing
Move production traffic in stages, using DNS changes or weighted routing at the load balancer, and keep API Gateway available as the rollback path until monitoring confirms stable behavior. Keep a written rollback procedure. Done when all production traffic runs through Kong, error rates and latency match the agreed thresholds, and the old stage is retired under change control. For a step-by-step plan, see the migration guide.
Questions buyers ask before switching from API Gateway to Kong
How much effort does a switch from API Gateway to Kong take?
The effort depends mainly on how many APIs, stages and authorizers you run, and how much of your behavior lives in API Gateway features that do not map one to one. Effort rises with custom Lambda authorizers, usage plans with API keys, VPC links, request and response mapping templates, and per-stage configuration. Effort falls when your APIs are described in clean OpenAPI files and most traffic goes to HTTP backends. Start with an inventory of routes, integrations, authorizers and quotas, then compare it with Kong's decK model of services, routes and plugins. Ask any implementation partner for a written scope that lists each API and each feature that needs a replacement before agreeing on a fixed price.
Can our own team migrate from API Gateway to Kong without outside help?
A team with Kubernetes or container operations experience and some gateway knowledge can often run a pilot alone, and many do. The harder parts are usually the ones that are easy to underestimate: rebuilding authorization behavior, reproducing quotas, and testing traffic cutover without breaking clients. Outside help is most useful for a defined piece of work, such as converting exported definitions into declarative configuration, hardening the deployment, or preparing test evidence. Decide early which parts your staff will own after handover, and ask for documentation and a runbook as written deliverables.
What do our platform and AWS teams need to contribute?
Your platform team needs to own the Kubernetes or virtual machine environment that runs Kong, the network paths to backends, the load balancer and TLS certificates, and the database if you use traditional mode. Your AWS team needs to provide access to API Gateway configuration and logs, IAM roles for any Lambda authorizers being retired, and VPC connectivity to private backends. Security and identity staff are needed to decide how tokens are validated, which claims are trusted and where keys are stored. Put these responsibilities into the written scope so that each team knows what it must deliver and when.
Does Kong open source lack features we need, and which need Enterprise?
Kong Gateway OSS covers common needs such as routing, load balancing, health checks, JWT, basic auth, OAuth, ACL, rate limiting and transformation plugins, plus DB-less declarative deployment. Some capabilities are different in the open-source edition. Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode, not DB-less mode. Fully self-hosted control plane and data plane setups, along with several management and governance features, belong to Kong Gateway Enterprise, according to Kong's pricing page. Map each feature your APIs use against the Kong pricing page and ask the vendor to confirm the edition for each one in writing.
How long does a migration from API Gateway to Kong take?
No timeline is given here because duration depends on scope, not on a fixed template. The main drivers are the number of APIs and stages, the complexity of authorizers and quotas, the number of consumers that must move, the test coverage you already have, and how many approvals each traffic shift needs. A small set of HTTP APIs with good OpenAPI definitions moves faster than a large estate with custom authorization and many VPC integrations. Ask for a phased plan that states start and end points for each phase, the acceptance tests and the rollback steps, and confirm those dates in the written scope.
What does running self-hosted Kong involve after go-live?
Running Kong is a recurring job with several parts: patching and upgrading the gateway, maintaining the Kubernetes or host platform, monitoring latency and errors, rotating certificates and keys, and reviewing configuration changes. Open-source releases follow their own cadence, and Kong's version support policy applies only to Enterprise, so you should confirm your own patching obligations and how long a release line will receive fixes. Configuration kept in Git and applied with decK makes changes reviewable. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope for those should be agreed in writing.
Will moving authentication and rate limiting to Kong change our security posture?
It can, because authorization moves from AWS-managed components into gateway plugins and your own configuration. Review how JWT signing keys, client secrets and API keys are stored and rotated, and confirm that the rate limiting you configure matches the quotas clients currently rely on. Keep access logs and audit trails flowing to your existing monitoring so that a change in behavior is visible. Security testing of the new gateway should happen before cutover, and the results should be recorded as evidence. Ask your assessor which controls they will need you to show.
Operating Kong Gateway on EKS, other clusters or bare metal
Kong OSS installs in several ways, and each one moves operational work to your team. The open-source edition runs from Docker, Docker Compose, Kubernetes or Linux packages for Ubuntu, RHEL, Debian and Amazon Linux. On EKS, most teams deploy the gateway with the Kong Ingress Controller, which is Apache-2.0 licensed, and pin both components to versions that Kong documents as compatible. On EC2 or bare metal, the package route on Amazon Linux or RHEL is the most direct. In every case, your team owns the cluster or hosts, node and OS patching, TLS certificates, the database if you run traditional mode, log shipping, and health monitoring. Kong does not operate these components for you under the open-source edition, so assign named owners for each before go-live.
The upgrade cadence is the main planning constraint. The open-source repository's newest release line is 3.9, and the 3.9 patch releases are published on the GitHub releases page. Kong Gateway Enterprise moved to quarterly releases from March 2025 and is now on a later 3.x line. Kong's version support policy applies only to Enterprise, so it gives no published support window for the open-source edition. Build a written upgrade plan: pin a tested patch version, subscribe to release notes, rehearse each upgrade in a staging cluster with your real plugins and declarative configuration, and set a review date for deciding whether the 3.9 line still meets your security patch expectations.
Confirm the open items with Kong before you commit to a version. Ask whether the 3.9 OSS line will receive security fixes, and for how long, and whether your chosen Kong Ingress Controller release supports that gateway version. Check which plugins and features you need are available in OSS and which require Enterprise. Confirm what support, if any, Kong offers for the open-source edition and whether a commercial support contract is the only path to a defined response commitment. Record the answers in an internal version matrix. Your auditors and security reviewers will ask who patches each layer and on what schedule, so the matrix should name an owner for each answer.
How DeployOpen works on this
DeployOpen starts by mapping the APIs, policies and authentication flows that currently run on Amazon API Gateway, then decides with you whether Kong Gateway open source fits your traffic and operating model. We then plan, build and hand over a self-hosted Kong deployment inside your own AWS accounts, data centers or air-gapped networks.
How we scope
- Inventory every API Gateway stage, route, authorizer, usage plan and custom domain before any design work starts.
- Confirm which features your APIs need, including plugins that depend on a database, to decide between DB-less and traditional mode.
- Agree the scope, deliverables and timelines in writing before work begins, since most engagements are fixed-scope.
How we build
- Convert exported OpenAPI definitions into declarative Kong configuration, kept in Git and synced with decK.
- Re-create authorizers with Kong authentication plugins and replace usage plans with rate limiting, testing each route against current behavior.
- Deploy Kong Gateway on EKS or your chosen platform, with hardening, logging and monitoring set up in your own environment.
How we hand over
- Document the architecture, configuration repository, deployment steps and rollback procedure for your engineering team.
- Run staged traffic cutover with test evidence for each route, so you can confirm behavior before DNS changes.
- Confirm with Kong which features your edition includes, and record any gaps against your current API Gateway usage.
How we support
- Back up configuration and gateway components, and plan upgrades against the open-source release line you adopt.
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Ask for a written quote based on your scope, since DeployOpen does not publish a price list.
