Home / Dedicated Cloud Gateways
Edit
Report

Dedicated Cloud Gateways production readiness guide

Uses: Kong Gateway
Related Documentation
Gateway Documentation
Incompatible with
on-prem
Tags
#dedicated-cloud-gateways
Related Resources
Dedicated Cloud Gateways
Dedicated Cloud Gateway data plane logs
Set up a GCP VPC peering connection
Configure an outbound DNS resolver for Dedicated Cloud Gateway
Dedicated Cloud Gateways reference
Set up an AWS resource endpoint connection
AWS Transit Gateway peering
Configure private hosted zones for Dedicated Cloud Gateway
Set up a GCP private DNS for Dedicated Cloud Gateway
Set up an AWS VPC peering connection

This production checklist provides a high-level readiness outline for customers preparing to route production traffic through Dedicated Cloud Gateway. It focuses on Konnect entities and configurations that are specific to Dedicated Cloud Gateway, cloud provider prerequisites, and general pre-production and security hardening steps.

Because every environment is different, this checklist is not exhaustive and should be used as a starting point. Customers should incorporate additional validation as part of a broader launch plan, including testing and readiness for plugins, routes/services, upstream applications, identity providers (IdPs), third-party integrations, and any upstream or operational dependencies.

Preparing your Dedicated Cloud Gateway for production involves the following general steps:

  1. Verify your Konnect custom domains, data planes, and control planes are configured correctly.
  2. Configure your CIDRs to at least meet minimum requirements.
  3. Verify that your cloud provider is configured correctly.
  4. Secure your upstream environment.
  5. Perform final checks for metrics, logging, load testing, and cutover plan.

These steps are broken down into specific details in the sections that follow.

Konnect configuration

Action: If you’re using a custom domain with your Dedicated Cloud Gateway, you’ll need to do the following:

  • Verify that the Kong-provided CNAME domain is correct in your DNS records.
  • Verify that ACME domain is correct and the challenge path is accessible.
  • Verify that the custom domain is healthy in the Konnect UI.
How to verify in Konnect
  1. In the Konnect sidebar, click API Gateway.
  2. Select your Dedicated Cloud Gateway.
  3. Click the Custom Domains tab.
  4. Verify that the status of your custom domain displays as HEALTHY. Monitor this for certificate issuance and readiness.
  5. Click the more options menu icon next to your custom domain.
  6. Click Configure DNS.
  7. The first CNAME value should match the CNAME domain in your DNS records.
  8. The second CNAME value is the ACME domain you must use for automated certificate management. Make sure that this challenge path is accessible.

CIDR size requirements

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:

Number of AZs

Minimum CIDR
2 /23 (512 IPs)
3 /22 (1,024 IPs)
4 /22 (1,024 IPs)
5 /21 (2,048 IPs)

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.

CIDR range

AZ count

Usable IPs per AZ in public subnet

Usable IPs per AZ in private subnet

Recommended data plane count
/16 2 8175 16357 1-960
/16 3 2031 8173 1-480
/16 4 2031 8177 1-480
/16 5 1007 8180 1-480
/17 2 4079 8165 1-480
/17 3 1007 4077 1-240
/17 4 1007 4081 1-240
/17 5 495 4084 1-240
/18 2 2031 4069 1-240
/18 3 495 2029 1-120
/18 4 495 2033 1-120
/18 5 239 2036 1-120
/19 2 1007 2021 1-120
/19 3 239 1005 1-60
/19 4 239 1009 1-60
/19 5 111 1012 1-60
/20 2 495 997 1-50
/20 3 111 493 1-30
/20 4 111 497 1-30
/20 5 47 500 1-30
/21 2 239 485 1-30
/21 3 47 237 1-20
/21 4 47 241 1-15
/21 5 15 244 1-10
/22 2 111 229 1-10
/22 3 15 109 1-8
/22 4 15 113 1-3
/22 5 Not supported Not supported Not supported
/23 2 47 101 1-3
/23 3 1 45 Not recommended

Cloud provider configuration

