Dedicated Cloud Gateways network architecture

In a Dedicated Cloud Gateway, Kong manages the Gateway infrastructure (compute, Dedicated Cloud Gateway network, and data planes) for you in a single-tenant cloud environment dedicated to your organization (AWS, GCP, Azure). A complete Dedicated Cloud Gateway deployment consists of this Kong-managed network infrastructure and the cloud infrastructure with the upstream services you manage.

The following diagram shows how traffic flows in a Dedicated Cloud Gateway:

 
flowchart LR
    A(API consumers) --> |inbound edge| B(Kong data planes)
    B --> |upstream path| C(Your services)
  

The networking decisions you make govern both hops independently.

Before you deploy a Dedicated Cloud Gateway, you must make some choices to determine how to deploy it based on your network and upstream service configuration:

1. Decide which cloud provider or providers you want to use based on where your upstream service cloud infrastructure is currently deployed.
2. Decide if you want a public or private Dedicated Cloud Gateway (or both) depending on if your upstream traffic is public or private.
3. For private Dedicated Cloud Gateways:
   • Decide how Kong Gateway will connect to your upstream services via private network peering (VPC/VNET), hub-and-spoke networking (Transit gateway, VWAN), or private endpoints (AWS resource endpoints).
   • Decide how to resolve hostnames, either via private DNS or an outbound DNS resolver (when your hostnames live on a separate DNS server).
4. Decide if you need a multi-cloud Dedicated Cloud Gateway for high-availability.

The Kong-managed Gateway infrastructure consists of data plane nodes that run inside of a Kong-managed network peering (VPC or VNET depending on your provider). The Kong-managed data plane nodes automatically scale with your throughput.

The following diagram shows what the Kong-managed architecture looks like if you chose AWS as your provider:

 
flowchart LR
    subgraph kong_account["Kong-managed AWS infra"]
        subgraph kong_vpc["Kong-managed VPC"]
          dp1[" Data plane node"]
          dp2[" Data plane node"]
          dp3[" Data plane node"]
        end
    end

    style kong_account stroke-dasharray:3,rx:10,ry:10
  

In a Dedicated Cloud Gateway, the Kong-managed infrastructure communicates with your own cloud infrastructure that contains your databases, APIs, and other resources. Your infrastructure can run on virtual machines (VMs), managed container platforms like ECS, Kubernetes managed pods, or a combination of multiple platforms. If the services are backed VMs or managed container platforms, Kong mostly expects you to expose them via load balancer. If the services are in Kubernetes managed pods, they can either be exposed via a shared ingress or if only a small set of services need to be exposed, they can be directly exposed by a load balancer service.

Konnect uses cross-availability zone load balancing to distribute traffic evenly across data plane nodes in all availability zones where your Dedicated Cloud Gateway is deployed. Load balancing happens at the connection level, not per request. Multiple requests sent over the same TCP connection go to the same data plane node. Different connections distribute across nodes.

Before you deploy a Dedicated Cloud Gateway, you’ll need to determine if you should deploy a public or private gateway, or both. Which you deploy depends on how API consumers are reaching your gateway and how you want data planes to reach your backend services:

• Use public if you:
  • Expose services to the internet with custom access control
  • Want minimal setup and are securing at the Kong layer
  • Proxy your own infrastructure over the public internet
• Use private if you:
  • Deploy upstream services on one or more private network (VPC or VNET)
  • Don’t expose services to the public internet
  • Require network isolation or full edge control
  • Operate under regulated security requirements

Use both a public and private Dedicated Cloud Gateway if some of your traffic is public-facing and other traffic is private.

The following table describes which cloud providers and private networking configurations are supported:

A single Konnect control plane can manage Dedicated Cloud Gateway deployments across AWS, Azure, and GCP simultaneously. Multi-cloud deployments are common in enterprise environments for high availability, regulatory requirements, or because upstream services are distributed across providers.

When deploying across multiple cloud providers, you’ll need to decide how API consumers discover and reach each deployment. Konnect doesn’t provide cross-cloud private networking. If a gateway in one cloud must reach backends in another, you’re responsible for implementing that connectivity using your cloud provider’s tools (for example, Transit Gateway, ExpressRoute, and Direct Connect).

For more information, see Multi-cloud Dedicated Cloud Gateway network architecture.

