Kong Konnect Enterprise

My main use case for Kong Konnect , at least with the clients that I work with, is to create a centralized single pane of glass for all of their control planes, whether it be for their API gateways or their AI gateways, so the SaaS control plane can control and configure and give visibility to all of those data plane nodes.

One of the last clients I worked with was a large automotive enterprise company that uses Kong Konnect  to control or house all of their API gateway control planes. Kong Konnect gives you the ability to roll out a federated operating model so that you can have multiple teams; they had about 80 teams, allowing them to not only get self-service to manage their own configurations but also have isolation from anyone else, reducing the blast radius of there being any issues.

Some other use cases or features that Kong Konnect gives you that I've seen other customers use include a really good analytics feature that allows you to get information about requests, specifically getting latency information when requests go through the gateway and on which features and plugins are being used. Additionally, having the ability to use an IDP  called Kong Identity is a really nice way of doing machine-to-machine identity management rather than bringing in options like Entra. Obviously, I've mentioned API gateways, but the same plays out with AI gateways as well, and having the ability to add the capabilities needed, whether it's linking out to guardrails or being able to use open telemetry to see what's going on. I think the feature set is very rich within Kong.

Kong Konnect reduces the operational overhead of being able to run a control plane, as well as gives you that single pane across large enterprises when you want to work in a federated operating model, which I think is quite a major benefit. It means there's no operational tasks of doing things like updating licenses when you are very federated across an organization, and it just opens up the visibility of what's going through your gateways. I think it's a really great tool, and I've seen a number of enterprise companies using it.

The whole area of API and AI management is quite complex, with so many different ways of being able to do things. I think a positive of Kong is that it's so configurable and extendable, but that is also a con because there are so many ways of achieving the same thing that I think often people are either confused or struggle to get going as to how to solve a particular problem. In my mind, a more opinionated deployment of Kong itself or even how to solve certain use cases would be something I would like to see, so a more opinionated use of their products and configuration of their products on how to solve the most common use cases.

That's probably the main thing about needed improvements for Kong Konnect. It's a pretty fully-fledged platform; there obviously are portions of it that could be improved. But I think overall as a platform, it's really good, and I think it can help the majority of organizations looking to manage their throughput of APIs or AI traffic.

The majority of what I've said before probably covers the improvements needed for Kong Konnect. There probably are some API Ops and AI Ops changes that could be improved, which is not necessarily the Kong Konnect product, but some of the toolchains around it. I'm thinking around, especially if it's API Ops, about topics like better GitOps processes and the ways of being able to roll back changes when there are issues. At the moment, a lot of that is either non-existent or is hand-cranked. I would like to see the ability to roll back configurations when there are issues being added to the product.

I've been using Kong's product for about seven or eight years, and Kong Konnect has only really been around probably in the last three years, so I've been using Kong Konnect since it first hit the market.

Kong Konnect is very stable. Kong Konnect is just the control plane; the data planes or the proxies, which are the gateways, have been around and running for I would say 8 to 10 years, and I've seen them run at major scale in large companies across the whole of Europe. In my opinion, it is very stable.

Kong Konnect can handle scalability. Kong Konnect is the control plane, and there is the ability to add more teams and more control planes based on the number of teams you have onboarding. From that aspect, there's absolutely no problem. When it comes to increased traffic, that's effectively down to how you deploy it. The scalability of the infrastructure, whether it's EKS or ECS as an example in AWS , depends on being able to configure those correctly so that it scales; I have seen some performance metrics that show how well it scales. It can definitely handle growth for any organization.

Customer support for Kong Konnect is really good. Different tiers of support are available depending on how much you want to pay. Overall, the support team is very responsive; it's 24/7 support, so it goes around the world, and you will always have someone in support to talk to. If you aren't getting what you need, there's also the community where they have Kong champions who can answer questions for you as well.

I have helped companies migrate from other providers, but I haven't necessarily used those myself. Some of the major reasons behind moving are Kong's ability to follow a proper GitOps model and the simplicity of being able to configure the product as well. Not only that, there is really great support and a great community.

