<commit_before>---
title: Kong Implementation Checklist
---
# Kong Architecture Patterns

An important part of setting up a new Kong cluster is choosing the right architectural pattern that fits your needs and integrates with your existing infrastructure. Here are a few that we commonly see and recommend. Kong itself is greatly flexible, and can be setup in many ways. We present these as starting points in hopes that you find that using or extending one of these patterns provides an ideal fit for your unique needs.

## Kong between client and upstream

The classic architectural pattern we see customers setting up is adding Kong in between some, or all, of their API traffic. Kong is installed in your prefered hosting provider, and configured to proxy traffic to the existing APIs. Note that in this pattern the APIs are still accessible directly, that is both through the proxy and also without being routed through the API Gateway. We see this during initial testing, and migration phases, before customers eventually route all traffic through Kong. 

The pros of this approach are that it is simple to setup and configure. All it requires is setup, and coordinating new traffic to use the gateway. Older traffic will still flow directly to the APIs.

The cons are, in this case, the same as the pros. It’s a simple pattern, which works for new traffic, but older traffic will continue to be routed directly to the API and not take advantage of rate limiting, auth, or other plugins configured on the Kong gateway.

Often we see this initial Kong configuration morph into one where the APIs are walled off behind a firewall, which we will visit in the next pattern.

## Kong and APIs behind firewall

The next pattern we see, and the next step for security, is to setup [API servers behind a firewall](https://getkong.org/docs/latest/network/) and only allow the Kong API Gateway be accessible to the public.
<commit_msg>docs(ee/guides) architecture patterns updated to correct title<commit_after>---
title: Kong Architecture Patterns
---
# Kong Architecture Patterns

An important part of setting up a new Kong cluster is choosing the right architectural pattern that fits your needs and integrates with your existing infrastructure. Here are a few that we commonly see and recommend. Kong itself is greatly flexible, and can be setup in many ways. We present these as starting points in hopes that you find that using or extending one of these patterns provides an ideal fit for your unique needs.

## Kong between client and upstream

The classic architectural pattern we see customers setting up is adding Kong in between some, or all, of their API traffic. Kong is installed in your prefered hosting provider, and configured to proxy traffic to the existing APIs. Note that in this pattern the APIs are still accessible directly, that is both through the proxy and also without being routed through the API Gateway. We see this during initial testing, and migration phases, before customers eventually route all traffic through Kong. 

The pros of this approach are that it is simple to setup and configure. All it requires is setup, and coordinating new traffic to use the gateway. Older traffic will still flow directly to the APIs.

The cons are, in this case, the same as the pros. It’s a simple pattern, which works for new traffic, but older traffic will continue to be routed directly to the API and not take advantage of rate limiting, auth, or other plugins configured on the Kong gateway.

Often we see this initial Kong configuration morph into one where the APIs are walled off behind a firewall, which we will visit in the next pattern.

## Kong and APIs behind firewall

The next pattern we see, and the next step for security, is to setup [API servers behind a firewall](https://getkong.org/docs/latest/network/) and only allow the Kong API Gateway be accessible to the public.

{'fraction_non_alphanumeric': 0.03147389969293756, 'fraction_numerical': 0.0, 'mean_word_length': 4.414127423822714, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6268487', 'n_tokens_mistral': 867, 'n_tokens_neox': 822, 'n_words': 638}