You can use a Web Application Firewall (WAF) in front of your Dedicated Cloud Gateway as a first-line defense that filters and blocks malicious traffic before it reaches Kong Gateway. A WAF provides Layer 7 protection for HTTP(S) traffic and helps protect APIs against:

• OWASP Top 10 vulnerabilities
• Malicious bot traffic
• IP reputation threats
• Rate-based abuse
• Geo-based access restrictions

Kong strongly recommends configuring a WAF for public and private Dedicated Cloud Gateways. WAF configuration differs for public and private deployments.

For more information about all Kong Gateway WAF configurations and plugins, see Kong Gateway WAF capabilities.

To ensure your Gateway traffic can continue uninterrupted in the event of a control plane or provider outage, you can deploy data planes in multiple Dedicated Cloud Gateway regions and cloud service providers. This setup allows Kong to automatically re-route traffic to the secondary region or cloud provider during an outage.

You cannot edit an existing Dedicated Cloud Gateway network CIDR: To change a network’s CIDR, recreate the network with the new CIDR.

Before creating a Dedicated Cloud Gateway network, choose the CIDR range you want to use. A CIDR block defines the range of IP addresses available for your Dedicated Cloud Gateway. If you’re configuring private network connectivity, this CIDR block must not overlap with CIDR blocks assigned in your own cloud service provider networks to prevent conflicts. The CIDR block must also be large enough to accommodate all Kong-managed infrastructure provisioned inside the network such as the data plane nodes, the DNS proxy, internal load balancers, and other components.

Keep the following requirements in mind when choosing your network CIDR range:

• Prefix length: The CIDR block must have a prefix length between /16 and /23. /23 blocks support a maximum of 3 availability zones.
• Private IP Range: The entire CIDR block must fall within one of these private IP ranges:
  • 10.0.0.0/8
  • 100.64.0.0/10
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 198.18.0.0/15
• No overlap with existing ranges: Your CIDR block must not overlap with any IP ranges already in use by your organization. Overlapping ranges can prevent network peering from functioning correctly.
• No overlap with reserved CIDR blocks: Your CIDR block must not overlap with these reserved ranges:
  • 10.100.0.0/16
  • 172.17.0.0/16

Acceptable CIDR examples:

• 10.4.0.0/16
• 100.68.0.0/20
• 172.20.0.0/22
• 192.168.128.0/18
• 198.18.0.0/16

The number of availability zones (AZs) you plan to use determines the minimum CIDR range for your Dedicated Cloud Gateway network. Keep the following in mind:

• Cloud service providers enforce a minimum subnet mask of /28 (16 IPs) and a maximum of /16 (65,536 IPs) for any subnet.
• The following table reflects the minimum recommended CIDR sizes for Dedicated Cloud Gateway deployments to ensure sufficient IP address space for the required infrastructure.
• Selecting a larger CIDR block provides more flexibility for future growth and expansion.

The following table details the minimum CIDR sizes by AZ count:

How many IPs are usable depends on whether you’re using a public or private subnet, your network’s CIDR range, and AZ count.

• Public subnets: Kong reserves about 50 IPs in total (used by Kong’s internal services and cloud provider reserves).
• Private subnets: The cloud provider your Dedicated Cloud Gateway is deployed on reserves 5 IPs. It cannot use subnets that have fewer than 8 IPs, so Kong reserves about 15 IPs per AZ.

The following table describes how many IPs are usable depending on your CIDR range and AZ count. The recommended data plane count examples assume a maximum of 15 data planes per AZ and each data plane group needs one public IP in one AZ.

You can configure a Dedicated Cloud Gateway network using the Konnect UI, API, or Terraform.

echo '
data "konnect_cloud_gateway_provider_account_list" "my_cloudgatewayprovideraccountlist" {
}

resource "konnect_cloud_gateway_network" "my_cloudgatewaynetwork" {
  name   = "Terraform Network"
  region = "eu-west-1"
  availability_zones = [
    "euw1-az1",
    "euw1-az2",
    "euw1-az3"
  ]

  cidr_block      = "10.4.0.0/16"

  cloud_gateway_provider_account_id = data.konnect_cloud_gateway_provider_account_list.my_cloudgatewayprovideraccountlist.data[0].id
}
' >> main.tf

terraform apply -auto-approve

Important: It can take 30-40 minutes for your network to initialize. You must wait for your network to display as Ready before you can configure private networking.