I have seen a return on investment from Kong Konnect, though sharing specific numbers is really difficult to do. From my previous client, who was a large enterprise automotive company, what I have seen there is the ability for a smaller team to be able to manage more federated consumers of the services because of how well the federated operating model works with Kong Konnect. Although I can't put a specific number on it, I have seen the scalability of being able to manage 80 to 100-plus teams with a small team of about three or four people.

The processing of the license for Kong Konnect is normally handled by procurement, so in large enterprises, that's not something I've had to deal with, so I can't really comment on that at all. Setup cost is pretty easy to get set up and get going once everything has been licensed and the contract signed, so I wouldn't say that the setup cost is much more compared to using any other product.

Before choosing Kong Konnect, I and my clients evaluated other options like the cloud providers' options, such as AWS  API Gateway or the Azure  API Gateway. Those are often the tools that get compared at least from an API standpoint. When it comes to the AI gateway, there are options like LiteLLM that I've worked with with customers, but I think the features that you get from the full platform of Kong Konnect just outshine something like LiteLLM.

The most simplest case would be a reduction in cost, because you don't have these additional operational tasks that need to happen anymore. Not only does that reduce cost and day-to-day cost, which is time, but it also means allowing teams to self-serve themselves and onboard themselves is a reduction in bottlenecks for platform teams and just works hand-in-hand with the federated operating model.

There is a measurable reduction in onboarding time and certainly a certain percentage of cost savings or resource hours saved after adopting Kong Konnect. I wouldn't be able to put a number on it because I think it will be dependent on the size of the organization, the size of the teams, how federated they are, and how many teams are using the products throughout the organization. It would very much depend on the size of the company for the measurable savings you would have with respect to financial as well as time-based outcomes, but I've definitely seen it improve the self-service capability that a platform team can offer to an organization.

My advice for others looking into using Kong Konnect would be to try it out yourself and just see whether it works and solves what you want within your organization. There is an open-source version, not of Kong Konnect but of the gateway, so you could use that to see whether it works for what you're looking for. I think you can get a two-week trial if you sign up at cloud.konghq.com, so that would be my advice.

I would rate customer support for Kong Konnect with a nine out of ten.

Hybrid Cloud

Amazon Web Services (AWS)

I use Kong Konnect  as a centralized API gateway solution that helps provide API solutions on a cloud platform. In my organization, Kong Konnect  has been implemented with different solutions using AWS  as a cloud provider. The deployment was accomplished using Terraform  as an automation tool, with the data plane deployed on ECS EC2 , connecting it to the control plane while managing configuration changes through Terraform .

Kong Konnect provides centralized API management, which means there is one place to manage all the APIs. It has a good plugin subsystem with built-in plugins for authentication, logging, and rate limiting, plus a hybrid architecture with a SaaS control plane and a data plane that can fit on Kubernetes , ECS, or any container solution.

Authentication, rate limiting, logging, and routing plugins are mainly used, which helps save costs by reducing engineering time to configure authentication since the plugins come with provided configuration settings that work immediately. Kong Konnect has helped save costs in terms of resources and reduced engineering time with the help of its plugins and authentication features, providing good scalability with the data plane being independent and improving developer productivity due to pre-built plugins for authentication and throttling.

The adoption of Kong Konnect has significantly helped reduce engineering time, allowing focus to shift from building logic for authentications and logging to more efficient operations, especially with high workload traffic.

The learning curve is the first issue when starting with Kong Konnect, as understanding the concepts such as services, routes, plugins, and the control and data planes takes time. Debugging  complexity arises from issues that can occur at any layer including gateways, plugins, and upstream services. I chose a rating of 8.5 for Kong Konnect because of the debugging complexity, which is an area that could see improvements.

I have using Kong Konnect just recently for seven to eight months.

Kong Konnect is stable.

Kong Konnect exhibits good scalable architecture with its two different planes: the data plane and the central one hosted on Kubernetes , ECS, or a container platform, making it very scalable.

The customer support is good.

I did not previously use a different solution.

Kong Konnect was purchased through the AWS Marketplace . The experience with pricing, setup cost, and licensing was quite good as the licenses were taken from the marketplace.

Although specific numbers are not available, Kong Konnect helps save resources since fewer engineers are needed to work on this, allowing very few resources to manage it.

Specific numbers have not been provided.

The experience with pricing, setup cost, and licensing was quite good as the licenses were taken from the marketplace.