See the section for your cloud provider for more information about how to configure your provider for a production instance of Dedicated Cloud Gateways.

AWS

Action:

  • Verify the number of available IPs in the subnet, considering your organization’s peak scale and expected traffic. Ensure sufficient IP capacity for autoscaling.
  • Verify the CIDR range to ensure there are no conflicts with your existing networks. Cross-reference this with your network topology.
  • Verify that security group rules allow necessary inbound/outbound traffic (Control Plane <-> Dataplane, Dataplane <-> Upstream). Strict security posture is required.

Azure

Action:

  • Verify the number of available IPs in the subnet, considering your organization’s peak scale and expected traffic. Ensure you have sufficient IP capacity for autoscaling.
  • Verify that the CIDR range doesn’t interfere with existing your VNet. Cross-reference this with your network topology.

GCP

Action:

  • Verify the number of available IPs in the subnet, considering your organization’s peak scale and expected traffic. Ensure there’s sufficient IP capacity for autoscaling.
  • Verify that the CIDR range doesn’t conflict with your existing VPCs. Cross-reference this with your network topology.

Securing Dedicated Cloud Gateway upstreams

While Kong manages the Dedicated Cloud Gateway infrastructure, you are responsible for securing your upstream environments and ensuring that traffic from Dedicated Cloud Gateway is appropriately restricted and authenticated. This shared responsibility model requires precise network and IAM configurations to maintain zero trust principles.

Action: Protect the public gateway endpoint and your workloads

Explanation: You can apply additional layers of security to further protect the public gateway endpoints such as IPS/IDS, CDN or WAF/WAPI systems.

You can apply the following security controls to restrict and validate incoming traffic from Dedicated Cloud Gateway:

  • AWS Security Groups: Apply restrictive ingress rules to only allow traffic from Dedicated Cloud Gateway CIDRs. Gateways can be explicitly allowlisted at the network load balancer (NLB) or application load balancer (ALB) endpoints.
  • Network ACLs (NACLs): Add stateless filters to restrict ingress to your VPCs, and require matching egress rules for return traffic.
  • Transit gateway route tables: Ensure that only explicitly routed CIDR blocks or subnets from Dedicated Cloud Gateway are reachable.
  • DNS resolver rules: Configure Route 53 resolver rules to control which upstream service domains are resolvable from Dedicated Cloud Gateway, enforcing service discovery boundaries.
  • Authentication and authorization: Enforce strong AuthN/AuthZ at all upstream services. We recommend mTLS, JWT, OIDC, and signed requests. TLS should be enabled end-to-end between Dedicated Cloud Gateway and the target service.
  • IP allowlisting at Firewalls or transit gateway attachments: Further isolate exposed components by subnet and port at the perimeter level.

General pre-production final checks

Action:

  • Monitoring and logging: Confirm that Dedicated Cloud Gateway logs (such as access and error) are flowing correctly to Konnect. Check initial log samples.
  • Metrics: Confirm Dedicated Cloud Gateway metrics (for example, latency and error rates) are being collected and reported correctly in Konnect Analytics. Set up initial dashboards.
  • Load testing: Execute representative load/soak tests against the Dedicated Cloud Gateway deployment. Check for unexpected performance degradation or scaling issues.
  • Cutover plan: Finalize and communicate the detailed traffic cutover plan (for example, DNS TTL changes and staged traffic migration). Ensure a rollback plan is also documented.
How to verify in Konnect
  1. In the Konnect sidebar, click API Gateway.
  2. Select your Dedicated Cloud Gateway.
  3. On your Dedicated Cloud Gateway overview, verify that analytics like latency and error rate are collected.
  4. Click the Control Plane Logs tab.
  5. Verify that your Dedicated Cloud Gateways are collected. Check the initial log samples.
  6. In the Konnect sidebar, expand Observability.
  7. Click Dashboards.
  8. Set up initial Dedicated Cloud Gateway dashboards.
Something wrong?
Report an Issue | Edit this Page
View all Kong documentation

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!
Contribute

Still need help?

Ask in our Slack Community
Contact Support