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.

Before you create a Dedicated Cloud Gateway network, determine which CIDR range you want to use for your network. 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. Keep in mind that your Dedicated Cloud Gateway network CIDR block must be large enough to cover the Kong infrastructure Kong will provision inside it, such as the data plane nodes, the DNS proxy, internal load balancers, and any other components Kong manages.

Keep the following CIDR requirements in mind when you’re deciding your network CIDR range:

• Prefix length: The CIDR block must have a prefix length between /16 and /23. /23 blocks are only supported for up to 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

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" {
  page_number = 1
  page_size   = 1
}

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.