Other options were not evaluated before choosing Kong Konnect. A couple of documentation reviews were conducted and Kong itself was targeted.

Kong Konnect should be considered as a good tool for API management that should be adopted. I would rate Kong Konnect an 8.5 overall.

Public Cloud

Amazon Web Services (AWS)

I have been using Kong Konnect  for the last year, and it has been a great experience. Mostly, I use it as part of our API testing and integration workflows. I was not directly involved in setting it up, but I have been consistently using it while testing microservices that were exposed through Kong Konnect  gateway. Over time, I became quite comfortable with how it impacts authentication and overall API behavior, especially while debugging failures in staging and CI pipelines.

The main use case for me in Kong Konnect is API testing. From my perspective as an SDET, I use it as a centralized API gateway for all our microservices. Instead of hitting services directly, all our requests are routed through Kong Konnect, which handles authentication, request routing, and rate limiting perfectly. For us in testing, it became important because we had to validate not just the API responses, but also gateway-level behaviors, such as whether the correct authentication policies were enforced and if requests were being throttled properly under load. In my company, the load is really high, so Kong Konnect provides a very reliable mechanism to maintain good uptime and quality for the APIs for our clients.

One specific way I used it was while writing and debugging API test cases for services that are behind Kong Konnect. I was validating authentication flows and rate limiting, and I used ChatGPT to quickly draft different request variations, such as how to structure headers and tokens. Then I used Kong Konnect to test that.

Another use case I can think of is that we started focusing more on gateway-level validations after using Kong Konnect, such as verifying authorization failures, handling of invalid tokens, and observing how rate limiting behaves under repeated requests. This actually improved our negative and edge case coverage quite a bit. Overall, interacting with Kong Konnect made our testing approach more aligned with real production scenarios rather than just isolated API validations.

As an SDET, I found that the best features of Kong Konnect are the centralized API management, where all the services are exposed through a single gateway layer. It made it much easier for us to validate APIs consistently instead of dealing with multiple service endpoints. Another important feature was analytics. Having visibility into API traffic and failures helped us to debug issues faster, especially in CI pipelines where it is sometimes hard to trace failures.

Analytics in Kong Konnect helped us mainly in debugging and identifying patterns in failures. Using these patterns, we have generated outcomes showing where our APIs exactly failed in edge case scenarios. For example, during regression runs in CI, if a set of API tests started failing intermittently, instead of directly assuming it was a backend issue, I used the gateway-level analytics to check request counts, error rates, and response statuses. In a couple of cases, I noticed spikes in 429 errors, which indicated rate limiting was kicking in. The issue was not the service logic but the gateway policy. That saved us a lot of time in root cause analysis. Overall, analytics gave us better visibility of the failures in our current system.

More specifically, another feature I could think of is authentication, logging, and rate limiting. These things could be handled at the gateway level instead of being implemented separately in each service. This is what I liked the most. From a testing standpoint, it actually reduced duplication and made our validations more consistent across APIs. One more thing I noticed was that these configurations could be updated without major code changes, so testing becomes really easy. It helped us to quickly test different scenarios in staging without waiting for full deployments because the code changes are not very major; they are minor code changes.

Kong Konnect requires some improvement, but overall the experience is quite positive. One thing I can think of currently is around debugging visibility. While I know that the analytics are helpful, sometimes getting very detailed request-level insights during failures, especially in CI runs, required additional digging. A bit more granular and easily accessible logs would make troubleshooting faster. Also, in some cases, configuration changes were not immediately intuitive to validate from a testing standpoint. Having better tooling or previews to simulate how a policy change would impact API behavior could be useful. Nothing major, but these kinds of improvements would make it even more efficient for teams, especially our teams, which heavily rely on automation and CI pipelines.

Better integration visibility with CI/CD tools would make it easier to quickly correlate test failures and gateway behavior without switching between multiple dashboards. This should be improved.

In my current field, I have been working for more than 3.5 years, and I am going to complete close to four years in my current domain of testing.

Kong Konnect is stable. In my company, the product that I am involved in is very API-heavy. In day-to-day testing and CI runs, we did not face frequent outages and major disruptions. Most of the time, the gateway handled routing and policies reliably, even during heavy regression cycles and heavy customer throughput. One thing I noticed is that even if there are occasional issues at the control plane level, the data plane continues to function using cached configurations, so API traffic is not impacted immediately. Overall, I would say it is a stable platform, especially for production-scale API traffic and for companies like HighLevel  where the products are very much API-heavy.

From what I have seen recently, Kong Konnect is quite scalable, especially in a microservices-based setup. In our case, even during heavy regression runs or higher traffic scenarios, we did not notice major performance bottlenecks. The gateway was able to handle concurrent requests quite efficiently. Also, from what I understand, it supports auto-scaling of gateway nodes, especially in cloud setups, which helps it adjust dynamically based on traffic spikes without manual intervention. Overall, it scales well both horizontally and across environments, which is important when you are dealing with multiple services and high API traffic.

I am not personally involved in customer support. Whenever issues were raised, especially through support tickets, they were escalated and our internal system takes care of those issues. What I have seen is that the response time was generally quick, and most of our queries were resolved within a reasonable time frame. In some cases, critical issues were addressed within a few hours, which really helped during our testing cycles.

Before Kong Konnect, our setup was more direct. We did not use any centralized API management layer. Each service handled authentication and routing on its own, which made testing a bit inconsistent because different services had slightly different implementations. In some cases, we also had basic reverse proxy setups, but they did not provide the kind of flexibility or features that Kong Konnect offers, such as plugin-based policies or detailed analytics. Moving to Kong Konnect helped standardize a lot of those aspects and made our testing approach more structured.

I do not have experience with pricing, but I do have experience with setup and licensing. I did not have direct involvement in the pricing or licensing decision for Kong Konnect, as those were handled more at the management or DevOps level. From what I understood through internal discussions, the pricing was considered reasonable for the value it provides, especially given the centralized API management and flexibility it offers. In terms of setup, since Kong Konnect was already integrated into our AWS  environment when I started, the onboarding from a tester's perspective was fairly smooth. I could start interacting with the APIs through the gateway without much back-and-forth.

From that standpoint, the core of it is that our debugging time during regression cycles reduced roughly by 25% to 30%, mainly because the gateway layer helped us quickly identify whether issues were coming from authentication policies, rate limiting, throttling, or the backend services. Because the debugging time has been reduced, the number of people that are required for doing that debugging and regression has also been improved. I sensed a 30% reduction in the effort. I have seen it myself in the employees needed to do a particular project.

These particular decisions are mostly taken by upper management level people, so I was not directly involved in evaluating which solution would work the best. I believe tools such as Apigee  and AWS  API Gateway were among the ones explored, mainly because they are quite common in the API management space. Eventually, Kong Konnect was chosen because of its flexibility, plugin-based architecture, and how well it fits in our microservice setup.

One piece of advice I can give is that instead of using traditional methods of API management, Kong Konnect provides a very reliable solution for centralized API management. Because APIs and backend services are the backbone of any product, if these are scaled in a better way, then that is the main thing. One piece of advice I would give is to clearly understand your API ecosystem first before adopting Kong Konnect because it works really well in a microservice architecture. To get the most value, you need to have a clear idea of how your services interact and what kind of gateway policies you want to enforce. From a testing standpoint, it is important to design test cases not just for API functionality but also for gateway-level scenarios such as authentication failures, throttling, and routing behavior. That is something teams sometimes overlook initially. If these things are taken care of, then Kong Konnect will be a very useful product for companies which are heavily reliant on APIs. I have provided a rating of 9 out of 10 for this review.

Hybrid Cloud

Amazon Web Services (AWS)

What do you like best about the product?

Earlier we were using Kong enterprise and recently we migrated to Kong Konnect, the Konnect is absolutely a good enhancement that we wanted because UI is simple to check DP & CP, i can check all created Gateway's including how many servers are present in the DP. Integration with organization SSO is very seamless without any issues. Also there are plenty of new features for future enhancement like AI gateway and LLM connection. We have deployed CP in our on-prem and performance quite good and it was in ms only by using validations and authentication plugins.

What do you dislike about the product?

There are not major downsides, if we get a screen to deploy custom plugins or build custom plugins then that will be very helpful.

What problems is the product solving and how is that benefiting you?

Building custom plugins or readymade drag n drop functionality to build custom plugin and developer portal.